
Bob's wife Carla lends a speedy mind - jgrahamc
http://blog.jgc.org/2013/04/bobs-wife-carla-lends-speedy-mind.html
======
rlpb
"And even when they are salted and hashed it's worth asking (or wondering)
whether they used a scheme that could beat Carla's computer equivalent by
hashing multiple times."

Using such a scheme is generally called using a "key derivation function".
Commonly known ones are PBKDF2, bcrypt and scrypt.

What worries me is that most competent people in the industry still ask
whether passwords were salted and hashed, rather than whether they used a key
derivation function.

This suggests to me that even generally competent developers are not aware
that salting and hashing on its own is considered weak. PBKDF2 is over a
decade old now!

If you want to educate people, please finish by suggesting that developers
should not be rolling their own, but instead using a key derivation function
that wraps the knowledge of the state of the art so that developers don't have
to worry about the details any more.

"Be on the look out when a password database is reported to stolen to see if
the press reports that the passwords were 'salted' and 'hashed'..."

Instead, I would be on the look out to make a note of which key derivation
function they were using. If they weren't using one, they were doing it wrong.

~~~
venomsnake
_What worries me is that most competent people in the industry still ask
whether passwords were salted and hashed, rather than whether they used a key
derivation function._

Maybe because even that weak protection is still rare. It is the equivalent of
"Did you plug it" in tech support.

~~~
rlpb
Sure. I'm certain that there are competent developers who are aware of KDFs
but still ask for salting for the reason you described.

The problem I perceive is that other developers learn from this question. They
falsely learn that salting is the best practice answer, when it is not.

------
jgrahamc
This is the final part of my series about one-way functions and password
storage. Thanks for all the comments.

Are there other topics that could use a similar treatment?

~~~
samwillis
I think this kind of explanation is brilliant. One on public-key cryptography
would be really good but i'm not sure where to start.

~~~
dreen
This.

Also, thanks for a good read John.

------
brudgers
An excellent series of articles that were clear, concise, and entertaining.

The only cryptologic issue I take is that to some degree the analogy
illustrates [rather than breaking down] the security for security's sake
commonly argued in regard to passwords.

Imagine Alice decides to found a crossword puzzle startup. Password recovery
is far more important than protecting passwords. The answer for 2A is not
important enough to justify a computationally intensive salt and hash. She is
responsible for entertaining customers, not running a bank.

~~~
mikeash
This assumes good password hygiene on the part of all of Alice's users, which
is a bad assumption. In reality, a large proportion of Alice's users will use
the exact same password for her site as they use for their bank. She owes it
to her users to protect that data.

Best password practices do not have to be user hostile. You can still allow a
password reset while doing things properly. Yes, you can't e-mail them their
old password, but you can set a new one for them, which is nearly as usable.

~~~
brudgers
I'm assuming no such thing. I am also not assuming that Alice is responsible
for protecting the entire internet.

Your response is exactly in line with my comment - security for the sake of
security and unfortunately the analogy of crossword puzzles does not break
down there.

Assuming that Alice is responsible to protect her user's data - and there is a
comparison with Facebook, Google, and other companies which sell user data,
here - Alice's responsibility is to take reasonable steps based upon the
nature of the data she is protecting.

Until I started pointing this out on HN, my HN password was "hackernews"
because there is nothing here that I really care about protecting, and in my
opinion, nothing worth PG implementing complex password protection over.

~~~
mikeash
My point is that the data she is protecting is not just the crossword data,
but that it also includes _the users' passwords_. Protecting that data is
always worthwhile, because those passwords are so frequently reused. This is
not "security for the sake of security". It doesn't matter if the passwords
are protecting the most unimportant thing on the planet, the _passwords
themselves_ still need to be protected.

------
eranation
This is a great series of posts! a must read for every developer.

If anyone is wondering about the practical aspect of it, here is my
interpretation: never use MD5, SHA-1 etc to hash passwords, they are too fast,
anyone with a good GPU / dedicated hashing hardware can brute force short
common passwords quickly (Carla), use bcrypt/scrypt or _at least_ SHA-256 with
many iterations, and increase it every couple of years as hardware get's
faster...

I would also add: salt your passwords with a secure random, and force strong
long passwords, don't have "security questions" (they can be Googled /
facebook graph searched easily), respond the same time for correct or
incorrect credentials to avoid timing attacks, and note that whatever you do,
if someone got their email account compromised, none of this will matter.

Thanks again for a very well explained set of posts, hope it will make our web
a bit more secure...

~~~
jgrahamc
Your TL;DR talks about things I never said. I never discussed security
questions or mentioned any hash algorithms by name.

~~~
eranation
I'm sorry, you are right, rephrased my comment, thanks for a great set of
posts!

------
sikhnerd
I recall in a previous thread jgrahamc promised a single, illustrated document
with this series, very much looking forward to that so I can hand it to
someone like my wife and have her truly understand how this works. Thanks for
putting it together, great series.

I could see a similar set devoted to explaining things like PGP or PKI

~~~
jgrahamc
Yes, I'm working on the PDF. I intend to leave the series up on my blog but
charge a small fee (probably $0.99) for the illustrated PDF.

~~~
jgrahamc
And here it is: [http://www.lulu.com/shop/john-graham-cumming/a-non-
mathemati...](http://www.lulu.com/shop/john-graham-cumming/a-non-mathematical-
introduction-to-one-way-functions-and-their-use-in-securing-
passwords/ebook/product-20976643.html)

------
danbruc
»And that is the current state of the art in password protection.« It is not
really state of the art; storing passwords in plain text or hashing them are
just by far the most common solutions. I think something like the Secure
Remote Password protocol [1] deserves the label state of the art much more
although it is not widely deployed.

[1] <http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol>

~~~
rwg
It's unfortunate that SRP is one of those _things_ that's technically sound
and has been around for a fairly long time but has never seen widespread
implementation for whatever reason. (See also: IPv6, SCTP, C99.)

------
bishopj
But it still can be easily cracked by making less than 10 single step reverse
lookup dictionaries and the time would be less than a few minutes.

~~~
jgrahamc
Yes, this is the point made here:
<https://news.ycombinator.com/item?id=5551027>

