Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

But why can't I send people their passwords?

news.ycombinator.com

Post reply on HN
Print view View original

131–140 of 181 posts

Re: But why can't I send people their passwords?

#131

Post by drewcrawford »

ajanuary wrote: post #109
makmanalp wrote: post #75

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 t…

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

Re: But why can't I send people their passwords?

#132

Post by masklinn »

huxley wrote: post #52
vomitcuddle wrote: post #34

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

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

Re: But why can't I send people their passwords?

#133

Post by Sami_Lehtinen »

jere wrote: post #5

> 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 y…

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.

Re: But why can't I send people their passwords?

#135

Post by ademarre »

cookingrobot wrote: post #74
jere wrote: post #5

> 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 y…

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.

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.

Re: But why can't I send people their passwords?

#136

Post by u124556 »

slight wrote: post #12
Mithaldu wrote: post #8

Earlier quoted context omitted.

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

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.

Re: But why can't I send people their passwords?

#137

Post by mechanical_fish »

herge wrote: post #70
mechanical_fish wrote: post #53

Earlier quoted context omitted.

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 rea…

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

Re: But why can't I send people their passwords?

#138

Post by troels »

sp332 wrote: post #44
troels wrote: post #15

Earlier quoted context omitted.

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

Re: But why can't I send people their passwords?

#139

Post by SkyMarshal »

jere wrote: post #5

> 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 y…

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

Re: But why can't I send people their passwords?

#140

Post by personZ »

grayclhn wrote: post #119
personZ wrote: post #89

Earlier quoted context omitted.

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…

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.

Post reply on HN