I suspect, given the reference to sending verification emails, that hashing was what was intended here. As with the use of identity instead of authorization. To be clear, encryption implies you can retrieve the stored value later, while hashing is intended to be one-way.

I've fixed the language in question. Thanks all for the catch here.

The full quote is:

"When storing passwords, encrypt them first, using an existing, widely used crypto library. If you can get away with it, outsource identity management to Facebook / GitHub / Twitter / etc. and just use an OAuth flow."

Can you elaborate on what's so "nope" about that advice? Are you saying one shouldn't encrypt passwords?

Of course one shouldn't encrypt them, one should salt and hash them. With a cryptographically secure hash such as bcrypt or scrypt.

If you use a batteries-included web-framework, this is already done for you. If you do not, you better understand the tradeoff of redeveloping those parts.

I imagine the OP probably meant that and simply wrote the wrong thing in the post. I probably wouldn't have noticed it was the wrong wording if not for this comment chain.

The only acceptable advice in this situation is "use bcrypt". Vague stuff about "hashing or encrypting" is not good enough.

Wait, what about "scrypt"? Maybe the only acceptable advice changed in the last hour? :-)

Bcrypt is a very easy to use hashing tool that exists in all popular languages. It is the best choice, and the easiest to implement.

and if you're salting them yourself you're doing things wrong, use a good library that takes care of these little crypto details for you.

That is correct. You should not store passwords in any form ... even encrypted.

You should either store only the salted hash value, or outsource the identity management to a third party who knows not to store the users passwords. :)

Encryption isn't encryption if it's one-way.

Thanks, I was trying to rephrase it, similar to people using IM in this thread but being off-base with it's actual meaning.

Encryption means encrypting information which can later be decrypted. If you are talking about a one-way transform of data that you can never retrieve the original information from the result of the transformation, that is called hashing. We hash passwords, not encrypt them.

I think the OP meant "hash them" with something like bcrypt.

Which raises the question: should you follow web application advice regarding security from someone who mistakenly uses the word "Encrypt" when they (actually or unintentially) mean "Hash?"

It's an easy slip of the tongue, either if you don't know very much, or if you've spent too much time reading how the bcrypt hash works internally - https://www.usenix.org/legacy/events/usenix99/provos/provos_...

Yeah, yeah, I think I would. Someone's credibility as a programmer isn't destroyed in my mind because they say encrypt to describe hashing, especially if they are in fact, hashing and not encrypting and understand why.

This is something I've seen a lot of developers act elitist about, and it's always rubbed me the wrong way.

It's the same in everything. I'd say passwords are "encrypted" in my systems (even though they're salted/hashed).

It's like the gun nuts that flip out when someone calls it an assault rifle or a clip instead of a magazine.

What can you do, people like showing off how "smart" they are.

Technical jargon is a precise language because it communicates precise concepts. People who do not use it correctly likely have serious misapprehensions and their advice is automatically suspect. Excusing the misuse helps no one.

I hope that at least some services will eventually consider that for sites that aren't storing valuable data, Passwordless (i.e. emailed, etc. one-time token) and long-lived session tokens are better than even touching passwords.

Going passwordless with long-lived sessions requires more complex session management though. If you don't time-out sessions then you increase the cumulative probability of a live session eventually being hijacked through XSS, MITM (coffee shop, rogue wifi), or malware etc.

And if you want the user to be able to perform sensitive operations (edit their personal details for example) then you'll have to ask for a OTP or email verification every time. These methods tend to be higher friction than a password box.

I'm not sure I see the XSS vuln, or rather, a site might have an XSS vuln and long sessions would make it worse, but I don't see long sessions causing XSS. MitM would be possible without TLS, but not with it. Malware is always a threat, but if it can read cookies it might be able to read cached passwords etc. too.

Sure you don't want to constantly bug the user but not every site needs to do that. Especially for sporadically-used sites, "receiving email" could be less of a pain than keeping track of passwords.

A session can be long-lived without being indefinite. We might decide that any authenticated site visit within the last week is new enough not to repeat the passwordless process, or we might say two weeks or a month or whatever.

Are there actually any sites that do this? It is somewhat interesting.