4 ms·

Server knows the plaintext password already, too. Servers should NOT be storing passwords in plaintext, ever. This has been clear for at least 20 years now.

Server knows the plaintext password already, too. Servers should NOT be storing passwords in plaintext, ever. This has been clear for at least 20 years now. You should only store a salted hash of a password, and please, do not roll your own. Use one of the many popular libraries for this.

megous 5y ago
Servers routinely handle plaintext passwords when authenticating. They may not store it, but it's not something that is invisible to them, unless using some auth method that uses challenge/response instead of plaintext passwords. Most web apps use plaintext password auth.
- Kwpolska 5y ago
  There is a difference between the plaintext password being stored in memory and in a database. One is just how things work (the client browser needs the password in plaintext as well), and another is a security breach waiting to happen.
  - adolph 5y ago
    > There is a difference between the plaintext password being stored in memory and in a database. Yes, if you already got in, then reading RAM for active users is much more convenient than exfiltrating a bunch of potential trash accounts.
    - pdpi 5y ago
      Any non-brain dead design will keep the password around only long enough to hash it and compare that to the store hash, and then promptly get rid of it. You can’t just read passwords from memory as if it were an open book.
      - adolph 4y ago
        Attacks, as opposed to data breaches/exposures, may occur over longer time periods and sample memory as they go. Iirc, the attacker in The Cuckoo’s Egg both read password files and temporarily patched the login form.
      - alophawen 5y ago
        You don't have to hold clear-text data around for very long for it to be exfiltrated. And noone said clear-text passwords would just stick around in ram.
        Dylan16807 5y ago
        Your first sentence seems to describe sticking around and your second sentence says nobody claimed they would stick around? But more directly, "reading RAM for active users" as a method of gaining passwords, written in context as a direct consequence of "the plaintext password being stored in memory", sure sounds to me like a claim that they're sticking around.
        pdpi 5y ago
        If my password is only ever kept in RAM during my login process, there’s a small window of time where it can be exfiltrated, it’s only really at risk if there is an attack in progress while I’m logging in. Persistent storage is always susceptible to exfiltration. Nothing is ever 100% secure, but we can limit the exposure, and the blast radius when you do get breached.
VWWHFSfQ 5y ago
The server knows the plaintext password in order to hash it, salt it, and compare it. How else would it do that
- p0sixlang 5y ago
  I thought it could get hashed client side
  - VWWHFSfQ 5y ago
    Then the hashed password is effectively the plaintext password
    - sascha_sl 5y ago
      Except, if you run rounds on the client and server, you now never handle plain passwords (that users might be reusing) and reversing the thing you store into something you can use against that services' API is still just as hard (if not harder because you need to do either do the total rounds on plain or the server rounds on a very long input)
    - lxgr 5y ago
      Not if it's scoped to the username/domain in some way (e.g. by making the client-sent value H(password, username, domain) rather than just password or H(password)). But that would require a canonical and secure (i.e. not (only) controlled by server-fetched code) way of client-side password preprocessing, and if you have that, you can just as well use a PAKE, modern instances of which have all of these nice properties and more.
    - thamer 5y ago
      It's not the same. If you the un-hashed password leaks it can often be used to authenticate on other websites since people reuse passwords. You can't do that if all you have is the hashed password.
      - alophawen 5y ago

megous 5y ago

Servers routinely handle plaintext passwords when authenticating. They may not store it, but it's not something that is invisible to them, unless using some auth method that uses challenge/response instead of plaintext passwords. Most web apps use plaintext password auth.

Kwpolska 5y ago
There is a difference between the plaintext password being stored in memory and in a database. One is just how things work (the client browser needs the password in plaintext as well), and another is a security breach waiting to happen.
- adolph 5y ago
  > There is a difference between the plaintext password being stored in memory and in a database. Yes, if you already got in, then reading RAM for active users is much more convenient than exfiltrating a bunch of potential trash accounts.
  - pdpi 5y ago
    Any non-brain dead design will keep the password around only long enough to hash it and compare that to the store hash, and then promptly get rid of it. You can’t just read passwords from memory as if it were an open book.
    - adolph 4y ago
      Attacks, as opposed to data breaches/exposures, may occur over longer time periods and sample memory as they go. Iirc, the attacker in The Cuckoo’s Egg both read password files and temporarily patched the login form.
    - alophawen 5y ago
      You don't have to hold clear-text data around for very long for it to be exfiltrated. And noone said clear-text passwords would just stick around in ram.
      - Dylan16807 5y ago
        Your first sentence seems to describe sticking around and your second sentence says nobody claimed they would stick around? But more directly, "reading RAM for active users" as a method of gaining passwords, written in context as a direct consequence of "the plaintext password being stored in memory", sure sounds to me like a claim that they're sticking around.
      - pdpi 5y ago
        If my password is only ever kept in RAM during my login process, there’s a small window of time where it can be exfiltrated, it’s only really at risk if there is an attack in progress while I’m logging in. Persistent storage is always susceptible to exfiltration. Nothing is ever 100% secure, but we can limit the exposure, and the blast radius when you do get breached.

VWWHFSfQ 5y ago

The server knows the plaintext password in order to hash it, salt it, and compare it. How else would it do that

p0sixlang 5y ago
I thought it could get hashed client side
- VWWHFSfQ 5y ago
  Then the hashed password is effectively the plaintext password
  - sascha_sl 5y ago
    Except, if you run rounds on the client and server, you now never handle plain passwords (that users might be reusing) and reversing the thing you store into something you can use against that services' API is still just as hard (if not harder because you need to do either do the total rounds on plain or the server rounds on a very long input)
  - lxgr 5y ago
    Not if it's scoped to the username/domain in some way (e.g. by making the client-sent value H(password, username, domain) rather than just password or H(password)). But that would require a canonical and secure (i.e. not (only) controlled by server-fetched code) way of client-side password preprocessing, and if you have that, you can just as well use a PAKE, modern instances of which have all of these nice properties and more.
  - thamer 5y ago
    It's not the same. If you the un-hashed password leaks it can often be used to authenticate on other websites since people reuse passwords. You can't do that if all you have is the hashed password.
    - alophawen 5y ago