Bill: To clarify why a salt is necessary, consider the classic time-space tradeoff. Let's say I know that your password is exactly 8 characters long and I know all of the possible characters it could be. So let's say it's alphanumeric (a-z, A-Z, 0-9, hyphen, period, underscore) - that's 26+26+10+3 = 65 possible combinations per character.
Then you'd only have to generate a hash 65^8 = 318644812890625 times, which for faster computers these days shouldn't take too long. Still, it takes a lot of time, so you can store it all in a database (ie, Rainbow Table). So if you map a bunch of arbitrary plaintexts and calculate their hash, you can look up the hash and figure out what text was used to generate that hash. Thus, you've either figured out the password or an MD5 collision thereof; in either case, you'll be able to log in. There are web sites that specialize in that sort of thing. So having a 2-byte salt can really help stop those attacks, or at least make the amount of space needed infeasible (since every different 2 character salt will require you to generate an entirely different rainbow table). For most uses it's probably unnecessary, however, if you can harden security with just a few extra lines of code, why not? Cheers, Jonathan On Wed, May 20, 2009 at 5:45 PM, Bill Ward <[email protected]> wrote: > > > On Wed, May 20, 2009 at 2:39 PM, Jonathan Yu <[email protected]> > wrote: >> >> 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. > > > Maybe I can make it so that the user can specify whatever cryptodigest they > like, since opinions vary a lot on this. MD5 is nice because everyone has > it, and although there are chinks in its armor as you mention it's still > pretty widely used and respected. I don't want to force people to adopt a > new module if I can avoid it, but it would be good to support something like > SHA-256 or 512 for those who are more concerned about security. > >> 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'm not doing that, but that wouldn't be hard to add. I didn't think that a > salt was necessary with a one-way hash. > >> >> 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). > > > Well, some of the apps I have using this are running as CGI rather than > mod_perl, so right there that rules that one out. Also, mine is not > specifically tied to the web; it could be used for other kinds of apps as > long as there was a suitable translation for the concept of a cookie. > >> All in all, it feels to me like you're reinventing the wheel here. >> CPAN can be a great resource for these tools. > > Well, I never found anything on CPAN that did quite the same thing mine > does. And I wrote it originally about ten years ago when there was no such > thing on CPAN for sure. >
