Hacker News Reader

Comment by chris_l | Hacker News Reader

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

They probably just do two password checks.

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

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.

>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

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.

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

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.

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

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.

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

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

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

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.

It's only being hashed once...

And obviously this is server side

Why?

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.

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

The database would contain existing passwords without normalization. You also you have to hold the unnormalized password. Super silly to do that to save a few processor cycles on login.

It's amazing how much misinformation is in this thread. You should do further reading on password hashing and rethink whether you really have to store two different passwords...

Hashing one or two 10 char strings takes basically no time on even old mobile hardware.

Good password hash algorithms specifically are designed to take a while. They add latency to the subsequent page load when you click “submit”.

Not if you are using algorithms specifically designed to take a lot of CPU time, which is a best practice

https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpubli...

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.

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.

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.

I believe they don't hash the password. They can't know the capitalised version of my password unchanged from nearly 17 year 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

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?

...and if they remove the capital?

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

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.

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

Edit: not a good idea.

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.

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.

Ouch, you are right.

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

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.

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

Reply on news.ycombinator.com