you are viewing a single comment's thread
view the rest of the comments
[–] 2 points 3 days ago* (last edited 3 days ago) (2 children)

Basically, the hash is your password

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.

  • source
  • parent
  • hideshow 2 child comments
  • [–] [S] 1 point 3 days ago (1 child)

    The salt adds nothing

    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.

  • source
  • parent
  • hideshow 1 child comment