4 ms·

I've written many webapps in my life time with browser and server-side validation. Encrypting is the very first step once the form is submitted. We never knew t

by yardie 6y ago

I've written many webapps in my life time with browser and server-side validation. Encrypting is the very first step once the form is submitted. We never knew the password the only thing the library could do is validate it for minimum requirements and compare to stored hashes, that's it. If your password was "CannibalisticBabyRaper42!" as far as the server is concerned it met all the requirements.

davedx 6y ago
> Encrypting is the very first step once the form is submitted I've never worked on a webapp that did this, though I have heard of it. What's the point, really, if you're using SSL? If you don't trust the server then don't use the service
- Retric 6y ago
  Server side, the more you pass around a clear text password the more likely you are to have a security issue. So it’s very good practice to immediately hash any submitted passwords to avoid them ending up in logs accidentally etc. It’s pointless client side. Trusting the clients hashing of a password is the same as using a clear text password. Aka some admin or hacker learns the hash they can use a modified client to send the hash directly.
  - tzs 6y ago
    It's only pointless to hash client side if the server does not also hash. Hashing on the client what the user actually types and sending that hash to the server which then treats that hash as the password can help in the case of users that construct similar passwords for different sites. A user who uses passwords of the form "<site>.19%Gkm19^GB", for example, would normal be sending "gmail.19%Gkm19^GB" gmail, "twitter.19%Gkm19^GB" to Twitter, and so on. If anyone one of those gets compromised there is a good chance they all will be. If the sites had a first step of client siding hashing then the password that gmail sees is "0d156132c43e7110b5d678eafd7117b5a4649fbf" and the one twitter sees is "cfd9d7f62b92eb025a242bc860d41aae60ebeacf". One of those getting compromised on the wire or at the server doesn't put the other at risk.
    - deleted 6y ago
      [deleted]
    - Retric 6y ago
      If you accept that someone could compromise the web server but be unable to modify the website sent then sure. More generally if you don’t trust the other end you should not be using passwords.
- yardie 6y ago
  If you're using SSL the password is encrypted in transit. Once it reaches the server it needs to be to encrypted at rest. When I see billion dollar companies with an ungodly IT budget not do something basic like salt and hash passwords in the database I have to wonder how they could miss something so basic.

by yardie 6y ago

davedx 6y ago

> Encrypting is the very first step once the form is submitted I've never worked on a webapp that did this, though I have heard of it. What's the point, really, if you're using SSL? If you don't trust the server then don't use the service

Retric 6y ago
Server side, the more you pass around a clear text password the more likely you are to have a security issue. So it’s very good practice to immediately hash any submitted passwords to avoid them ending up in logs accidentally etc. It’s pointless client side. Trusting the clients hashing of a password is the same as using a clear text password. Aka some admin or hacker learns the hash they can use a modified client to send the hash directly.
- tzs 6y ago
  It's only pointless to hash client side if the server does not also hash. Hashing on the client what the user actually types and sending that hash to the server which then treats that hash as the password can help in the case of users that construct similar passwords for different sites. A user who uses passwords of the form "<site>.19%Gkm19^GB", for example, would normal be sending "gmail.19%Gkm19^GB" gmail, "twitter.19%Gkm19^GB" to Twitter, and so on. If anyone one of those gets compromised there is a good chance they all will be. If the sites had a first step of client siding hashing then the password that gmail sees is "0d156132c43e7110b5d678eafd7117b5a4649fbf" and the one twitter sees is "cfd9d7f62b92eb025a242bc860d41aae60ebeacf". One of those getting compromised on the wire or at the server doesn't put the other at risk.
  - deleted 6y ago
    [deleted]
  - Retric 6y ago
    If you accept that someone could compromise the web server but be unable to modify the website sent then sure. More generally if you don’t trust the other end you should not be using passwords.
yardie 6y ago
If you're using SSL the password is encrypted in transit. Once it reaches the server it needs to be to encrypted at rest. When I see billion dollar companies with an ungodly IT budget not do something basic like salt and hash passwords in the database I have to wonder how they could miss something so basic.