4 ms·
>When storing passwords, encrypt them Nopenopenopenopenope! This is terrible advice. Don't do this. Remember what happened when Adobe did this?
by shiggerino 11y ago
>When storing passwords, encrypt them
Nopenopenopenopenope!
This is terrible advice. Don't do this. Remember what happened when Adobe did this?
- rfrey 11y agoThe 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?
- atwebb 11y agoI think they're assuming it can be decrypted instead of one-way.
- ad-hominem 11y agoEncryption 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.
- smt88 11y agoEncryption isn't encryption if it's one-way.
- atwebb 11y agoThanks, I was trying to rephrase it, similar to people using IM in this thread but being off-base with it's actual meaning.
- ovi256 11y agoOf 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.
- mcdougle 11y agoI 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.
- woah 11y agoThe only acceptable advice in this situation is "use bcrypt". Vague stuff about "hashing or encrypting" is not good enough.
- baby 11y agoand 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.
- mgolawala 11y agoThat 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. :)
- lstamour 11y agoI 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.
- venantius 11y agoI've fixed the language in question. Thanks all for the catch here.
- aikah 11y agoI think the OP meant "hash them" with something like bcrypt.
- balls187 11y agoWhich 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?"
- brlewis 11y agoIt'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_html/node4.html https://www.usenix.org/legacy/events/usenix99/provos/provos_...
- justathrow2k 11y agoYeah, 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.
- iolothebard 11y agoIt'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.
- oldmanjay 11y agoTechnical 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.
- jessaustin 11y agoI 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.
- cpitman 11y agoAre there actually any sites that do this? It is somewhat interesting.
- nly 11y agoGoing 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.
- jessaustin 11y agoI'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.