9 ms·

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

by chris_l 5y ago

cotillion 5y ago
They probably just do two password checks.
- chris_l 5y ago
  That's what I meant... hash both versions when logging in.
  - OJFord 5y ago
    Ah, it's a bit ambiguous though: not GP, but I read you as meaning do they store both versions' hash and check against either. Actually I realise GP is equally ambiguous. But I read that as (and my own assumption would be) frontend retries with the variation, backend verifies against the same only one stored.
- mnahkies 5y ago
  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
  - alin23 5y ago
    It’s very nice that you do that! I find apps that don’t trim the whitespace for the email field so annoying in terms of UX. I usually use a Text Replacement shortcut to fill in my emails (e.g. “gml” fills in my GMail address, “cld” my iCloud address etc.) and that always inserts a space after the email and I have to manually fiddle with the cursor to delete it.
  - Levitz 5y ago
    >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 Why is that relevant? The standard technically allows for case sensitivity but nobody does it
    - mnahkies 5y ago
      It can be problematic when you go to look up the account by email address during login and it isn't found due to inconsistent casing. It's technically true that the part before the domain can be case sensitive, but as nobody does this the gain in UX from people not having to know the exact casing used during sign-up is worth it to me.
- nimchimpsky 5y ago
  I doubt that very much
doubleorseven 5y ago
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.
coredev_ 5y ago
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.
achairapart 5y ago
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.
morsch 5y ago
Or just normalize the password by making the first character either lower- or uppercase both when checking and setting it.
- Raed667 5y ago
  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 5y ago
    If your storing millions of passwords surely a version field and an if statement is not going to be a huge concern
    - Raed667 5y ago
      It is definitely more complicated than changing the case and running the hash again
      - markenqualitaet 5y ago
        Why?
        pawelmurias 5y ago
        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 5y ago
        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
baybal2 5y ago
I believe they don't hash the password. They can't know the capitalised version of my password unchanged from nearly 17 year ago.
- Dylan16807 5y ago
  ...and if they remove the capital?
- williamdclt 5y ago
  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
  - baybal2 5y ago
    But how did they know which punctualion characters to remove from the password? You may try 2 versions of first letter, but do they go as far as bruteforce removing all the % character combinations from the password, unless they did remove them all?

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

cotillion 5y ago

They probably just do two password checks.

chris_l 5y ago
That's what I meant... hash both versions when logging in.
- OJFord 5y ago
  Ah, it's a bit ambiguous though: not GP, but I read you as meaning do they store both versions' hash and check against either. Actually I realise GP is equally ambiguous. But I read that as (and my own assumption would be) frontend retries with the variation, backend verifies against the same only one stored.
mnahkies 5y ago
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
- alin23 5y ago
  It’s very nice that you do that! I find apps that don’t trim the whitespace for the email field so annoying in terms of UX. I usually use a Text Replacement shortcut to fill in my emails (e.g. “gml” fills in my GMail address, “cld” my iCloud address etc.) and that always inserts a space after the email and I have to manually fiddle with the cursor to delete it.
- Levitz 5y ago
  >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 Why is that relevant? The standard technically allows for case sensitivity but nobody does it
  - mnahkies 5y ago
    It can be problematic when you go to look up the account by email address during login and it isn't found due to inconsistent casing. It's technically true that the part before the domain can be case sensitive, but as nobody does this the gain in UX from people not having to know the exact casing used during sign-up is worth it to me.
nimchimpsky 5y ago
I doubt that very much

doubleorseven 5y ago

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.

coredev_ 5y ago

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.

achairapart 5y ago

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.

morsch 5y ago

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

Raed667 5y ago
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 5y ago
  If your storing millions of passwords surely a version field and an if statement is not going to be a huge concern
  - Raed667 5y ago
    It is definitely more complicated than changing the case and running the hash again
    - markenqualitaet 5y ago
      Why?
      - pawelmurias 5y ago
        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 5y ago
        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

baybal2 5y ago

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

Dylan16807 5y ago
...and if they remove the capital?
williamdclt 5y ago
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
- baybal2 5y ago
  But how did they know which punctualion characters to remove from the password? You may try 2 versions of first letter, but do they go as far as bruteforce removing all the % character combinations from the password, unless they did remove them all?