This is Sp0rkbomb's TypePad Profile.
Join TypePad and start following Sp0rkbomb's activity
Already a member?
Update has been hidden from all public facing feeds in TypePad
Good post. However, the part about salted hashing is somewhat misleading. Salted hashes (in this form of usage, not in all) are there to slow down hashing, hiding the salt is (as you explain) pointless. This is also why shadow(3) stores hashes in the exact same line as the hash: It doesn't matter. To explain this a bit more thoroughly: Salts must be chosen on a per-password basis in order to provide any hardening against brute forcing. They then provide the additional security that if two of your users (let's call them 'steve' and 'john') have the same password 'password' and you use their usernames as salt, their two password hashes will still be different, because H('stevepassword') and H('johnpassword') are completely different (provided you're using a cryptographic hash). With unsalted hashes (or when the salt is the same for the whole database), as soon as anyone knows the hash of 'password', they can also check through all other rows if they have the same hash. With salted hashes, you have to hash your entire character set against any different salt and check it against the corresponding row.
Commented Apr 6, 2012 on
Hashes are a bit like fingerprints for data. A given hash uniquely represents a file, or any arbitrary collection of data. At least in theory. This is a 128-bit MD5 hash you're looking at above, so it can represent at most 2128 unique items, or 340 trillion trillion trillion. In reality the...
Sp0rkbomb is now following
The Typepad Team
Apr 6, 2012
Subscribe to Sp0rkbomb’s Recent Activity
View all »
Around The Web
All Rights Reserved.
Terms of Service