But why can't I send people their passwords? | Hacker News Reader

But why can't I send people their passwords?

201 pointsomervk174 comments

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

View on HN

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

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

This is certainly a good point.

Which is still true if you don't know their passwords but if you have their email. You can reset the passwords for just about every conceivable account they have.

If the password is in the email in cleartext, you don't need an active login for their email. All you need to do is be looking over their shoulder in the cafe, once, when they bring up the email on their iPad.

Given an uncertain amount of time. Your process requires access to their email account while you go through and reset all their passwords. Whereas if the passwords are in plaintext, you can download all their email and get access at your leisure.

Back when I was a teen I used to fraud people and scam ebay sellers through paypal. If I were to somehow gain access to an email (via RAT, Cookie hijacking), one of the easiest ways to recover a password was to look for a provider that sent out a plaintext password. Chances are the unfortunate target used the same password on every site (or if it was lowercase and alpha, that password + "1").

That would grant continued access to the email, and other sites that took protection a little more seriously like Paypal and Bank Logins (you can't reset a Paypal password with just an email, and if you could, such an action would make Paypal fraud detection software go nuts).

"Back when I was a teen I used to fraud people and scam ebay sellers through paypal".

Cool!

in which case they wouldnt be using the password reset mechanism

One scenario of many: The attacker has brief access to the email of the victim. Hacker resets the password and now has the password for all accounts tied to that email address.

You'd be giving the attacker the keys to the kingdom.

No, the people who use a common password gave out the keys.

There is simply no excusing it. The apologism for it has to stop. NEVER use the same password across multiple services. If one service gets compromised, the extent of their culpability is their own service. Anyone whose password exposes other things was the cause of their own demise.

EDIT: I will not back down from this (and you shouldn't feel too ashamed for reusing passwords and falling in the above buckets, desperately hitting down arrow. Just correct your mistakes). It is utter idiocy to constantly defend the habit of shared passwords, when people give it to services of zero trust, and with unknown habits and practices. When some service of no consequence stores your password in plaintext, that is them being dumb. If you then complain because it's the same password used elsewhere, that is you being dumb.

I'm not going to presume to know anything about you, but as soon as your system interfaces with human beings, your system needs to adapt to human nature. You can't say "there's no excusing it" and "cause of their own demise". Humans act as humans tend to do - why should the security of your system rely on humans changing their natural behavior?

You can't say "there's no excusing it" and "cause of their own demise".

Yes, you absolutely can and should say that. This isn't human nature, but is simply accepted and defended behavior that gets caught out again, and again, and again. I have absolutely no doubt that many visitors to HN are guilty of this, and instead of confronting the reality of their insecurity, pretend it's someone else's fault.

Each time some random, irrelevant message board has a password exploit, everyone who should know better rushes forth to pillorize the operator because of the greater danger, yet the operator may have been sharing those passwords on the black market for time eternal. The operator may have been putting their plaintext backups on a compromised FTP site for years. They may have engaged endless contractors who made their own backups and are busy buying stuff on Amazon for it.

But instead we argue pretend security measures, when the horses have not only bolted, they're several states away.

It is complete idiocy to use passwords across services. Utter insanity. It is the worst possible practice imaginable, and is never, ever excusable.

If you used the same password across sites, you simply must assume that since day one it has been compromised, and it is your own doing.

But here we excuse it. And then, in excusing it and defending it and supporting it, claim that it's "human nature". It isn't human nature at all.

How To Hack 60% of Hacker News: Create a service requiring users to create logins, submitting it as a show HN. Harvest email/passwords from very foolish people and enjoy their access everywhere else.

I agree with you - using the same password in multiple places is a dumb thing to do. However, you seem to be totally missing the point made in the previous post, namely that people are, on the whole, pretty dumb. The vast majority do not share your understanding of computers and security and hence see no real issue, although this is very very slowly changing.

I disagree entirely with your statement that: "This isn't human nature, but is simply accepted and defended behavior that gets caught out again, and again, and again."

This is patently false - remembering a different password for every single system, device and site you interact with is not a feasible proposition for the vast majority, especially if you require these passwords to be in any way meaningfully secure.

There are ways of sidestepping this problem, such as 1password and the like, but the ones that are most seamless are paid for services and hence the adoption rate among technically illiterate people is pretty small (I'd imagine, no stats here).

The real issue is that passwords are a broken way of authenticating. End of. Passwords that are easy to remember are trivial to crack, and passwords that are difficult to crack are hard to remember. This is the issue here.

People may do dumb things, but it is far easier to change your system than it is them.

However, you seem to be totally missing the point made in the previous post, namely that people are, on the whole, pretty dumb.

The whole discussion revolves around a fundamental principal that is simply broken to begin with, akin to "How to try not to die when you eat rotting meat".

Don't eat rotting meat. Use a fridge. Etc.

In the case of passwords-

-Use a shared authentication platform -or on sign-up implore that your users do not use a shared password. Education -or offer, or force, a generated password

But instead we'll discuss the risk that shared passwords get lost, when they were in the wild the moment you used them on a second site.

This is a disingenuous analogy - the reason people keep eating rotting meat is because there isn't a usable alternative for the vast majority. Fridges are unknown, to hopelessly overload the metaphor, to the masses and those that are aware of them are reluctant to shell out for the cost.

The problem needs to be solved at a more fundamental level - people should not have to be forced to perform a function that they are demonstrably bad at. Mitigation strategies like having randomised passwords and storing them in a shared authentication platform are only masking the reality that passwords are a bad way of performing authentication.

Not that I'm clever enough to come up with an alternative mind you, and not to suggest that I don't agree with your premise that using a password in multiple places is a bad idea.

I love this analogy. But, to continue it a little further, the article and discussion are about "preventing meat from rotting during transportation," and you seem to be saying, "screw it, the customer should know not to buy the meat if it's gone bad." Going even further: most countries have consumer protection laws that prevent things like selling rotting meat.

and you seem to be saying

If you have given an untrusted third party site the credentials that you use on other sites, that meat is complete fetid. It is now deadly.

This whole discussion is arguing about what to do once the meat is rotten, rather than daring to maybe discuss not selling rotten meat in the first place.

When a site gets compromised and the passwords may get stolen (because of weak or no cryptography), the site should send out password reset emails en mass, and that should be the end of the whole issue. Instead it's moralizing about how they put everyone at risk because of other sites where the same credentials work. No, the user put themselves 100% at risk. But it is never discussed that way, and instead we continue this ignorance train.

As an aside, I marvel that some defensive imbecile keeps coming deep into this thread to downvote me.

> As an aside, I marvel that some defensive imbecile keeps coming deep into this thread to downvote me.

Comments like this are the "rotting meat" of Hacker News. Please just leave them out of your posts.

Ignorance and the defense of the same is the rotting meat of Hacker News. This whole discussion is absolutely rife with it.

It is complete idiocy to use passwords across services. Utter insanity. It is the worst possible practice imaginable, and is never, ever excusable.

It's one thing to argue for improving people's password practices, but please don't pretend that there's no reason for their behavior. The vast majority of people who share passwords between sites experience no repercussions from their choice. And choosing not to create a new password for every site saves them time and potential frustration.

That's the human nature part, to assess the risk of behavior and change it only if future experiences show that the costs associated with that behavior are too high. Since most people don't experience the disadvantages and do experience the benefits this behavior continues.

We can encourage more people to avoid this behavior by explaining the potential impacts and providing accurate estimates of the risk they're taking. We can offer alternatives to password reuse, like using a password manager. But ultimately they are still going to weigh their perception of the risk and benefits to make their own decision.

The vast majority of people who share passwords between sites experience no repercussions from their choice.

More accurately, they have no awareness of the reprecussions from their choice. Yet endlessly on HN we hear stories of mysterious iTunes access, Steam takeovers, even Amazon AWS account compromises. It is no big mystery when this happens given this common, grossly insecure behavior.

But ultimately they are still going to weigh their perception of the risk and benefits to make their own decision.

I absolutely agree, absolutely and completely, but think that the risk portion is hugely underestimated. Among people who should know better there is a tendency to under-estimate what is an enormous, worst-possible-exploit problem. No one ever talks about education. No one wastes time trying to help users enjoy better behavior.

Instead we argue about whether some site operated by an unknown number of people of unknown trustworthiness, on a platform that might have been exploited and owned by hacker groups for years, properly hashed our password after we passed the keys to all services through plaintext. It is insanity.

I'm a software developer, but I'm done trying to remember passwords for every single site.

What do I do?

I just don't use the sites.

I've restricted, and continue to pare down, the sites that I use on the internet.

It's the truth.

I do keep my amazon.com account, so I can order paper and cardboard books the local bookstores don't carry, and read them on the sofa at my house, next to my floor lamp.

there is a few solutions. use a password manager like lastpass or keepass or something like that. it generates passes for you and you don't have to remember them.(bonus: it logs you in automatically if you go to the vault and click login)

use throwaway passwords for one off services and just use the password reset feature when you want to use it.

Except, well, I use several computers, plus smart phone.

lastpass works on all of them.

I re-use passwords, but only for things I don't care about.

Not everything is critical, if someone gets into my HN account, for example, I'm not too fussed about it. It sucks, but whatever.

If someone gets into my bank account... different story.

It isn't that people re-use passwords that's the issue, it's that they do it for shit that actually matters.

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

  - Request password reset.
  - Sniff email with reset link.
  - Go to reset link before user does and change password.

That will work, however it will also leave the user with a clue that their account may have been compromised. It is also a noticable degree harder to pull off than simply sniffing a password being sent, due to needing to know the target's data necessary to request a reset.

The key difference is that capturing a plaintext password means the user and attacker both share a password without the user realising, while capturing a reset link means that one of them will win and the other will observe their password reset has failed.

Hence our mentioning that the user must receive a mail notifying of the password change.

It would be better if the website allowed the user to set the new password first and then send an email to confirm the password change.

Entire clear text emails. Everyone SHOULD be using TLS wrapped email protocols. That doesn't mean they are, but gmail is https all the way and many providers now require TLS connections to the mail servers.

Still, one time use password reset links with explicit instructions and set expectations to reset the password immediately is the way to go if you're emailing anything IMO.

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?

I have never thought of that, ever. I'm not being sarcastic. Usually I think of email as existing on some secure server, I never thought that backups are kept, maybe in a different medium which is then open to vulnerabilities.

It is frighteningly common to neglect backups when thinking in security. I have seen a couple of examples where the technical aspects of security with good firewalls, good access control to servers and so on were in place, but backup media could still be found laying around for everyone to grab.

This is why, for example, Amazon S3 has a little checkbox on each bucket to encrypt the contents of the bucket.

At first glance this might seem a little silly. Amazon has the key. (You don't even get to see the key yourself.) So Amazon can read all your data. And every time you read from the bucket it's automatically decrypted, so the encryption won't protect you from anyone who has somehow achieved permission to read your data.

But that's not the point. The point is to protect against attacks like "I found this pile of dusty drives stacked in the maintenance closet at Amazon," or "I went digging in the local dump near an Amazon data center and unearthed this hard drive, and look what I found backed up on it."

I'd even make the effort of encrypting yourself any data you want to protect that you send to s3. GnuPG is not that hard to use with RSA.

Yeah, I go back and forth on that one. The problem is that the key management is crucial. Slip up and lose your key and your data is toast. Obviously this also applies to Amazon, but they have more resources, better incentives, and one million times the operational experience with their key management system than I'll ever have with mine. Frankly, my clients should bet on them over me.

Now, one good idea might be to redundantly back-up Amazon's backups at some other host, using GPG to encrypt those. This ensures against Amazon encryption errors, billing errors, mistyped legal injunctions, Jeff Bezos declaring you his personal enemy, et cetera.

This may be obvious, but rolling my own at-rest encryption is not going to significantly protect my data from an attacker who works inside Amazon, nor from an attacker who roots my instance. If the keys are in the cloud, the keys are in the cloud.

UPDATE: oh, yeah, I forgot the use case where you are writing to s3 from outside Amazon's datacenter over HTTPS. Okay, that is a much stronger case for GPG in advance. It wouldn't matter if we assumed that TLS always worked. But this is TLS. Does your upload client check the certificate chain? So many of them do not. I sure hope Amazon's CLI client does.....

I just recently got this email from AWS:

Dear Amazon S3 Customer,

Amazon S3 now supports server side encryption with customer-provided keys (SSE-C), a new encryption option for Amazon S3. When using SSE-C, Amazon S3 encrypts your objects with the custom encryption keys that you provide. Since Amazon S3 performs the encryption for you, you get the benefits of using your encryption keys without the cost of writing or executing your own encryption code.

Wait. how exactly do you transfer the encryption key to amazon?

And do they keep your key?

How long?

Presumably another key?

Look, it's keys all the way down.

Beneath that, wiretaps.

I'm not even giving a hypothetical scenario. It's no longer fresh in the minds of most people but years ago Reddit used to store their passwords plain text for the convenience of being able to send them to the user, instead of implementing a password reset mechanism. One day their hosts backup tapes were stolen out of the back of a truck. Now they salt+hash their passwords.

Thanks, I've added that to the FAQ. :)

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.

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.

And if someone hacks the system administrator's account, they may find everyone's passwords (for systems where the admin sets the pw and emails it).

You're current password shouldn't stop working because otherwise that can be used as a denial of service without otherwise compromising the security of either the user or the site if the email address is known.

Obviously it shouldn't stop working straight away, but presumably an attacker would actually use the password reset code, at which point they would set your password to something else, which you would notice.

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.

Exactly. This action is so obviously horrendous it's had to believe it still happens. Once a password hits your inbox, you can almost count on it living forever. And Basically with one 5 second search of my inbox for "password" a thief could easily discover my password that I use for almost every web site.

It's totally irresponsible for a service provider to essentially reveal a secret like that (without asking or really, ever).

Does none of that responsibility lay with you for using the same password across all sites? What if, on the other side of the spectrum, their site was compromised, and your password was retrieved that way? You'd be vulnerable in the same way.

I think people are learning about password wallets. My mom, wife, and kids (12 and 9) all use and understand the value of password wallets.

If google really does get in-browser crypto working, they might even understand pgp. They won't understand Diffie-Hellman, but they understand if words --> block of gibberish --> words, then there must be some math in between.

Blaming the victim. Yes of course, but no, not reasonable to expect users to be smart about passwords in general.

I don't mean to exclusively blame the victim, but you can only go so far to protect a user if they won't protect themselves. I haven't read through the suggestions on the site, but it seems like this should be the primary -- as a user, you need to take care of your own safety and not rely on good development practices to protect you.

You just blamed the victim. Again.

My comment implied that I was. I said it's not exclusively their fault, implying that it is partially their fault. In the case of reusing the same password between sites, the blame for reusing that password does lay with the victim. That's not to say that sites should be sending the password to them -- that's still a horrible idea. A site cannot prevent a user from reusing the same password, though.

I guess what I mean to say is that you need to play both sides of it. As a developer, you should be doing all you can to prevent anything from leaking user info. As a user, you should do anything you can to prevent leaks from one site affecting other parts of your internet identity. Isn't that the entire goal of the FAQ this guy is putting together?

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

Using personal questions for security is the worst thing ever.

Whenever I encounter them, I paste the output of "dd if=/dev/random bs=1k count=1 |uuencode x" into the field.

If you can use Facebook and Linkedin to hack someone's bank account you know that this is a bad idea. What's that, the make of your first car and the name of your first boss are actually freely posted on the Internet? You don't say.

I can never remember the answers to those damned things.

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.

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

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: evil@example.com', 'Run on all messages'.

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

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

Yeah, I was surprised to see that this bit wasn't mentioned anywhere. If you are emailing someone their password in plaintext, that means you know their password in plaintext -- which you should not.

You do when they first create it.

And every time they enter it to log in, up until the moment when it's hashed and (maybe the memory is overwritten with zeros before being) garbage collected.

That's not quite true, most random web services send out the welcome email from the same page that just hashed your password so during email creation they still have the plaintext copy around even though it dies after the request ends.

Yes, that's in the FAQ too.

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.

The "log in again to do something secure" is a rabbit hole, where suddenly you have to log in again to do anything it all. It could become a login nightmare.

Only if 'something secure' is defined overbroadly. Using Amazon, as an example, I can idle my session indefinitely, and when I return, it will even allow me to do potentially secure things like browse my order history, look at my account details and such, but before I order something, or change my password, it prompts for a login, except where I've just recently logged in.

There's a balance to be had, and while admittedly, getting the details right is tedium and minutiae, it can be done, and done right.

I expect people would not understand this. They would start to get confused between their Google password and that of the service they are trying to access.

Also, after users learn the new process, it opens up a new phishing attack vector for Gmail.

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.

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.

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

Clickable links:

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

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

Good idea. Implemented.

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

Ack, I accidentally down-voted this comment, someone please right my wrong

I think Django's method is a good one to emulate:

https://docs.djangoproject.com/en/dev/topics/auth/passwords/

A list of password hashers, on successful login the user is upgraded to the top password hasher. Makes it very simple to switch to a new scheme or work factor.

Outside Django, if you're using Python, there's no excuse to not use passlib[0] whose cryptcontext object[1] handles this situation fantastically: create a cryptcontext with all the hash types you accept as input, and put any "old" hash in the `deprecated` list (or just set `deprecated=['auto']` in 1.6, it'll deprecate any non-default hash — the default hash is the first of the list, or the one passed as the `default` parameter). Then you can just use the relevant method to know that the authentication was successful and you should update the in-db hash:

    hash = CryptContext(
        # upgrading from an md5_crypted system
        ["sha256_crypt", "md5_crypt"],
        deprecated=['auto'])
    
    # in auth code
    valid, updated = hash.verify_and_update(password, current_hash)
    if not valid:
        # error out
    if updated is not None:
        # updated is the new hash to set in database

[0] https://pythonhosted.org/passlib/

[1] https://pythonhosted.org/passlib/lib/passlib.context.html?hi...

That's a good point, but I think it goes a bit over what I was getting at.

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

Lol, my dad is an endodontist and he hasn't made his website interactive (patient accounts, interactive appointment scheduler, interactive referrals) yet because he can't afford a webdev that would make it secure (salting/encryption).

My dad is an endodontist with zero software/web experience and even he knows not to keep passwords in plaintext and to use ssl.

I'm only a CS undergrad and I'm learning webdev so I can implement it for him but I still know to hash and salt your passwords. The fact that people implement these critical systems (and get paid for it) without knowing basic practices makes me worry about the future.

My 401K company, Kibble & Prentice, does the same thing. They make you call a phone number if you forget your password, and then the operator reads the password out loud to you over the phone. Freakin' amazing. I told HR and they said they'll change companies, but that was six months ago, so... who the hell knows.

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.

Thanks, I've added wording for that.

I prefer makmanalp's explanation to the wording you are using right now. It emphasizes that hashing is an one-way operation and "encryption" or "scrambling" are more familiar and less abstract than "representation". I know its not an accurate usage of the terms but this is the layman FAQ and we could always add a link to a more in-depth explanation using the correct terminology (hashing, salts & key strength).

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.

I like this description. I don't know that you need to explain hashing to laymen, though. Hand-waving is acceptable when communicating to people who aren't skeptics (laymen). If they're really interested in fact-checking you, they can do so on their own time, or you can provide links to detailed explanations.

"It is possible to store passwords in a way that the website cannot see your password, but can still verify that a password entered by you checks out." (trust us, after all you're trusting that we know what we're talking about by reading this stuff)

I think this is easier than it sounds. To a layman, when they type in their password, they are not thinking about how it would be implemented. The idea that "oh, somebody is doing a string compare against a password in the database" is not something that would enter their mind. That is baggage that software developers may have, but ordinary people have not been primed in that way.

Ordinary people are going to be thinking about a key in a lock. Does the lock on your house store the key inside? Maybe in some kind of information-theoretic sense but in the ordinary meaning of the word, no, it has a representation (that may not even be sufficiently specific to recover your key exactly). And if you lose your key you don't break into the lock to recover it--you call a locksmith to replace the lock, and get new keys.

That right there is an intuitive understanding of both hashing and good security principles that goes surprisingly far.

Absolutely. I wasn't really clear. I didn't mean it needs an explanation of hashing. I meant there needs to be some short answer to the question of "if they can't pull out my password, how do the check it?"

I don't think people are thinking about keys and locks. Passwords are a thing that existed before computers and that people understand perfectly outside of an IT context. Spies in films use secret phrases to prove they're the contact, kids use passwords to gain access to the clubhouse. But in all these non IT contexts the person checking the authentication knows the shared secret, so it's obvious how they check it.

If my mental model is "I've arranged a secret password with this website that proves I'm really me", then my first question when told the website doesn't know what secret password is "well how does it know that the password is correct?".

The best I've been able to come up with today is a somewhat lengthy metaphone with color mixing.

[Edit] Having said that, I just went and talked to my technical literate non programmer wife and she used the key and door analogy.

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.

Thanks for the feedback. I went back to the article (which we started linking to a couple of years ago) and saw the comments and, along with what you wrote here, removed the preference of scrypt and PBKDF2 over bcrypt.

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?

It's a good thought, but the FAQ starts with what we are, why and how to contribute.

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.

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!

Re: Q9, you could at least put in a link to zxcvb[1] so that they can be aware that it's an issue and that there's libraries for implementing it.

[1] https://tech.dropbox.com/2012/04/zxcvbn-realistic-password-s...

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

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

Fixed. Thanks :)

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

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

I'd appreciate it if you could post this as a comment to the Dev FAQ page :)

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?

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

There was a discussion here a while back on this matter, where I held very much the same position as you. The other guy convincingly proved that adding the "must use at least one each of these character classes" barely reduces the password space, while promoting increased password complexity for those people who would pick the _really_ easy ones.

What if I want my password to be "one small step for man one giant leap for mankind" (or something less known)? Do I really have to put a dollar in that to make it secure?

Teach good password hygiene. Use keepassx. Use decentralized third party authentication with providers that know what they are doing and use 2FA and such!

But password restrictions achieve very little. Let people use their 12345 if they really want, they won't learn by watching the stove but by touching it. Some people are like that and we should educate, not babysit.

Well the other part of weak passwords is for many websites the users care less about account security then the website operator.

There are many sites which contain none of my personal info but I have to setup an account just to view website content. If my account gets hijacked, it might be used for spamming. But still If I could make a throwaway account with a blank password I would because I don't care about that accounts security. So surely some restrictions need to be in place if you're going to require signups.

Perhaps it's better to suggest using at least one capital, one number and one symbol. You can warn a user that their password doesn't use those and remind them to make it long and not a mere short colocation of dictionary words but ultimately - unless it's risking other's security - you can let them set any password they like?

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/

> What's the thinking here?

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

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.

While it's true their changes made the key space smaller and, even with a good KDF, 8 chars was never long enough to begin with, the reduction is negligible. Assume 36 char (alphanumeric, case insensitive) passwords:

Originally:

    36^8 + 36^7 + 36^6 + 36^5 + 36^4 + 36^3 + 36^2 + 36
    2,901,713,047,668 possible passwords
    ~41.4 bits

After:

    (36^8 - 26^2 * (8*7)/2) + (36^7 - 26^2 * (7*6)/2) + (36^6 - 26^2 * (6*5)/2)
    2,901,650,810,624 possible passwords
    still ~41.4 bits

Only 62,237,044 possibilities eliminated. Length is the most important factor, so this was probably a good decision if most of their users were using <= 6 char passwords, or not using numbers at all. And frankly, the financial sector should be using HSMs anyway, making weak KDFs irrelevant.

Making the minimum password length 6 characters reduces the possible outcomes by a negligible ammount.

Have fun running bcrypt on 100TB of /dev/urandom. Insanely large password limit? Sure sounds like good business to me. No password length limit? Sounds like a DOS attack waiting to happen.

What would you suggest as a sane upper bound?

No idea, especially as pass phrases have become more popular the max length of a password that you might see in the wild has gone up quite a bit. Lets say someone is willing to type for 1 min to login to a site. According to Google the fastest typing speed recorded is 216 words per min. According to the words per min Wikipedia entry a "word"(They give examples of "I run" counts as one word, but "rhinoceros" counts as 2) is 5 characters long so that gives us a max password length of 1080 characters. According to wikipedia War and Peace is just shy of 600 thousand words long or approximately 3 million characters.

Therefore 1000 is a good minimum max length but 3 million is way to long.

const int PW_MAX = strlen("correct horse battery staple")

You're probably good with 1k FWIW Django added a 4k limit (4096 bytes) last September: https://www.djangoproject.com/weblog/2013/sep/15/security/

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

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.

Thanks, I used your number, too. :)

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.

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.

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.

I thought of my mom and dad reading this and what they would best understand. I'm worried using something like "one-way encryption" would have their eyes glaze over :)

Probably. What about something to the effect of just adding, "The representation is created by shuffling and encrypting the password over and over so there's no way to reverse the process" or something like that?

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

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

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

I had already replied to that comment.

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.

Good point.

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

1. You're right. Fixed.

2. Rephrased.

Thanks for doing this, it is greatly appreciated. The list of offenders with screenshots is nice, but what would be really useful is a table that is sortable and filterable so that people (i.e. me) can find out if any of our vendors are offenders. Also, a JSON API would be slick too. Just ideas.

Soon :)

Let's say I register for a Web Hosting solution. And then I receive a email containing a username built upon the information I gave them and a generated password to access the cPanel.

Is this offending? Let's also pretend that I have to change this password upon my first login.

Yes, because you might not be the first to use that password.

For [11]: I think it makes sense to also highlight other approaches than OpenID such as https://passwordless.net which is a sort of way in the middle (disclaimer: I'm the author)

As a huge supporter of Persona, I am intrigued. Can you sell me on how this may be better?

I think Persona is great and can be the right choice for many scenarios. Browser support, the JS requirement, and the reliance on email (whereas tokens can e.g. be distributed via text message) might however be points that convince developers to go with one-time passwords.

> Browser support

Persona is just a protocol though, it's implicitly supported by all browsers. Though in-browser auth (which is the ideal case) is only in Firefox so far...

> JS requirement

Granted. Though theoretically, you don't need javascript.

> reliance on email

Granted again, but this is a completely acceptable tradeoff for 99% of services which will require an email and usually even use it as the user's identification.

Still not sold, but I'll keep your solution in mind. Thanks for alternatives! :)

Also, Persona still relies on passwords which are usually too weak and re-used across the web

No, Persona does not rely on passwords. Persona has authentication providers that rely on passwords.

Depends on the email address you use :-) Gmail, etc. are directly supported - for any other email provider (or your self-hosted one) you'll need a password.

Added. Thanks :)

Creating an FAQ for these companies would be useful.

Something to arm the devs who work at these places with something when they go to management who's reaction is "yeah I know it's bad.. but... like, we have important shit to do."

What would you suggest?

Assume the company is unaware that their developers have implemented the password this way. The FAQ for the company should highlight the exceptionally high cost of losing customer data, the distraction for their team from dealing with any breach, and the incredibly low cost of making the fix. The call to action could be for them to email their developer a link to your dev FAQ, demanding a fix.

That's a great idea! I'll add "I've been listed! What do I do?" to the FAQ. Thanks!

Wow, thanks for all of your points and suggestions! Unfortunately, I'll only be able to attend to them in an hour or so, so please bear with me and I promise personal attention to each any every point made here.

This is something that came to mind while reading the comments: Why should me, the owner/developer of some service, care if somehow your password is stolen/guessed by any mean?

I'm not saying we shouldn't take care of our users, but how's our fault that their email is hacked? We can't do anything to protect against this and placing more complex policies would hurt users who have enough common sense to this properly and expecting the same from us.

P.S. I'm in no way saying to to ditch all security procedures we can, but to one point security is about trust, and if you can't trust your users to keep their freaking passwords and email accounts secured, then hell with them. Put it in plain text in your TOS and be done with it.

Do you have any idea how email works?

You could as well just publish your users passwords at your front page, and claim that if a user has a password compromissed because of that, it's his own fault, you should be able to trust them not to use insecure services.

Because then users would lose faith in your service? Also, your service can then be abused. Think about a hacker ramping up charges on a credit card, only to have fraud detection activated and you losing money (and getting worse rates in the process).

And when your server is inevitably compromised and your users passwords stolen from you due to your lack of dillgence and used to compromise logins on other services, what then? Still their problem?

You shouldn't be able to see their passwords in the first place, let alone send it to them. You should only store a one-way encrypted string based on the password they typed.

I don't see how sending a reset link is secure.

Wouldn't anyone intercepting the email be able to use the reset link themselves and gain access to the account?

Reset links can at least time out, passwords generally don't.

Providers should send you notifications when you reset your password, they generally don't when you just log-in like normal.

Or don't use passwords? https://launchkey.com

I'd appreciate it if you could post this as a comment on the page itself. :)

Is a plaintext (heh) list of all the sites available?

Soon :)

I disagree with point 11. You shouldn't rely on someone else's service to be the way for users to access yours.

It's pretty hard not to though. You rely on your hosting provider for service and probably on a multitude of software services too. Of course you have to weigh the value of each further point of failure in your setup, but it's a tradeoff and may well be worth it.

Yeah, but I can switch hosting providers. What happens when I switch login providers?

Valid point. Still - that doesn't categorically make it a bad choice. It just weighs a bit heavier on the con side. There are some positive effects of that dependency as well (User trust and convenience).

Actually, that FAQ entry itself already counters your argument: "Treat it like you would payment - you wouldn’t write a whole payment gateway like PayPal - but instead use a 3rd party." Where's the difference?

By the way, you can always allow users to connect several OpenIDs to a single account – this way, worried users can provide redundancy themselves, if desired.

Reply on news.ycombinator.com