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.

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

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.

Are there other topics that could use a similar treatment?

Also, thanks for a good read John.

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.

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.

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.

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.

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

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

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