
Cheap GPUs rendering strong passwords useless? - pwg
http://www.zdnet.com/blog/hardware/cheap-gpus-are-rendering-strong-passwords-useless/13125
======
tptacek
_NO THEY AREN'T._

This is a great example of a bona fide _awful_ trade press article: some guy
with a column-inch quota sees a piece by _another_ trade press hack who is in
turn digesting a blog post by someone who is "allergic to command line
utilities" writing up someone else's GPU password cracking tool. And so,
strong passwords are useless!

Except that this has nothing at all to do with why passwords are bad. The
problem GPU crackers exploit was solved over a decade ago with adaptive
hashing. GPU crackers cannot crack scrypted passwords of any real complexity
in tenable amounts of time.

Once again: <http://codahale.com/how-to-safely-store-a-password/>

~~~
tzs
Bcrypt seems to have a big design oversight. Given a password stored with cost
factor C1 that you would like to increase to cost factor C2, it seems to me
that you have to have the plaintext password to do this. Thus, you have to
wait until that user next provides the password, verify it, and then re-store
it with cost factor C2.

~~~
smanek
That's just not true. To oversimplify a bit, let's say BCrypt is a function
b(data, cost) that returns a hash.

Right now, I have b(password, c1) = hash_a stored in my database. To increase
the cost to c1+c2, I just replace that with b(hash_a, c2) = hash_b in my
database. To verify a user's login, I just compute b(b(password, c1), c2) and
compare it to the hash_b I have stored.

Am I missing anything?

~~~
zcid
Or you can wait until the user signs in again and create hash_b at login with
the plaintext password after you validate it against hash_a. I believe that is
how the bcrypt documentation recommends you do it.

~~~
VMG
That is much less preferable though.

------
fleitz
This article is missing a bunch of facts, namely that NTLM passwords have been
broken for 2 to 3 years long before the invention of cheap GPUs. Rainbow
tables are a far more effective way to attack NTLM hashes. Cracking passwords
is trivially parallelizable, if you let your hashes fall into the hands of the
enemy then it's only a matter of money.

The fundamental issue is that of salting combined with not disclosing your
password database. If you're using Windows you should enable the options for
SSHA and disable the NTLM / LM hashes. Instead of using a password use a
passphrase. I use 3 levels of password and at the top level you're looking at
~22 characters which contains characters outside the normal ASCII range so an
attack is looking at ~65536 combinations instead of ~256. I doubt many
attackers include the snowman character. :) (and no that char isnt in my
password)

Running the math quickly yields a time to crack in excess of the lifetime of
the universe, it would probably be easier to generate a hash collision than
crack the password.

------
pixeloution
GPUs are rendering MD5 and other weak hashing methods useless when a database
is compromised. Using bcrypt [properly] can reduce the attempts the fast
computer on the planet could make to a handful per second.

~~~
thirsteh
Yep. Don't store passwords using (non-password) fast hashes like MD5 or
SHA-256. Use bcrypt: <http://codahale.com/how-to-safely-store-a-password/>

~~~
Joakal
His recommendation of not using salts is very misleading and should not be
quoted due to poor advice as Bcrypt is also useless against dictionary and
brute force attacks.

The aim of password storage security is to prevent pre-computed hashing
reasonably enough. No amount of password hashing even if it takes 1000 years
to hash a password if your users use '12345678' as a password.

Salting protects against pre-computed hashes (rainbow tables [0]). Otherwise I
can pre-compute many bcrypt hashes and then quickly look up the password.

[0]
[https://secure.wikimedia.org/wikipedia/en/wiki/Rainbow_table...](https://secure.wikimedia.org/wikipedia/en/wiki/Rainbow_tables)

~~~
tptacek
No; you're incorrect.

All secure password storage schemes are randomized. If you insist on using the
word "salt", then just know that bcrypt, scrypt, and the PBKDFs build the salt
in. You cannot "pre-compute many bcrypt hashes and quickly look up passwords".
So: if you're using a scheme that requires you to think about salts, you are
virtually certain to be using an insecure storage scheme.

And, dictionary and brute force attacks are the entire problem bcrypt is
designed to address. Go back to that article that you didn't really read,
follow the first Usenix link, and read the Usenix paper it cites.

~~~
Joakal
I'm concerned that you advocate ignorance of 'salt'.

Some functions[0][1] seem to optionally allow the use of salt, are you saying
that users should just use passwords as input with bcrypt hashing?

In the article, it does not suggest only bcrypt as well [2].

[0] <http://www.mindrot.org/projects/py-bcrypt/>

[1] <http://au.php.net/crypt>

[2]
[http://www.usenix.org/events/usenix99/provos/provos_html/nod...](http://www.usenix.org/events/usenix99/provos/provos_html/node16.html#SECTION00070000000000000000)

~~~
tptacek
Bcrypt uses a 128 bit salt. The code I provided above didn't show it, because
the library simply generated it for me.

The bcrypt libraries that _require_ users to explicitly provide a salt are
themselves doing their users a (slight) disservice, by making it seem as if
there was a reasonable option for salt generation other than simply using a
CSPRNG.

~~~
djmdjm
> The code I provided above didn't show it, because the library simply
> generated it for me.

... and this is another reason why people should use one of the bcrypt()
implementations for their language* - the API makes doing the wrong thing
difficult or impossible.

* disclosure: I ported/wrote a couple of them

------
bcl
There are at least a few obvious solutions. One is to use long passphrases.
Another is to stop trying to memorize your passwords, write them down on a
postit, encrypted file, etc. The main threat to your security is not someone
digging through the postits in your wallet, it is the hash being stolen from
someone's insecure database.

~~~
r00fus
The bad part is that some sites (even banks!) force you to limit the number or
type of characters. In one ridiculous case, I was forced to use an 8 character
pwd with only lowercased letters.

The solution is to use tools like KeePass or 1Password to allow maximum length
passwords (randomly generated also) wherever possible.

~~~
code_duck
I recently signed up for the new payment system for my local water and gas
company... you _must_ use your phone number as your user name, and the
password, to my suprise, can only be _digits_ , up to 8 characters.

Pretty horrible. I wonder what level of idiot designs these systems.

~~~
cdr
That "new payment system" is quite possibly interfacing with, say, mainframe
code written in the 70s. That's often the source of banks' ridiculous account
restrictions.

~~~
code_duck
I can't see any legitimate technical reason to restrict passwords.

In my example, they could put a sensible account system on the front end, and
do whatever they need to in the back end to link it to my phone number and a
random 8 digit number, if that's what they need.

Same with banks. They can set up a real user name and password from you, store
it in a modern system, and link it to the older system behind the scenes.
Perhaps there's some arcane legislation that prevents this, but it seems
unlikely.

~~~
cdr
That's certainly true, but it doesn't usually seem to happen.

------
flashingleds
Since this has attracted the attention of some very knowledgeable people, can
anyone suggest a good textbook/site/paper discussing password security and
encryption? Obviously I can google 'computer security' and find something, I
just wondered if there was a well regarded standard reference (ala K&R or Art
of Electronics). I don't understand the majority of the techniques being
discussed here but would quite like to.

~~~
tptacek
Sorry, key derivation functions are kind of a back alley in crypto research.
Your best bets are Colin's scrypt paper and the original bcrypt paper; the
bcrypt paper is on the link at Coda Hale's "How To Store Passwords" article,
which you can find plastered all over this thread, and Colin's paper is at:

<http://www.tarsnap.com/scrypt/scrypt.pdf>

------
pragmatic
This article uses NTLM passwords.

Can anyone compare this to the actual MSFT recommended Kerberos security
protocol?

Also, how does one go about getting a list of NTLM passwords to work against?
You steal the domain controller or somehow get access to it?

<http://en.wikipedia.org/wiki/NTLM> MSFT does not recommend using NTML which
is very old.

[http://msdn.microsoft.com/en-
us/library/cc236715(v=PROT.10)....](http://msdn.microsoft.com/en-
us/library/cc236715\(v=PROT.10\).aspx)

Implementers should be aware that NTLM does not support any recent
cryptographic methods, such as AES or SHA-256. It uses cyclic redundancy check
(CRC) or message digest algorithms ([RFC1321]) for integrity, and it uses RC4
for encryption. Deriving a key from a password is as specified in [RFC1320]
and [FIPS46-2]. Therefore, applications are generally advised not to use
NTLM.<68>

------
brianbreslin
can't you design your software to prevent brute force logins? i.e. lockout for
x seconds if y unsuccessful login attempts are made?

~~~
city41
That doesn't matter if someone has a dump of the database. Which as Sony can
tell you, is becoming more common.

~~~
pragmatic
Yes, but once you are in to the point where you have the db...what else are
you going after?

If you can dump the db then (most likely) you also have the credit cards,
other information that is useful to you?

This assumes a hacker has a financial motivation.

~~~
ceejayoz
> Yes, but once you are in to the point where you have the db...what else are
> you going after?

There are many conceivable attacks that would result in a read-only dump of
password hashes. An administrator's account would be useful in such an
administration, turning your read-only access to read-write access.

------
drivebyacct2
NTLM passwords? Meh. An awful benchmark for evaluating modern passwords. Who
uses NTLM besides Windows, honestly? (Apparently the person who seemed to have
not liked this comment, very quickly, heh)

I'd be curious about the timeliness of GPU cracking a 8 character,
alphanumerical mixed case password hashed with SHA1?

~~~
tptacek
Like MD5, SHA1 is designed to be fast. For that matter, so is SHA256, and all
the SHA-3 candidate functions. The right way to think about this is that all
the strong crypto hash functions are unsuitable for use _by themselves_ as
password hashes.

Cryptographers have a mechanism for securely turning human-readable text into
secret material: key derivation functions. All the modern KDFs are adaptive,
meaning that they come with a "pain" dial that you can turn to force attackers
to spend more time executing crypto code paths and less time comparing
results.

You can build decent KDFs out of functions like SHA1, but if hardware GPU
cracking is the future, you're best off with something like Colin Percival's
"scrypt", which was explicitly designed to be memory-hard (requiring lots of
state to compute) and hard to parallelize:

<http://www.tarsnap.com/scrypt/scrypt-slides.pdf>

~~~
shaggyfrog
I know you're a domain expert and in this thread you've suggested both bcrypt
and scrypt. Is there any advantage to one over the other? From my POV it seems
that bcrypt has more implementations and seems better-known (in a good way).

~~~
tptacek
scrypt is the sounder scheme, but bcrypt is far more widely available. Both
are fine.

