2009 |
|
|||
SuperGenPass and Password Composer are password generators, which generate different passwords for each site you use based on a single master password. This gives you the convenience of only remembering one password as well as the security of using different (and strong) passwords for each site. This means that you won't have all your accounts compromised when1 one of them is compromised. Most password generators are implemented as browser extensions or bookmarklets, since they are most frequently needed in a web browser. I've been wanting to start using a password generator, but I wanted to be sure that I could access my accounts even if I didn't have a web browser accessible. The two situations I could think of were a command line only system (e.g. SSH) and my cellphone2. Surprisingly, I couldn't find a command line implementation of SuperGenPass, so I wrote one in Python. I also couldn't find any J2ME or Symbian implementations, and so wrote my own one in J2ME. They both support subdomain stripping and configurable password lengths. They don't support salted passwords. I chose SuperGenPass over Password Composer because it uses a better scheme. Password Composer only uses hex characters, whereas SuperGenPass uses a base64 encoded hash. SuperGenPass also hashes the password multiple times (which would slow down a brute force attack to find the master password) and imposes complexity requirements on the generated password (which reduces the chances that the generated password can be brute forced). |
|||
Following on from yesterday's post, I decided to try implement proper content negotiation. After a fair amount of time spent getting to grips with [Lua][], I got a [script][] which works very nicely. It implements [server driven][] content negotiation for [media types][mime]. The basic idea of content negotiation is that a resource (e.g., this [graph][])
exists in multiple formats (in this case, [SVG][graph-svg], [PNG][graph-png] and
[GIF][graph-gif]). When a user agent requests the resource, it indicates which
formats it understands by listing them in the (The following description assumes knowledge of the The script works by searching the directory for files with the requested name
but with an additional extension (each of which is a variant). The [media
type][mime] is inferred from the extension using Some browsers include wildcard entries such as To install the [script][], download and save it somewhere (such as
|
|||
URLs shouldn't really contain file extensions (like Doing the same for static files (i.e. files served directly by the webserver)
isn't straightforward because most webservers use the file extension to
determine the MIME type to send in the I decided to try find a solution to this for my webserver of choice,
Lighttpd. Lighttpd has a module which embeds a [Lua][] interpreter and
allows you to write scripts which modify (or even handle) requests. So I wrote
a [script][] which searches the directory for files with the same name as
requested but with an extension. This means that any file can be accessed with
the file extension removed from the URL while still having the correct
The script currently chooses the first matching file, which means that having
multiple files with the same name but different extensions doesn't do anything
useful. The proper method however is to actually do [content negotiation][],
which chooses the format based on the preferences indicated by the HTTP client
in the To use this script, download it and save it somewhere (I use
|
|||
I recently came across an article which tries to address the problem of SSH agent forwarding with screen. Briefly, the problem is that reattaching a screen instance breaks agent forwarding because the required environment variables aren't present in the screen instance. The solution given didn't quite work for me though because I use an SSH wrapper script which automatically runs screen. My solution is to write a screen wrapper script which stores the
environment variables in I like to put wrapper scripts in
|
|||
One of the most effective anti-spam measures one can implement is to enforce valid use of SMTP and other standards. Spam clients are interested in sending messages as quickly as possible, and so usually don't bother with actually implementing standards correctly. In this post I shall describe the various checks which can be used, show how to implement these checks in Postfix, and describe how to ensure that your mail server passes these checks when sending mail. Reverse DNS EntriesRFC 1912 states that "every Internet-reachable host should have a name" and "make sure your PTR and A records match". This can be checked by performing a Forward Confirmed reverse DNS lookup1. This check can be done before even accepting the TCP connection, which means the mail server's existence isn't even revealed to rejected clients. Postfix: Add
|
|||