I’m working on an application that needs user authentication with passwords. I can’t figure out the best approach for handling password security.
If I hash the password on the client side using JavaScript, anyone can view the source code and see exactly how the hashing works. This seems like it would make it easier for attackers to reverse engineer.
But if I handle all the encryption on the server side, that means I have to transmit the raw password over the network first. Even with HTTPS, this still feels risky to me.
What’s the standard practice here? How do most developers handle this security challenge properly?
both approaches r pretty flawed, but server-side is def the better choice. i mean, yeah, sending pwd over the net feels sketchy, but with HTTPS it’s safe. client-side hashing? yikes. if someone gets that hash they can just replay it, which is a big problem. plus, server-side means you can manage the salt and tweak bcrypt settings.
Interesting problem! What if someone grabs the hash though? Even with client-side hashing, couldn’t an attacker just replay that hash to log in? How would you stop that - seems like you’d need extra protection either way?
Server-side hashing is the way to go for password security. Don’t worry about sending passwords over HTTPS - TLS encryption protects your data just fine, and that’s how pretty much every auth system works anyway. Client-side hashing actually makes things worse because now the hash IS your password. Here’s what you should do: send the plaintext password over HTTPS, then hash it immediately on your server using something strong like bcrypt or Argon2 with proper salt. This way the password never gets stored as plaintext and you’re using proven crypto methods. Put your energy into getting the server-side stuff right instead of trying to fix transmission security that HTTPS already handles.