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