[sf-lug] For SysAdmins upgrading of the hashing algorithm
rick at linuxmafia.com
Wed Jun 13 17:39:48 PDT 2012
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.
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
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.
More information about the sf-lug