4 ms·

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

pfarrell 5y ago
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.
nicoburns 5y ago
Unlikely from Google though. They might have a lot of questionable practices, but their security is top draw.
deleted 5y ago
[deleted]
iso1210 5y ago
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 5y ago
  Even if it’s encrypted, they could send both forms. Edit: not a good idea.
  - squeaky-clean 5y ago
    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.
    - the_gipsy 5y ago
      Ouch, you are right.
    - iso1210 5y ago
      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.
Dylan16807 5y ago
Sure it can mean that, in the same way that verifying a password at all can mean that.

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.

nicoburns 5y ago

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

deleted 5y ago

[deleted]

iso1210 5y ago

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 5y ago
Even if it’s encrypted, they could send both forms. Edit: not a good idea.
- squeaky-clean 5y ago
  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.
  - the_gipsy 5y ago
    Ouch, you are right.
  - iso1210 5y ago
    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.

Dylan16807 5y ago

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