Are passwords obsolete ?

[Rob Seastrom]

Michael O'Dell <mo at ccr.org> writes:

> (2) exhaustive brute-force attack against
> compromised encrypted credentials

I'd like to further point out that there are "shades of badness" here.

To be pedantic, the credentials (passwords) usually aren't
"encrypted", which suggests decryptability.  They're "hashed", which
implies one-way, but as you note dictionary-based attacks are trivial
even with a single computer (and particularly vulnerable to a
precomputed attack, often referred to as a "rainbow table").  This is
why standard advice is to never use a password that can be found in
the dictionary.

So let's say that a hashed password file is divulged to unauthorized
parties.  What's the next question that people are going to ask?  Of
course it will be which hashing algorithm was used, and whether it was
via standardized APIs that come with perl, php, python, ruby, etc (and
have been looked at by many eyes) or...  something else.

This is where people suddenly discover they're vulnerable.  Novice
programmers (the kind who can be acquired for cheap) tend to be fond
of rolling their own functions rather than researching published APIs.

This is what bit LinkedIn a couple of years ago.  They used either md5
or sha1 for hashing, but failed to salt the hash - see
http://en.wikipedia.org/wiki/Salt_(cryptography) - because someone
rolled their own functions.

Salted md5 or sha1, even with md5's known shortcomings, would have
been far less of a disaster.  Salted sha256 would have been marginally
better.

But there are hashing algorithms that are deliberately designed to be
computationally expensive.  This slows up attackers, though you need
many orders of magnitude of slow-down to counteract the efforts of a
quarter-million-host botnet.  One particularly favorite expensive
hashing algorithm is http://en.wikipedia.org/wiki/PBKDF2 (it's in your
iPhone).

The lesson is to make sure via code reviews that hashing is being done
*right*, and that the infrastructure ought to simultaneously support
more than one type of password hashing so that when periodic security
reviews bring up a new recommended practice in password storage, a
"fall-forward" behavior is possible without hosing everyone with an
existing account.

You, the end user, of course have no control over the clue factor at
the various online services you may use, and you also don't know what
kind of baddies might work for that company to do some kind of inside
job, so re-using passwords across multiple services ought to be on
your "do not want" list.

-r