8 ms·

A secure website should be mathematically incapable of ever displaying your plaintext password in any form whatsoever, at any time, even during the registration

A secure website should be mathematically incapable of ever displaying your plaintext password in any form whatsoever, at any time, even during the registration process.

derefr 16y ago
If you have a public key associated with your email address on a public keyserver, they could encrypt your password—using said key—when you set it, and then store only the encrypted copy. Then, even though they were holding it, the only person who could do anything with it is you :)
- zacharypinter 16y ago
  That should address their accessibility concerns :)
- joe_the_user 16y ago
  Uh... The standard, minimal approach is to keep secure hash of each password and throw away the password itself. This has the same effect but doesn't require the average, unsophisticated user to have a public keep. But that's just the bare minimum approach - from there, you add a "salt" and other things. Done well enough, you should have a system where downloading your entire system shouldn't compromise your users passwords. But that's only if this is done really well - the write-up for how hbgarey got hacked actually is a great intro to this kind of thing. http://arstechnica.com/tech-policy/news/2011/02/anonymous-speaks-the-inside-story-of-the-hbgary-hack.ars/ http://arstechnica.com/tech-policy/news/2011/02/anonymous-sp...
  - derefr 16y ago
    My point was that you can retain the ability to email the user their own password with no loss of security (provided the user has a public key—like, say, Github or Heroku require, as they use passwordless ssh for repository synchronization.) My point was not that keeping someone's password around, is any better an idea than just allowing them to reset it :)
archivator 16y ago
How so? You can easily send out an email with the plaintext password, hash it and store it securely from then on..
- JonnieCache 16y ago
  True, but this would imply that the plaintext password would be passed around the application's internal infrastructure. Instead of just going into the frontend server, being hashed and then discarded, it would have to be passed to the email server, probably via some sort of message queue. This means the plaintext passwords would have to reside in some kind of datastore temporarily, possibly for quite some time if there is a backlog of registration emails. This means you have to encrypt that store, which means you have to decide if you want to force EVERY email sent through the queue to adhere to the same security standards or just registration emails. Then you have to manage the keys for that encryption, and you have to audit it, blah blah blah blah, it quickly adds up to many many man hours of work. All this just makes the whole thing more insecure, it increases the attack surface, and increases the work needed to secure the system and keep it secure. As it is not really necessary, IMO it shouldn't be done. This also includes displaying the password back to the user in the browser, the plaintext password should be gone from memory before the templating engine is even invoked. The best way to solve problems is to simply avoid them. Maybe I'm being unnecessarily paranoid, I like to think of it as a "security mindset" :)
- colinhowe 16y ago
  What if you log all sent e-mails?
  - alinajaf 16y ago
    Then you have a great big log full of passwords, pretty much negating any security benefit of hashing them in the first place.
mootothemax 16y ago
By that logic, how should the website know what password it should be hashing?
- lkozma 16y ago
  The hashing should be done in the client's browser. The plaintext password should never reach the server (which is capable of sending emails).
  - karanbhangui 16y ago
    wut.
  - tedunangst 16y ago
    Actually, I think "wut" was a reasonable response. If the browser hashes the password, that just makes the hash the plaintext password. You've accomplished nothing.
    - scott_s 16y ago
      Not necessarily, if I understand the situation correctly. In this notation, -> represents communication between components, and | represents the boundary between local and remote communication, which we assume is encrypted/decrypted appropriately. On account creation, password -> hash -> | -> stored Upon account creation, I provide my password, which is hashed locally. The hashed version of my password is passed over the network and stored on the other end. Logging in, password -> | -> hash -> compare Upon logging in, I provide my password and send it to the remote server. The remove server hashes my password and compares it to what it stored previously. Hence, if someone intercepted my hash, it's the same situation as if they looked in /etc/passwd on a multi-user Unix system. That is, it's more information than nothing, but it's non-trivial to use that information to figure out my password. Is there a flaw in my reasoning?
      - stipes 16y ago
        This increases the password space (assuming a cryptographically strong hash), but if the datastore is compromised, an attacker can just bypass the client hashing (by changing JavaScript, etc) and just pass in the hash itself.
Travis 16y ago
How about this use case? You need to assign a password to a specific user account (they aren't registered, but are seeded into your system). I work on 3 different projects right now with this requirement. In this case, we create accounts for people based on a data pull from another agency, then contact those folks. I generally agree with you (and plenty of fish is scary how they mail your pass every week or so!), but there are use cases where displaying cleartext passwords is acceptable.
- vog 16y ago
  > but there are use cases where displaying cleartext passwords is acceptable. The only use case where sending and displaying cleartext passwords is acceptable is when the password is auto-generated and very long. In all other cases, especially if the password has been entered by the user, this behavior is not only unacceptable, but also unexpected and thus the exact opposite of user-friendliness.

A secure website should be mathematically incapable of ever displaying your plaintext password in any form whatsoever, at any time, even during the registration process.

derefr 16y ago

If you have a public key associated with your email address on a public keyserver, they could encrypt your password—using said key—when you set it, and then store only the encrypted copy. Then, even though they were holding it, the only person who could do anything with it is you :)

zacharypinter 16y ago
That should address their accessibility concerns :)
joe_the_user 16y ago
Uh... The standard, minimal approach is to keep secure hash of each password and throw away the password itself. This has the same effect but doesn't require the average, unsophisticated user to have a public keep. But that's just the bare minimum approach - from there, you add a "salt" and other things. Done well enough, you should have a system where downloading your entire system shouldn't compromise your users passwords. But that's only if this is done really well - the write-up for how hbgarey got hacked actually is a great intro to this kind of thing. http://arstechnica.com/tech-policy/news/2011/02/anonymous-speaks-the-inside-story-of-the-hbgary-hack.ars/ http://arstechnica.com/tech-policy/news/2011/02/anonymous-sp...
- derefr 16y ago
  My point was that you can retain the ability to email the user their own password with no loss of security (provided the user has a public key—like, say, Github or Heroku require, as they use passwordless ssh for repository synchronization.) My point was not that keeping someone's password around, is any better an idea than just allowing them to reset it :)

archivator 16y ago

How so? You can easily send out an email with the plaintext password, hash it and store it securely from then on..

JonnieCache 16y ago
True, but this would imply that the plaintext password would be passed around the application's internal infrastructure. Instead of just going into the frontend server, being hashed and then discarded, it would have to be passed to the email server, probably via some sort of message queue. This means the plaintext passwords would have to reside in some kind of datastore temporarily, possibly for quite some time if there is a backlog of registration emails. This means you have to encrypt that store, which means you have to decide if you want to force EVERY email sent through the queue to adhere to the same security standards or just registration emails. Then you have to manage the keys for that encryption, and you have to audit it, blah blah blah blah, it quickly adds up to many many man hours of work. All this just makes the whole thing more insecure, it increases the attack surface, and increases the work needed to secure the system and keep it secure. As it is not really necessary, IMO it shouldn't be done. This also includes displaying the password back to the user in the browser, the plaintext password should be gone from memory before the templating engine is even invoked. The best way to solve problems is to simply avoid them. Maybe I'm being unnecessarily paranoid, I like to think of it as a "security mindset" :)
colinhowe 16y ago
What if you log all sent e-mails?
- alinajaf 16y ago
  Then you have a great big log full of passwords, pretty much negating any security benefit of hashing them in the first place.

mootothemax 16y ago

By that logic, how should the website know what password it should be hashing?

lkozma 16y ago
The hashing should be done in the client's browser. The plaintext password should never reach the server (which is capable of sending emails).
- karanbhangui 16y ago
  wut.
- tedunangst 16y ago
  Actually, I think "wut" was a reasonable response. If the browser hashes the password, that just makes the hash the plaintext password. You've accomplished nothing.
  - scott_s 16y ago
    Not necessarily, if I understand the situation correctly. In this notation, -> represents communication between components, and | represents the boundary between local and remote communication, which we assume is encrypted/decrypted appropriately. On account creation, password -> hash -> | -> stored Upon account creation, I provide my password, which is hashed locally. The hashed version of my password is passed over the network and stored on the other end. Logging in, password -> | -> hash -> compare Upon logging in, I provide my password and send it to the remote server. The remove server hashes my password and compares it to what it stored previously. Hence, if someone intercepted my hash, it's the same situation as if they looked in /etc/passwd on a multi-user Unix system. That is, it's more information than nothing, but it's non-trivial to use that information to figure out my password. Is there a flaw in my reasoning?
    - stipes 16y ago
      This increases the password space (assuming a cryptographically strong hash), but if the datastore is compromised, an attacker can just bypass the client hashing (by changing JavaScript, etc) and just pass in the hash itself.

Travis 16y ago

How about this use case? You need to assign a password to a specific user account (they aren't registered, but are seeded into your system). I work on 3 different projects right now with this requirement. In this case, we create accounts for people based on a data pull from another agency, then contact those folks. I generally agree with you (and plenty of fish is scary how they mail your pass every week or so!), but there are use cases where displaying cleartext passwords is acceptable.

vog 16y ago
> but there are use cases where displaying cleartext passwords is acceptable. The only use case where sending and displaying cleartext passwords is acceptable is when the password is auto-generated and very long. In all other cases, especially if the password has been entered by the user, this behavior is not only unacceptable, but also unexpected and thus the exact opposite of user-friendliness.