Google as a password cracker (Light Blue Touchpaper)

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.

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.