This is a good analogy! Another similar analogy would be construction codes for earthquake proof, or fire proof or whatever safety feature new building must have to be compliant. We don't go and fix everything currently built unless we have to, or can.

The risk is of course, an earthquake where it could destroy all houses built before year X.

But we do the same in all industries, path of least resistance.

> Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.

Unless I'm misunderstanding what you're doing, this achieves nothing.

Hashing the password on the client side makes the hash the password, and MITM attacks are still possible.

Sure, you could MITM still if all you do is that, as with anything it depends on what you are defending against.

If you are defending against clear text being discoverable, then bcrypt hashing with a unique salt on the client is good enough.

If you are trying to prevent MITM you can combine that salting with public/private key transmission of the bcrypt hash to the backend (effectively the same idea as pass keys without the downsides).

MITM just affects your service, and doesn't always matter depending on what the service is, for example, a recipe manager doesn't need to have bullet proof security.

As the hash is being encrypted with the public key in the client, that would require that the client be compromised. In which case the original password is already exposed at that point, thus a discussion of the transport is no longer the concern.

The point of a hash is that the password is not stored on the machine long term. Thus, if an attacker gains access to the back-end and exports all the hashes, you can't reuse the hashes themselves to login. I.e. you need to do a password-cracking attack, which is infeasible with a password of sufficient length.

I don't care if someone gets my password hash. They aren't going to crack it due to the complexity of it.

Here is my hashed password. Good luck:

    $argon2id$v=19$m=65536,t=3,p=1$YTE4NzBkMDIwMjRhMGY5NzU4OTc2ZWY5YzI0N2RjOTY$GSBlUwWxr4BBs+5o5Ye2NphT9PFeWx4ECG6siED9uVQ

You can't use that to login to my system. You can only use it to validate if I give you my password...

Correct. The hash effectively is the password at that point.

If you’re storing the hash unencrypted in the DB, and it’s “just” a hash so why not, you’ve gone backwards.

One example I'm familiar with which is different, are Schengen tourist visas. You need to leave before the visa expires. That's not the case for US tourist visas.

Apparently the Form I-94 (Arrival/Departure Record) card is phased out. But it used to be that it contained your allowed term of stay. I am sure the digital version has something like that. You do not automatically get the max allowed duration per your visa. It might be that they are one and the same especially short visa terms of course. But i haven't actually been since mid 2000s so I wouldn't actually know for sure.