Rainbow Hash Cracking

[Mr. Analog]

Interestingly we've been talking about hashes and password security at work lately for a project we sort of inherited (or rather, foisted upon to use). I ran into this interesting article yesterday using StumbleUpon and it discusses the generation of rainbow tables for the expedient retrieval of hashed plaintext. The vendor who supplied us the code does something strange with their salt value which I think could be easily cracked using Orphcrack given the nature of the code as it was explained to me.

The oddness we ran into was the vendor who supplied us with the code inserts a generated salt into the password and then encrypts the resultant string (this is good, normal). They then also encrypt the salt and append it to the encrypted result. Sounds innocent enough BUT the problem that I see from doing this is that if you have an algorithm generating the salt based on the password string and if more than one user have the same password you will have two entries that end in the same value. From that you could decrypt the repeating values and determine the salt. Knowing the salt for one password isn't that important unless of course as I said, the salt was generated by an algorithm in which case the algorithm could be reverse engineered and with a small amount of effort you could determine the salt for every encrypted password.

Anyway, I found the article to be a good read, check it out:
http://www.codinghorror.com/blog/archives/000949.html

[Thorin]

Actually, one of the problems was that they append the salt directly to the password hash without encrypting or hashing the salt.  Thus, if you know how many characters to take off, you know the salt and you can use a rainbow table to determine the password.  Probably in less than five minutes.

Of course, the same problem exists if you store the unhashed salt in a field next to the hashed password field.  I still don't know what to do about that.  But at least with the hashed salt+password, they need to build a new rainbow table for each password entry, rather than being able to run all passwords against a single rainbow table.  And that's what gives you time...

Also, that CodingHorror article referred to the GeekWisdom password strength meter, something I'm going to start using.  So thanks for that
And it also led to Microsoft's 10 Immutable Laws of Security:

Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore
Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore
Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore
Law #4: If you allow a bad guy to upload programs to your website, it's not your website any more
Law #5: Weak passwords trump strong security
Law #6: A computer is only as secure as the administrator is trustworthy
Law #7: Encrypted data is only as secure as the decryption key
Law #8: An out of date virus scanner is only marginally better than no virus scanner at all
Law #9: Absolute anonymity isn't practical, in real life or on the Web
Law #10: Technology is not a panacea

[Mr. Analog]

Sheesh! I thought they encrypted the salt before they parked it in the database. I sure hope they know that the front facing web app is vulnerable to SQL injection attacks. I bet they even keep the password table in the same alias they allow the application to select from!

If you wanted a way to convince Jon that their code was naff there it is!

[Darren Dirt]

connected to this ancient topic was this much more recent thread, that had a TON of interesting stuff (for those of us who are armchair cryptography geeks)

LinkedIn password hacking = STUPID AND AVOIDABLE!