WeChat permanently closes account after user sets offensive password

Re:WeChat permanently closes account after user sets offensi... by yardie on Friday June 05, 2020 @10:10AM (#23428729)

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.

[ Parent | on HN ]

Re:WeChat permanently closes account after user sets offensi... by davedx on Friday June 05, 2020 @10:15AM (#23428787)

> 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

[ Parent | on HN ]

Re:WeChat permanently closes account after user sets offensi... by Retric on Friday June 05, 2020 @10:54AM (#23429237)

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.

[ Parent | on HN ]

Re:WeChat permanently closes account after user sets offensi... by tzs on Friday June 05, 2020 @12:52PM (#23430625)

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.

[ Parent | on HN ]

Re:WeChat permanently closes account after user sets offensi... by Retric on Friday June 05, 2020 @09:16PM (#23435925)

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.

[ Parent | on HN ]

Re:WeChat permanently closes account after user sets offensi... by yardie on Friday June 05, 2020 @12:18PM (#23430223)

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.

[ Parent | on HN ]