Hi: Well, some things I can think of are:
1. Use SHA-256 instead of MD5. Even SHA-1 is thought to be possibly weak, and there have been collisions detected against MD5, worse for MD's predecessors like MD4. If not SHA, then there are lots of other great algorithms like WHIRLPOOL that are worth looking at. By and large, though, I think support/speed/testing for SHA-256 is in good balance, making it a good choice. If you're really paranoid and want to future-proof your software, then SHA-512 is good too. If you have it so that algorithms for saving passwords can be changed by loading a different module, that would be a useful feature too. 2. Make sure to have a salt value, as it prevents the use of rainbow tables to get a password. So you have the hash and a known salt kept separately (the salt is plaintext), and when you check the password you check: sha256(passphrase + salt) == sha256(passphrase_entered + salt) I think there are some modules that do this sort of thing transparently using mod_perl's authen hook, which means it can be used to provide login using WWW-Basic-Authentication (though that one is a bit insecure, even if you use the MD5-digest form). All in all, it feels to me like you're reinventing the wheel here. CPAN can be a great resource for these tools. Cheers, Jonathan On Wed, May 20, 2009 at 5:24 PM, Bill Ward <[email protected]> wrote: > Over the years I've developed my own private Perl web login module. It > takes a username or email address and password, checks it against the > database, and creates the cookies. It has a 'forgot my password' option > which is reasonably secure (of course it assumes that the email address of > record is secure, but that's unavoidable). It uses MD5 to store passwords > so there's no plaintext option, and I think it's "secure enough" for most > Web apps. I wrote the initial code many years ago and have been tweaking it > and adapting it but never released it as its own module, which I'd like to > finally get around to doing. > > But I'm afraid I may have "missed a spot" security-wise and would like > someone who's a little more of an expert in that area to see if they can > find any holes in its design or implementation that would be unacceptable. > > Any takers? >
