[chris_l]

So they hash both versions of the password? Or how does this work?

[cotillion]

They probably just do two password checks.

[mnahkies]

Yeah we did it this way on an app I worked on in the past, try the verbatim input and then a couple of minor variations in casing if it didn't work.

I've also found that for email fields you need to be careful to normalize the input (trim, casing) as safari had a habit of autocorrecting the first character to be a capital

[chris_l]

That's what I meant... hash both versions when logging in.

[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.

[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.

[achairapart]

From the first answer:

> Looks like the app is clever enough to try changing the case of the first letter if the first attempt fails.

Still, looks like a compromise between usability and security/reduced password entropy.

[doubleorseven]

They send it once over the wire but salt it twice if the first attempt fails and the request originated from a mobile app. UX is all around us.

[baybal2]

I believe they don't hash the password. They can't know the capitalised version of my password unchanged from nearly 17 year ago.

[williamdclt]

Of course they hash the password. Of course they don't know the capitalised version of your saved password, but they can know the capitalised version of the password you just entered

[Dylan16807]

...and if they remove the capital?

[coredev_]

Sadly it can also mean that they save your password in a form that enables them to read it if they need/want it.

[iso1210]

Assuming the password is sent over the wire (rather than the salt being sent to the client, the client doing the hash, and sending the hash), the password will be stored in memory while the login process runs

Normal password code would be

  if (doHash(password+salt) == storedHash) {
   failedLogins = 0;
   return 1;
  }
  failedLogins++;
  return 0;

This would presumably be

  if (doHash(password+salt) == storedHash) {
   failedLogins = 0;
   return 1;
  }
  if (doHash(swapFirstLetterIfClientIsMobile(password)+salt) == storedHash) {
   failedLogins = 0;
   return 1;
  }
  failedLogins++;
  return 0;

So while the password is 'stored' in the server side heap, it's no different to normal password 'storage'

If the hash is done in the client it's the same, just the client sends two attempts rather than one.

[nicoburns]

Unlikely from Google though. They might have a lot of questionable practices, but their security is top draw.

[pfarrell]

Certainly it’s not definitive though. This could easily be accomplished by storing multiple hashes, or multiple password checks that alter the user input, but still have Google keeping hashed passwords. Definitive example could be something like them doing a password recovery where they send you a plaintext version of your current password.

[Dylan16807]

Sure it can mean that, in the same way that verifying a password at all can mean that.