Hashing the password client-side just means that the hash is now the password. Storing that hash is no different than storing the password, and when someone dumps out your database they can log in directly with the hash, because it's the password. So you still need to take all the same precautions you would with the original password, including hashing it again. For your trouble here you get essentially no security value, assuming you're doing everything else right, but do get some additional risk thanks to the extra moving part.

There are however real schemes to avoid transmitting passwords that may interest you, like PAKEs: https://en.wikipedia.org/wiki/Password-authenticated_key_agr.... But there are still compelling reasons not to use these, e.g. https://palant.info/2018/10/25/should-your-next-web-based-lo....

I'm confused. How is it possible to login directly with the hash? I was under the impression that if you use the hashed password obtained from the DB, then the system will try to match the hash of the hash and would fail because they would be different.

You're not wrong. To clearly delineate the two possibilities:

1. Hashing client-side in addition to standard server-side handling (Have I Been Pwned passwords disallowed, good hash function, preferably memory-hard, salted, peppered for storage, etc.). In this case client-side hashing adds complexity but doesn't improve the security model at all, so we shouldn't do it. Which is why nobody does it.

2. Hashing client-side instead of standard server-side handling. In this case client-side hashing completely breaks the security model, since the hash is equivalent to a cleartext password, so we shouldn't do it. Besides random websites, this kind of mistake has actually been made at scale. See https://en.wikipedia.org/wiki/Pass_the_hash.

In summary, basic client-side hashing either doesn't improve security or compromises it, and is therefore best avoided.

They’re talking specifically about client-side hashing. You’re right that the system will hash the stolen hash, but only in cases where the system can’t be bypassed (which client side code always can be).

> This is ridiculous and unjustifiable.

No, this feature is basically Okta working as a password-manager for systems not supporting oauth-flows / single-sign-on. Of course they then need to store and forward the actual passwords to log you in.

I think you're confusing storing user password for access to Okta vs storing passwords in Okta for access to other applications. If you're going to use Okta as a password manager and store passwords to access other applications you can't hash the password because it irreversible and you won't be able to get the real password to authenticate with the other application. So you must encrypt the passwords instead.

> Hashed pqsswords in databases is the absolutely bare minimum nowadays.

And has been for two decades. I was just a high-school kid with a website in ~2001 and I knew plaintext was bad even then.

I did it anyway, but it was just some homebrew blog I built.

> I would not only hash it already on the client side,

How does hashing on the client side help?