[sf-lug] For SysAdmins upgrading of the hashing algorithm

[Rick Moen]

A few days ago, I wrote:

> Some folks might be interested in this matter because of recent theft
> and subsequent cracking of 6.4 million MD5 hashes of LinkedIn passwords
> that someone posted to a Web forum in Russia.  The story goes, they were
> easy to crack because of LinkedIn's use of MD5 years after that hashing
> method was judged too weak to be safe -- and therefore it must be
> equally dangerous to use for user-login password hashes on Linux.
[...] 
> Rumour has it that the LinkedIn passwords were not stored salted, and
> obviously they weren't kept in very secure storage.  If they'd been
> stored using a computationally more expensive hashing method like
> SHA-512 or Blowfish _and_ using salt, they would have been a great deal
> more difficult to match to plaintext, even ignoring the obviously poor
> security on hash storage.

Correction:  According to a very informative EFF article, it was
unsalted SHA-1 hashes, not unsalted MD5 ones.

https://www.eff.org/deeplinks/2012/06/passwords-linkedin-and-beyond

The article doesn't actually say very much about the LinkedIn incident,
but has lots of sound practical recommendations about passwords.  Which
makes sense:  EFF's trying to help users, and there's not a lot EFF can
do about a company like LinkedIn making the dumb decision to store
password hashes without using the 'salt' modification.  It's out of the
users' hands -- whereas, good password practices are very much in their
hands.

The point about 'salt' is that it defeats attackers ability to build a
single huge table of, say, SHA-1 hashes of dictionary words and of other
strings likely to be used for passwords, and just bulk-comparing stolen
hash contents against the table.

As a fine point, Steve Bibayoff, that is also why there's no real gain
from using per-account individual salts within a system:  By salting the
hashes for the system as a whole, you are already defeating the
attackers' ability to precalculate a mammoth table.