4 ms·

No. Servers should never see the actual password. What case are you imagining where they need to?

hardware2win 5y ago
To generate tokens?
born2discover 5y ago
I believe they are referencing the fact that upon a login attempt the server does receive a plaintext password per se. Usually it is stored in memory only long enough to compare it to the hashed version from the persistence layer but... that's in theory.
- tuwtuwtuwtuw 5y ago
  When it comes to memory then it will typically be stored longer than necessary due to how garbage collection works in 99% of all of web applications.
coder543 5y ago
> Servers should never see the actual password. Are you actually doing client-side hashing in addition to hashing on the server side? Otherwise, yes, the server does see the password. In most applications, a compromised server could just serve a login page that doesn't do the client-side hashing anymore if the malicious actor wanted to collect credentials, so I don't see how this added complexity is really adding any security. The real way to add more security is to minimize dependence on passwords by implementing a better, second factor of authentication, such as TOTP, WebAuthn, SSO, or even SMS or email tokens. Unless a person is using a password manager to generate their passwords, then passwords are almost always terrible and weak, and usually reused across sites. More of my opinion is shared over here[0]. [0]: https://news.ycombinator.com/item?id=30559443 https://news.ycombinator.com/item?id=30559443
- CorrectHorseBat 5y ago
  >In most applications, a compromised server could just serve a login page that doesn't do the client-side hashing anymore if the malicious actor wanted to collect credentials, so I don't see how this added complexity is really adding any security. That takes much more time and requires the attacker to be able to, unnoticed, change the served data.
  - coder543 5y ago
    "Much" more time? Do you have any sources to back that up? Why is combining client-side and server-side hashing not commonly considered best practice if it's so great? I don't agree at all. Login pages are static, since they don't need to be customized per user, because the users aren't logged in. Anyone could easily prepare a modified login page before compromising the underlying system, and swap it in immediately after compromise. The added implementation complexity for the original developer is simply security theater. Client-side hashing of passwords is actually a dangerous thing to recommend, in my opinion, because a lot of developers would assume that it removes the need to also hash on the server-side. At which point, they would literally be storing the actual password in plaintext in their database, since the client-side hash is the password. Client-side hashes also aren't going to have a per-user salt, which means that an attacker can just use a rainbow table to reverse the hash of most passwords... making it even less worthwhile. The attacker doesn't even need to change the served content, but they certainly can. As I mentioned in my previous comment, and I will repeat it here, real benefit to authentication security only comes from adding 2FA or SSO. Don't waste your time on security theater.
    - Dylan16807 5y ago
      > As I mentioned in my previous comment, and I will repeat it here, real benefit to authentication security only comes from adding 2FA or SSO. Don't waste your time on security theater. In theory there's also convincing browsers to implement a zero-knowledge protocol like SRP.
      - 5y ago

To generate tokens?

I believe they are referencing the fact that upon a login attempt the server does receive a plaintext password per se. Usually it is stored in memory only long enough to compare it to the hashed version from the persistence layer but... that's in theory.

tuwtuwtuwtuw 5y ago
When it comes to memory then it will typically be stored longer than necessary due to how garbage collection works in 99% of all of web applications.

coder543 5y ago

> Servers should never see the actual password. Are you actually doing client-side hashing in addition to hashing on the server side? Otherwise, yes, the server does see the password. In most applications, a compromised server could just serve a login page that doesn't do the client-side hashing anymore if the malicious actor wanted to collect credentials, so I don't see how this added complexity is really adding any security. The real way to add more security is to minimize dependence on passwords by implementing a better, second factor of authentication, such as TOTP, WebAuthn, SSO, or even SMS or email tokens. Unless a person is using a password manager to generate their passwords, then passwords are almost always terrible and weak, and usually reused across sites. More of my opinion is shared over here[0]. [0]: https://news.ycombinator.com/item?id=30559443 https://news.ycombinator.com/item?id=30559443

CorrectHorseBat 5y ago
>In most applications, a compromised server could just serve a login page that doesn't do the client-side hashing anymore if the malicious actor wanted to collect credentials, so I don't see how this added complexity is really adding any security. That takes much more time and requires the attacker to be able to, unnoticed, change the served data.
- coder543 5y ago
  "Much" more time? Do you have any sources to back that up? Why is combining client-side and server-side hashing not commonly considered best practice if it's so great? I don't agree at all. Login pages are static, since they don't need to be customized per user, because the users aren't logged in. Anyone could easily prepare a modified login page before compromising the underlying system, and swap it in immediately after compromise. The added implementation complexity for the original developer is simply security theater. Client-side hashing of passwords is actually a dangerous thing to recommend, in my opinion, because a lot of developers would assume that it removes the need to also hash on the server-side. At which point, they would literally be storing the actual password in plaintext in their database, since the client-side hash is the password. Client-side hashes also aren't going to have a per-user salt, which means that an attacker can just use a rainbow table to reverse the hash of most passwords... making it even less worthwhile. The attacker doesn't even need to change the served content, but they certainly can. As I mentioned in my previous comment, and I will repeat it here, real benefit to authentication security only comes from adding 2FA or SSO. Don't waste your time on security theater.
  - Dylan16807 5y ago
    > As I mentioned in my previous comment, and I will repeat it here, real benefit to authentication security only comes from adding 2FA or SSO. Don't waste your time on security theater. In theory there's also convincing browsers to implement a zero-knowledge protocol like SRP.
    - 5y ago