Bob's wife Carla lends a speedy mind | Hacker News Reader

Bob's wife Carla lends a speedy mind

blog.jgc.org

76 pointsjgrahamc26 comments

"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.

Excellent suggestion. Will add.

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.

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.

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?

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.

This.

Also, thanks for a good read John.

I just want to thank you for doing these. We teach the basics of stuff like password security (and while I find security fascinating it's really not my area of expertise) and this will be great for our kids to help them understand (the bit on salting certainly helped me!).

I loved this series thanks for writing it.

A similar explanation for bitcoin would be great.

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.

Password protection is like vaccination. Herd immunity is as valuable asset as individual.

Since the majority of people still have the security setup of "one or two emails for most of the things and a set of 2-3 close passwords"

The moment you have a leak of 200 000 000 email password pairs the whole industry is in trouble not only the site that leaked them.

Currently there is semi random brute forcing - just taking already cracked lists and mutating them to guess the password.

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.

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.

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.

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...

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

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

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

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.

And here it is: http://www.lulu.com/shop/john-graham-cumming/a-non-mathemati...

»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

I actually considered writing a series of article about zero-knowledge proofs. One day...

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.)

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.

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

Reply on news.ycombinator.com