[morsch]

Or just normalize the password by making the first character either lower- or uppercase both when checking and setting it.

[Raed667]

It would be more complicated to do this once you stored millions of passwords.

So now you have to create 2 flows, those before the new policy and those that were set after the normalization.

[weird-eye-issue]

If your storing millions of passwords surely a version field and an if statement is not going to be a huge concern

[Raed667]

It is definitely more complicated than changing the case and running the hash again

[weird-eye-issue]

is_password_valid = hash_password(normalize_password_case(password) if version == 1 else password) == hashed_password

[pixl97]

Are we doing this client side or server side?

If you're actually using a 'strong enough' hash to prevent easy cracking if your hashed password database is leaked then you're doubling the server load which can be quite substantial in some cases.

[weird-eye-issue]

It's only being hashed once...

And obviously this is server side

[markenqualitaet]

Why?

[pawelmurias]

Because you are changing the daabase schema to introduce a stupid version field to store "normalized" passwords rather then just doing the check twice on mobile platforms.

[weird-eye-issue]

Hashing takes a lot of CPU time. And btw you don't even need to change the database schema. You could encode the version in the password field itself. Django does this and it works great

[Closi]

Sounds like the requirement might be for the case insensitivity of the first character to only be for some platforms (eg mobile devices where autocapitalisation might have happened).

In that case this solution would have the disadvantage that it wouldn’t be platform specific.