On Wed, Jun 6, 2012 at 2:28 PM, Heaton, Joseph@DFG <jhea...@dfg.ca.gov> wrote: > What I had heard from my security guy was that what was hacked was the hash > for the encryption. So, doesn’t really matter what you change to until > Linkedin changes the hash itself. Anyone hear if they’ve done that?
I believe your understanding of what "hash" means here is incorrect. It's a best practice to store passwords as hashes. If one stores passwords in cleartext, anyone who obtains a copy of the password database now knows the passwords. They can use those passwords to login, or try them on other sites. So, passwords are hashed. A hash is a cryptographic function which is not easily reversible. For example, say I have a password of "drowssap". That might hash to "939df92f0634b2e1dac11807724db138c8d6b98b". It's computationally easy to feed "drowssap" into the hash function and get the hash. But it is computationally expensive to take the hash and reverse it to the original password. When I set or change my password, I enter the password cleartext, and their system hashes it, and stores the hash. Later, during login authentication, I enter my attempted password, their system hashes *that*, and compares it to the stored hash. If the two hashes match, I must have entered the same password[1], so I'm legit. Now, if someone steals the hashed passwords, that's not great, but it's much less serious. They cannot use the hash to login to my account -- the system only accepts passwords. They cannot easily convert the hash back to my password. The exception would be that attackers could pre-compute hashes for possible passwords -- especially common passwords. These are called "rainbow tables". The attackers could then look up hashes from the stolen database against their rainbow tables. This might let them find all the accounts using "drowssap" as a password, for example. The effectiveness of rainbow tables can be significantly reduced by salting passwords before hashing. Reportedly, LinkedIn's system did not do this. So that's too bad. -- Ben [1] Technically not true, but good enough for this explanation. Google "hash collision" if you want to know more. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
