I see what you mean, the password is being sent from Client to Server to Firebase Server but as far as I know it's not necessary to hash it at any point.
Hashing is done when you want to store the pass, not send it in HTTP methods.
Hashing passwords on the client before sending them to the server? Not necessary.
Even if you are handling authentication yourself, you should still hash your password on the server.
I assume your concern is someone stealing your password, if your app’s security is compromised, then they can also steal the hashed password you are sending through the client. So there is no point really.
If your authentication logic depends on the server authenticating an already hashed password from the client, then all a hacker needs is that hashed password from the client, the real password isn’t useful to the hacker at this point.
If they have a plain text password I entered and I am a normal user, wouldn’t the thought be that I’ve reused this email / password combination elsewhere?
Yeah, but if every app did authentication the same way you are suggesting then their hashed password is still all that will be needed in a case of compromise. Your client code can be accessed on the browser so your hashing algorithm isn’t really hidden. My advice to you is just always have ssl.
Hope this guides you. stackoverflow.com/questions/371592...
Thanks for taking the time to answer these quandaries.
Last one: even if an attacker has both access to a hash and the hash function, if that hash function is secure, they still can’t reverse that to get the password, correct?
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
if every app did authentication the same way you are suggesting then their hashed password is still all that will be needed in a case of compromise.
There are, I think, ways to mitigate this kind of hash re-use. And I think Michael is right about there being some security advantages to interception of a hash vs a plaintext password.
Ideally a variable-salted hash of the passphrase would be signed by a given client's private key specific to the user, the same one used for a mutual TLS session.
It could still be intercepted via a MITM attack, but the attack might then give evidence of tampering.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Really great article. Learned a few things.
What strategy would you recommend we use to securely pass the user's password to the create user Route?
Would just hashing with a salt and always checking against that suffice?
I see what you mean, the password is being sent from Client to Server to Firebase Server but as far as I know it's not necessary to hash it at any point.
Hashing is done when you want to store the pass, not send it in HTTP methods.
Just pass the raw password to firebase auth. Firebase auth will take care of the hashing
But aren’t we sending a post request to the router? Is it a security issue at all to send the plaintext password in a post request?
I understand that Firebase takes care of the password hashing, but isn’t that generally done client side?
Thanks for helping me understand.
Hashing passwords on the client before sending them to the server? Not necessary.
Even if you are handling authentication yourself, you should still hash your password on the server.
I assume your concern is someone stealing your password, if your app’s security is compromised, then they can also steal the hashed password you are sending through the client. So there is no point really.
Would one benefit of hashing client side be that, if the app’s security were compromised, then the user’s real password wouldn’t leak?
Sorry to be overly pedantic here I’m just trying to learn.
If your authentication logic depends on the server authenticating an already hashed password from the client, then all a hacker needs is that hashed password from the client, the real password isn’t useful to the hacker at this point.
If they have a plain text password I entered and I am a normal user, wouldn’t the thought be that I’ve reused this email / password combination elsewhere?
Yeah, but if every app did authentication the same way you are suggesting then their hashed password is still all that will be needed in a case of compromise. Your client code can be accessed on the browser so your hashing algorithm isn’t really hidden. My advice to you is just always have ssl.
Hope this guides you.
stackoverflow.com/questions/371592...
Thanks for taking the time to answer these quandaries.
Last one: even if an attacker has both access to a hash and the hash function, if that hash function is secure, they still can’t reverse that to get the password, correct?
No they can’t
There are, I think, ways to mitigate this kind of hash re-use. And I think Michael is right about there being some security advantages to interception of a hash vs a plaintext password.
Ideally a variable-salted hash of the passphrase would be signed by a given client's private key specific to the user, the same one used for a mutual TLS session.
It could still be intercepted via a MITM attack, but the attack might then give evidence of tampering.