> Please read the first two paragraphs of what I wrote for why that is a mistake.

Okay, I read it, and then re-read it. I still don't get why (for example) `bcrypt` (a salted hash function) is a bad idea.

I fully accept that I am missing something here, but I really would like to know why using `bcrypt` is a problem.

>> you need to add versioning to the system

> You need this with salted hashes, too! And of course with any password-based system.

Not in the client software, you don't. The pre-shared information with password-based system is generally stored in the users head.

The pre-shared information in the challenge/response system means both the submitting software (interacting with the user and rxing the challenge) as well as the receiving software (txing the challenge and rxing the response) need to be synchronised.

Now, once again, I fully accept that I might be missing something here, but AFAIK, that synchronisation contains extra points of attacks; points of attacks that don't exist in the password/salted-hash system.

And since absolutely no system ever discards existing mechanisms completely when upgrading, that deprecated but still supported for a few more months is even more additional points of attack.

Once again, I am trying to understand, not be contentious, and I want to fuolly understand:

a) The problem with salted hashes like `bcrypt`

b) What changes need to be made to client software when upgrading algorithms and key lengths in a password-based system.

bcrypt is not a "salted hash function". It's a a password hash construction (at the time of its invention, it was called an "adaptive hash"; today, we'd call it a "password KDF"). If you're using bcrypt, you're fine.

What you can't do is use SHA2 with a random salt and call it a day.

My understanding of bcrypt math is that the input to the algorithm is a random salt and a message, with the output being a hash.

I believe the actual implementation gives two output fields as a single value, with that value containing the salt and the hash.

This might be why we appear to be talking past each other - I consider bcrypt to be a salted hash because it takes a salt in the inputs and produces a hash in the output.

The fact that the output also contains the salt is, in my mind, an implementation detail.

Yes. We aren't talking past each other anymore. If you aren't composing a "salted hash" out of a cryptographic hash function and a salt, but are instead using bcrypt, scrypt, PBKDF2, or Argon2, you have nothing to worry about. Just to complete your understanding: the salt --- randomizing the hash --- has very little to do with what makes bcrypt a good password hash.

You'll avoid this confusion in the future if you don't refer to bcrypt as a "salted hash". Salted hashes are the technology bcrypt was invented to replace.

OP here: I am using bcrypt to hash passwords, but I struggle to understand how not salting i.e. not randomizing it against a stored secret would still be safe for storing short strings. Be that as it may, I'm glad to hear I'm not doing anything horribly wrong when building login systems.