>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.
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 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.
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?
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.
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.
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."
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.
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'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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
>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.
"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.
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.
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.
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.
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.
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.
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.
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.