But why can't I send people their passwords?

[omervk]

Hi all, this is @omervk, one of the co-founders and maintainer of Plain-Text Offenders [1].

I've just finished creating two FAQs: One for developers who come to the site and don't understand what's wrong with what they're doing [2] and another for the laymen who want to understand what we're all about and how to protect themselves [3]. The idea is that people could also send these links around to educate others.

As HN is one of our main supporting communities, I'd love to hear your thoughts about both of these new pages.

[1] http://plaintextoffenders.com/ [2] http://plaintextoffenders.com/faq/devs [3] http://plaintextoffenders.com/faq/non-devs

[jere]

>7. Fine, but I still get to send users their passwords once they created them so they don’t forget them, right? Email is not a secure medium. It was never designed to be one. It’s susceptible to Man In The Middle (MITM) attacks and a slew of other issues. Also, users might have their email accounts abused or hacked into (how many people do you know who have left their GMail logged in on a public computer?). Would you really like someone to gain credentials to your product when this happens?

This is one I always struggled to understand. If email is compromised, the attacker can request and immediately intercept a password reset anyway.

[edit: Many excellent points below. I think some of these should be in the FAQ.

[ajanuary]

I agree; this point shouldn't be about password reset emails being more secure, it should be about the fact you don't need to be able to email them their password to have a successful account recovery process.

That said, it can be more secure. Firstly, people reuse passwords, so intercepting a plaintext password gives you access not only to the account on that site, but also several others.

Secondly, if the link expires you can't use old account recovery emails to find out passwords. If you manage to compromise an account (rather than mitm), you can search through for old "here is your password" emails and use those without even having to initiate a new password recovery process, which in this age of mobile devices and push notifications risks the victim seeing the email and getting suspicious.

[jaredmcateer]

Another thing to consider is if your email provider's offline backups get jacked in transit would you rather your emails contain your plain text passwords or links to a password reset with expired tokens?

[pmjordan]

If someone hacks into your email account, they can just trawl through the email archive and harvest passwords from past password reminder emails. With a temporary reset token, they have to initiate a password reset request, which you should notice: (a) you might notice the email if you have e.g. push notifications enabled, or if the attacker doesn't delete it quickly enough, and (b) your real password will suddenly stop working.

Additionally, even if your reset request is harvested via MITM, if you use a single-use reset token, and an attacker uses it before you can, you know something is up. Even if it's not single-use, your password suddenly no longer working should ring alarm bells.

[weaksauce]

A lot of people use only one password for everywhere... You'd be giving the attacker the keys to the kingdom.

[krambs]

You shouldn't send the password because you shouldn't be storing the password. Worries about email security, etc. are secondary.

[3pt14159]

The main reason not to do it is that people don't always have control over their email, for example, school, work, etc. Also, some courts can force you to give up an encryption password, but many can't. By sending a password in the clear you can be inadvertently giving the court a password that they otherwise wouldn't have had.

[cookingrobot]

Gmail should make you type your password again in order to open password-reset emails sent by other services.

This would close the "I accidentally left my account logged in" hole.

[chacham15]

Most of the other points, while correct miss the big issue: the server should not store the password in case they themselves get hacked. If an attacker gains access to one persons email then he gets 1 password. If he gains access to a server then he can potentially gain access to thousands of passwords. Therefore, having plaintext passwords makes you a target for attackers.

[biggerfisch]

The FAQ isn't saying that the only bad thing is that email accounts might be compromised, simply that that's one reason to not email passwords. While you're right about email comprises allowing an attacker to simply reset a password, the first few sentences are still very important.

> Email is not a secure medium. It was never designed to be one. It’s susceptible to Man In The Middle (MITM) attacks and a slew of other issues.

Email by default right not isn't encrypted. Anyone (eg, a 3-letter government agency or a malicous actor on an unencrypted wifi network) who can intercept your traffic can read that password - and you can't even tell. At least with a password reset there's the "notification" of "my password doesn't work anymore". That's mitigated by SSL/TLS, but it's still an important point to consider.

[blkhawk]

>This is one I always struggled to understand. If email is compromised, the attacker can request and immediately intercept a password reset anyway.

Not really the main issue - if you always send the password the Thief controlling the email does not even need to reset the password. he can get in without leaving any trace at any time. It also allows the collection of all the Passwords from all the users in bulk. And if your users are reusing their passwords everything else is open too.

Sending the Password is just a stupid policy. Its up there with restrictive Password requirements and Server-side unhashed Password storage.

[Mithaldu]

"Man In The Middle (MITM)" is the important bit. For example by sniffing the wireless traffic on an unencrypted wlan you can capture entire emails being sent or received, without ever compromising the account.

[jcampbell1]

In 2007, Gmail had a XSRF vulnerability for setting up filters. It was exploited by attackers that would create a filter 'Contains "password"', 'Forward to: [email protected]', 'Run on all messages'.

Basically you could visit a malicious webpage, and all emails containing the word "password", would be sent to the attacker.

[Sami_Lehtinen]

True, email shouldn't be used for password recovery nor user authentication anyway. But guess what, many sites still do it. Even if site security is otherwise flawless, password recovery using email ruins everything.

[powatom]

True - but you can add an additional layer of security to the password reset request if this is a concern, such as personal questions.

[SkyMarshal]

Would you send your user's password to them on a postcard? If so, by all means feel free to send it in email.

[omervk]

Clickable links:

[1] http://plaintextoffenders.com/ [2] http://plaintextoffenders.com/faq/devs [3] http://plaintextoffenders.com/faq/non-devs

[_mulder_]

I'd suggest starting the answer to each question with a clear Yes or No, Right or Wrong so people can skim through.

Example:

>7. Fine, but I still get to send users their passwords once they created them so they don’t forget them, right?

No, Email is not a secure medium.....

[vomitcuddle]

The dev FAQ should contain information on how to safely (and painlessly) migrate from plain-text/MD5/SHA1 to a more secure algorithm.

[jscheel]

Our healthcare provider is storing passwords in plain text. When I went in for my health screening, they had everyone's forms printed out, with our passwords written on sticky notes attached to the front. Hundreds of people's health data, wide open for the taking. I was beyond pissed. Then I found out that they don't use ssl on their service, and the passsword can be retrieved at the click of a button. Ended up speaking with a C-level about it. Her response was that they are perfectly within HIPAA compliance, and that she would have to talk to their CTO about any other problems with their data security. Looking at the HIPAA, I have to say, it's not very clear on the need for hashing passwords. Still, I reminded her of the massive liability they are opening themselves to. She promised to get back in touch with me, but I haven't heard anything since (imagine that).

[makmanalp]

Your non-devs FAQ is still not quite informative. You still don't explain to laymen /why/ what the sites are doing is wrong, you just say "You should never see your password".

edit:

Maybe something along the lines of:

> Modern cryptography allows websites to save passwords in a form that is un-decryptable even to the site itself. This works because to check the validity of logins, the unencrypted (plain) version of the password is never needed. The fact that a site stores the password in a decryptable format and decrypts it to show it to you means that an attacker could potentially decrypt the password in the exact same way. Or even worse, maybe they never encrypt it in the first place! This potentially compromises the safety of the password you use because it lets an attacker steal your password.

[ajanuary]

That's a pretty technical explanation. I think something like this would suffice:

> If the website can pull out your password to show it to you, an attacker can pull out the password to steal it.

As ever, the issue is explaining hashing.

[omervk]

Thanks, I've added wording for that.

[tptacek]

The "Don't Use Bcrypt" article isn't a good source; the headline message you've taken from it isn't accurate. In fact, bcrypt is significantly better than PBKDF2, and PBKDF2 (with normal parameters) is probably the "least best" of the mainstream options for password hashing.

By citing an inside-baseball controversy, you're making it harder for developers to do a good job storing passwords, because you're creating the impression that developers need to carefully choose which password hashing algorithm they use, and be careful about making the wrong choice.

In reality, what developers need to be careful about is choosing a password hashing algorithm, and not a general-purpose cryptographic hash. The right message is that PBKDF2, bcrypt, and scrypt are all fine options.

So my feedback is that your developer FAQ is trying to be a little too clever for its own good. I'd revise it.

[couchand]

Question #8 on the non-dev FAQ really should be higher up, like #3. That way the early questions mirror their own thoughts: 1. what is this, 2. but I thought it was secure, 3. what can I do?

[peterwwillis]

Question 8 on the dev faq should emphasize using multiple layers when doing a password reset, partially to avoid the inherent problems with e-mail security (especially as your last bastion of security). Security questions, browser heuristics, login attempts, out-of-band communication (SMS confirmation code, secondary e-mail account, etc).

Question 9 should include a sub-section .3 which explains that if you unrestrict the password field, you need to include a basic password cracker or strength requirement, usually along with a client-side "strength" meter. The backend should reject all simple passwords and the frontend should help the user pick a simple yet strong password.

And ideally this page would also link the dev to http://twofactorauth.org/ as an example of how many more places are implementing 2FA. Passwords are dead; long live passwords with 2FA.

[omervk]

Re: Q8. Security questions are an anti-pattern and the rest are outside our mandate. I do not claim to have written the penultimate guide to password security :)

Re: Q9. Again, that's a great pattern, but is not a requirement to not be on our list.

This is linked to from the non-dev FAQ, but I'll make sure to add a section about 2FA to the dev section.

Thanks!

[awsh]

You've got a typo in the link in dev FAQ #7. Main-In-The-Middle

[vadvi]

also this: "[...] or on how the can use them [...]"

[omervk]

Fixed. Thanks :)

[a1a]

>>(Question 5) What? No! Why use algorithms that have been broken for years? It’s ridiculously fast to break both, along with many other simple algorithms.

I'd remove the emphasized text. Yes they are vulnerable to collision attacks but that's completely irrelevant in this context.

[aturek]

I've been trying to learn the best practices on password "storage" and verification lately. I thought this was a really good step-by-step technical breakdown of the right way to hash passwords (I have no opinion/knowledge of the hashing algorithms in the article, but I've found a lot of other positive mentions of PBKDF2, bcrypt, and scrypt)

http://nakedsecurity.sophos.com/2013/11/20/serious-security-...

[blueatlas]

I was a bit surprised by #9.2 - "Don’t put any limitations on the passwords people can use (maximum lengths, disallowing certain characters, etc.)". What's the thinking here?

[furyg3]

If someone wants to use a 250 character truly random password with crazy characters, let them do it. If they used a long password with an excellent mix of upper-case, lower-case, and special characters, but no numbers, it's a good password, take it.

I had a password for a credit card account which could not be more than 8 characters and couldn't contain 'special' characters or punctuation. This was probably done to either make the password human readable (over-the-phone, horrible idea), or because of some legacy system on their end. At some point the organization got smart and made a minimum of 6 characters, of which two needed to be numbers (but kept the other restrictions). This effectively narrows down pool the possible passwords for an attacker to guess, the opposite of what you want to do.

[scrollaway]

What is the thinking behind disallowing certain characters? When you create artificial limitations you have to justify them, not the other way around.

[adwn]

> What's the thinking here?

I sucks for people that generate individual passwords based on a common password and site-specific data.

[user24]

Can't speak for OP, but surely putting restrictions on your password just makes people choose weird, eminently forgettable passwords, a la xkcd's complaint http://xkcd.com/936/

[jabbrwcky]

As the password should be stored as a hash anyway the actual length of the password does not matter as the hash length will be constant.

In the old days, if you stored the unencrypted password, it had to have a maximum length because somebody decided to make the db column 16 chars....

Same goes for charset limitations (e.g. try storing unicode characters in a database set to US-ASCII charset...) - with a hash your input does not matter - it is just a sequence of bytes that are hashed.

Lastly, the source of disallowing certain characters is the laziness of the implementers that couldn't be bothered to implement proper input encoding in their frontend

[Grue3]

In fact, very long passwords can be successfully used to DDOS some setups (i.e Django used to have such vulnerability). It's much simpler to put a sane upper limit, like 1024 characters.

[7952]

It is worth remembering that reset links should also be hashed. If the database is compromised the reset ID can be retrieved without needing access to the users email.

[bwy]

This isn't really addressing the main issue. You need to emphasize and just drive the point home that people should not even be STORING plain text passwords. Anywhere. Get them to understand that they don't want to, and shouldn't, know anyone's password in plain text, and how. It's a very counter-intuitive concept that makes sense once explained.

EDIT: Just saw @ajanuary's child comment on the top-voted parent. The point exactly.

[TallGuyShort]

This is really good, and I applaud your efforts in that site in general! My one suggestion would be to explain the term "representation" a little better to non-devs so they understand why the secure technique is secure. I like to use the term "one-way encryption" so that it's clearly not some simple derivation of a password, but a mathematical process with proven difficulty and uncertainty when reversing.

[pornel]

The dev FAQ perpetuates a common misconception about "broken" MD5 and SHA1.

MD5 and SHA1 are bad for password hashing indeed, but that's because they're fast, not because they have known collisions.

Collision attack has nothing to do with password security. For passwords the relevant attack is the preimage attack, which is a different thing and there are no feasible preimage attacks against these hashes (yet, of course).

[scrollaway]

Can you please look into Persona and recommend that instead of openid connect? It is a much better approach at decentralized authentication.

[omervk]

I have. Please take a look at another comment that explains the issues with it here: https://news.ycombinator.com/item?id=7943695

[mcovey]

instead of "shittysecurity.com" you might want to use something like "example.com", for one because some people will see it as inflammatory, and because some eager devs might be presenting this to bosses who will take offense, and based on that emotion, decide the whole thing is bullshit.

[philk10]

http://plaintextoffenders.com/faq/non-devs

"We explain in everything our About page." - doesn't read right, maybe 'we explain everything on our About page"?

"your post was deleted with prejudice" ?? needs rephrasing