Weekly Edition
Return to the Security page
| |||||||||||||
|
| |||||||||||||
Google as a password cracker (Light Blue Touchpaper)
Light Blue Touchpaper covers a somewhat surprising use of Google to crack Wordpress passwords. Other passwords stored as hashed values without salt would also be vulnerable to this kind of search. "Instead, I asked Google. I found, for example, a genealogy page listing people with the surname 'Anthony', and an advert for a house, signing off 'Please Call for showing. Thank you, Anthony'. And indeed, the MD5 hash of 'Anthony' was the database entry for the attacker. I had discovered his password."
(Log in to post comments)
Google as a password cracker (Light Blue Touchpaper) Posted Nov 17, 2007 0:01 UTC (Sat) by epa (subscriber, #39769) [Link] This is a variant of the old attack using a list of precomputed hashes. This is the reason why salting should be used for passwords. Generate 30 bytes of random data and XOR the password with that before taking the MD5 sum, then store both the random salt and the resulting MD5 checksum. (Or your choice of hash function instead of MD5 - though any hash function used on its own is vulnerable to someone looking up precomputed values.)
Google as a password cracker (Light Blue Touchpaper) Posted Nov 17, 2007 13:02 UTC (Sat) by tialaramex (subscriber, #21167) [Link] The article already links salting, but since you mentioned it here too, I think there are a few niggles with your description... The "random" salt doesn't need to be cryptograhically random, you just want to ensure that it varies between hashes (if many hashes use the same salt, you're back to a tiny version of the original pre-computation problem) and that an attacker can't force it to some particular value. So e.g. the current time in milliseconds is an acceptable salt for a lot of applications, since it varies pretty quickly (1000 times per second) and the attacker can't control time. If you have a batch process creating many hashes at once, wallclock time may be too coarse, but a system cycle counter or other trivial varying input would be fine. 30 bytes of data is overkill for a salt. It would suppose that you probably expected to generate many more hashes than there are atoms in the universe. Old-style Unix password crypt() used just 12 bits, and I still haven't seen any direct attacks on that (although it does have other problems, and such attacks are just about feasible) and these days 64 bits would probably be adequate to defeat any plausible pre-computation attack. There's also no reason to use XOR. Simply concatenating the password or other input with the salt and putting the whole thing through the hash is fine since you are using a cryptographically secure hash function. The take home message is very simple for most people. Use salt. Don't try to figure out how to do it yourself, find a trustworthy implementation and use that instead. Check the results, create two users in your new web 2.0 application, with the same password, and check that you can't tell they have the same password by looking in your user database. If you can then your salt doesn't work. Start over. If you're supposed to be developing a protocol, a framework or whatever with a security element, either use a pre-existing component for that part or hire someone who actually knows what they're doing. Far too many systems end up back-flipping through hoops for "security" reasons only to send a password-equivalent in plaintext over the wire or restrict the effective key size to 32 bits or do other silly things because they tried to re-invent the wheel.
Google as a password cracker (Light Blue Touchpaper) Posted Nov 21, 2007 9:10 UTC (Wed) by ekj (subscriber, #1524) [Link] I agree with the principle. But why 30 bytes ? 240 bits is way overkill for avoiding collisions. Okay, so doig it in an overkill kind of way doesn't hurt, I was just curious if you had a spesific reason for suggesting that much.
Google as a password cracker (Light Blue Touchpaper) Posted Nov 21, 2007 14:25 UTC (Wed) by epa (subscriber, #39769) [Link] I just assumed arbitrarily that a password will be limited to 30 bytes in length, and so 30 bytes of randomness is a convenient length to do the XOR. As others pointed out, you don't really need to XOR but just concatenate, if you're using a good hash function. With 12 bits of random data, there are 4096 times as many hash values for each password so you'd find far fewer hits on Google for a given MD5 hash, but still given the world's population and the size of the Web a match is not impossible. Better to use a good few bytes for the salt.
Google as a password cracker (Light Blue Touchpaper) Posted Nov 17, 2007 13:49 UTC (Sat) by tialaramex (subscriber, #21167) [Link] It would be good to "out" software like this (Wordpress) that doesn't take the rudimentary precaution of using salted hashes. There's far too much of it out there, and with site security being in general pretty poor it's never going to be long before such unsalted password hashes are being distributed on IRC for script kiddies to unravel. In fact the existence and popularity of this type of software encourages script kiddies to try to break into a site to collect more unsecured hashes. If getting a password out was impractical a lot of the fun would be gone and some of them would quit doing it. In effect we have an ongoing Internet public health disaster, with those who do take sensible precautions at risk because of those who either don't care or don't understand. The #1 solution to such a public menace is awareness, which in this case means telling Wordpress users that it has lousy password security. This is also a good reason not to use passwords at all for systems like blog software that are of only modest security value. OpenID or other single sign-on technology moves all the difficult security stuff to a provider that cares as much (or potentially as little) as the user does about their security. Dropping in a good single-sign on system (not rolling your own) means you can forget all further hassle with user identity, password security etc.
Google as a password cracker (Light Blue Touchpaper) Posted Nov 21, 2007 14:31 UTC (Wed) by alex (subscriber, #1355) [Link] Of course one problem is his password was a very simple word. A stronger password would of reduced the chance of it's md5sum existing in Google's index.
|
|
||||||||||||