LWN: Comments on "Google as a password cracker (Light Blue Touchpaper)"

Google as a password cracker (Light Blue Touchpaper)

alex — Wed, 21 Nov 2007 14:31:58 +0000

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.

Google as a password cracker (Light Blue Touchpaper)

epa — Wed, 21 Nov 2007 14:25:12 +0000

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)

ekj — Wed, 21 Nov 2007 09:10:04 +0000

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)

tialaramex — Sat, 17 Nov 2007 13:49:45 +0000

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)

tialaramex — Sat, 17 Nov 2007 13:02:24 +0000

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)

epa — Sat, 17 Nov 2007 00:01:08 +0000

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.)