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

[the_gipsy]

Even if it’s encrypted, they could send both forms.

Edit: not a good idea.

[squeaky-clean]

I'm no security expert, but this would let someone try two unrelated passwords at once and so probably wouldn't be done client-side.

[iso1210]

In practice is there really any difference between allowing a client to try 10 passwords before 'lock out' (say no more attempts for 10 minutes), or try 5 passwords before hand.

[the_gipsy]

Ouch, you are right.

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