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.
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.