

Keeping passwords safe by staying up to date - jgrahamc
http://blog.cloudflare.com/keeping-passwords-safe-by-staying-up-to-date?

======
JacobAldridge
As a HN non-hacker old-timer, I've read plenty of conversations about security
and had a vague idea of what the heck y'all were talking about with hashes,
salts etc.

But this post explained it all so clearly, I found it immensely useful to put
some of the pieces together. Have already shared it with some of my even-less-
technical colleagues so they too can appreciate 1) the complexity, 2) the
problem, and 3) the importance of their role in setting passwords. Well
written JGC!

~~~
jgrahamc
Thanks for the kind words.

For those who are interested in how to do the hash upgrade, I wrote a blog
post on my personal site here: [http://blog.jgc.org/2012/06/one-way-to-fix-
your-rubbish-pass...](http://blog.jgc.org/2012/06/one-way-to-fix-your-rubbish-
password.html)

~~~
nickpresta
Depending on the framework you're using, if any, there might already be a
built-in way to upgrade your users' passwords.

For Django:
[https://docs.djangoproject.com/en/dev/topics/auth/#password-...](https://docs.djangoproject.com/en/dev/topics/auth/#password-
upgrading)

------
SkyMarshal
Really nice writeup, but why not also append a discussion of scrypt and its
use of both CPU work factor and memory-hard functions to confound Moore's Law?
It's the next step after bcrypt, after all.

It may not be be implemented across as many platforms as bcrypt yet, but
there's plenty for people to experiment with [1], if only for learning and
educational purposes.

1\. <http://www.freebsd.org/cgi/cvsweb.cgi/ports/security/scrypt/>

[http://manpages.ubuntu.com/manpages/oneiric/man1/scrypt.1.ht...](http://manpages.ubuntu.com/manpages/oneiric/man1/scrypt.1.html)

<http://rubygems.org/gems/scrypt>

<http://pypi.python.org/pypi/scrypt/>

<https://github.com/search?q=scrypt>

~~~
tomjen3
Please not again. Discussions of passwords always brings up these stupid
scrypt bcrypt fanboy comments.

Repeating it one more time won't change anything.

~~~
SkyMarshal
Easy there. You're projecting and reading a little too much into it. I'm not a
fanboy, it simply struck me as a conspicuous oversight to write what appeared
to be a survey of password hashing history and technology, and not mention
scrypt at all.

It's very instructive, especially for people new to this stuff, to see the
contrast between bcrypt's CPU-hard algorithm and scrypt's CPU-hard + memory-
hard algorithm.

But jgrahamc's clarification above makes sense - it wasn't meant to be a
general survey, but only what CloudFlare has done.

------
sp332
Here is a name-and-shame site for services that store and send passwords in
plain text (or any reversible encryption): <http://plaintextoffenders.com/>

~~~
ceejayoz
There are a number there that are new registration e-mail, which doesn't
necessarily mean it's stored insecurely.

E-mailing it around isn't a great idea, certainly, but it's not _as_ bad as
storing it reversibly.

------
hcurtiss
Where do you store the individual salts, or the rules for creating the salts?
Do you hash those too? It seems like they'd have to be sitting somewhere so
that you could salt the input password before hashing to compare with the
salted/hashed password in your database. If the salts are sitting in a
database, and that database is compromised, aren't we sitting right back where
we started with hashed passwords that may be subject to attack by rainbow
tables?

// question asked by an attorney who knows nothing about this subject but what
he's read on HN.

~~~
jgrahamc
The salts are just random strings. They can be stored with the hashed
passwords. The security of the scheme does not depend on keeping salts secret.
It depends on the strength of the hashing algorithm.

Two things:

1\. Rainbow tables are today an irrelevance because of the speed of computers.
What you need to worry about is not precomputed tables, but the ability to
compute hashes when needed. The point of the salt is to prevent you
precomputing anything.

2\. So, suppose you have a database where (hash, salt) has been compromised
for each user. Assuming salt was chosen randomly for each user then attacking
the database boils down to calculating the hashes for common passwords
incorporating the salt. The security of that will depend on the security of
the hash algorithm and its slowness.

~~~
finnw
#1 is not true. Algorithms like bcrypt rely on being so expensive to compute
that brute-forcing is prohibitively expensive. bcrypt does use salt. If it did
not then it would indeed be vulnerable to rainbow table attacks.

------
mp3geek
o/t,

jgrahamc, when does the spdy beta start? :)

