Exactly, this is equivalent to using a password of a particular length with only hex digits. It may be long, but the original data is completely unnecessary here.
The salt adds nothing, since you can’t change it, as you need to produce the stored hash in the end on the server. There are methods of challenge-response authentication wherein the server sends a random challenge and the client hashes it, but that requires storing the password in cleartext on the server.
It prevents cross-service re-use, should the original password hash be obtained (if other services used the same system).
Example (MD5 in b64 used for simplicity):
Same password is used on website1 and website2. The password is password. password produces KGdV+tBIacpSMyCszg3GpA== which can be used for both websites.
Now, if website1 adds sbo2 as salt, and website2 addsx3e5, you get: passwordsbo2 -> d0bd511zpYqG3//3vLGYRQ== passwordx3e5 -> 788BnQKx7B2KOSju2jviiQ==
So if you are on a corporate network that does MITM (you had to add their root cert) for monitoring, they’ll only see a hash for each website separately, without being able to re-use it.
Though that’s quite a bit of an edge case, and assumes no client modification or other monitoring.
True, I got engrossed in thinking through your proposal and forgotten about the original intent of a salt. Happens to me from time to time, particularly with security topics for some reason.
Exactly, this is equivalent to using a password of a particular length with only hex digits. It may be long, but the original data is completely unnecessary here.
The salt adds nothing, since you can’t change it, as you need to produce the stored hash in the end on the server. There are methods of challenge-response authentication wherein the server sends a random challenge and the client hashes it, but that requires storing the password in cleartext on the server.
It prevents cross-service re-use, should the original password hash be obtained (if other services used the same system).
Example (MD5 in b64 used for simplicity): Same password is used on website1 and website2. The password is
password.passwordproducesKGdV+tBIacpSMyCszg3GpA==which can be used for both websites.Now, if website1 adds
sbo2as salt, and website2 addsx3e5, you get:passwordsbo2->d0bd511zpYqG3//3vLGYRQ==passwordx3e5->788BnQKx7B2KOSju2jviiQ==So if you are on a corporate network that does MITM (you had to add their root cert) for monitoring, they’ll only see a hash for each website separately, without being able to re-use it.
Though that’s quite a bit of an edge case, and assumes no client modification or other monitoring.
True, I got engrossed in thinking through your proposal and forgotten about the original intent of a salt. Happens to me from time to time, particularly with security topics for some reason.