this post was submitted on 18 Jul 2023
10 points (81.2% liked)
Discussions related to Infosec.pub
1121 readers
1 users here now
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Passwords are always sent to the server, then it is hashed to check it against the value in the database. It's also possible to view your password by inspecting login requests from other websites. TLS is used to secure it while in transit.
Hashing is done as an extra measure of security in case the database is compromised. This measure of security would have been completely void if the server would accept password hash directly. You could log in as any user by using his compromised hash.
Why not hash it server side too? I'm asking because I'm curious
Because it provides no advantage. TLS is used to secure any data sent to a server. If you don't trust the server with your password, then you should use a unique password for this website. In fact, you should always use a unique password.
https://www.cloudflare.com/en-ca/learning/ssl/transport-layer-security-tls/
Okay. I am pretty new to this stuff so I'll go and check out SSL/TLS. Thanks :)
That doesn't make any sense. If you hash it once on client and once on server, that means that your password, as far as the server knows, is the client-hashed password. Nothing has changed in terms of security. In fact, you could implement this yourself by hashing your password when creating it and when supplying it.
That's actually a good thought though. It would prevent (clear text) password leaks from shitty / malicious websites. Having a standard for browsers to salt and hash password would have prevented a lot password leaks. On the other hand it could never be updated and we would most likely be stuck on md4 or something similarly broken.
Yeah now that you put it this way I realised my mistake. Thanks