Live data from Hacker News

Gmail password first character is case insensitive on mobile device

support.google.com

131–140 of 278 posts

Re: Gmail password first character is case insensitive on mobile device

#131

I just want a phone number input box that will strip dashes for me. Many go to the effort of having an error message pop up that says "no dashes or parentheses allowed." So they went to the effort of writing special case code to notice and handle this ... by giving instructions to the person, instead of the computer.

>So they went to the effort of writing special case code to notice and handle this ... by giving instructions to the person, instead of the computer.

Personally, I pretty passionate about NOT changing data that my tools receive. It takes a specific, documented situation for me to say "you give me X, and I make it Y". I am more comfortable with "your address, X, has been standardized to Y. Do you accept?".

Re: Gmail password first character is case insensitive on mobile device

#132

Earlier quoted context omitted.

It is indeed [0], but there's about 14% of the browser world who can't benefit from it yet [1]. [0] https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att... [1] https://caniuse.com/mdn-api_htmlelement_autocapitalize

Realistically this is only going to affect people on mobile devices, which looks like it'd bring that down to about 6.5%

With over 1.5 billion active users... 6.5% is still a very large number of people!

Also.. not sure what safari/iOS did in their early years with keyboard password entry capitalization... but if they did auto capitalize... since Apple is so good at saving profile info across new installs/os updates... I imagine there would be a large portion of old apple users with perma-capitalized passwords out there as well.

Re: Gmail password first character is case insensitive on mobile device

#133

I just want a phone number input box that will strip dashes for me. Many go to the effort of having an error message pop up that says "no dashes or parentheses allowed." So they went to the effort of writing special case code to notice and handle this ... by giving instructions to the person, instead of the computer.

I thought the same, and was surprised to find the problem here seems to be that there's no part of the HTML spec to set the allowable characters in a text input.

So JavaScript to intercept keypresses or postprocess the string is risky at best and often poorly implemented.

If it was in HTML it could be reliable, and have a unified behaviour when text is pasted in.

For phone numbers there is a "tel" input, so the undesirable behaviour your experiencing may be in spite or because of it.

Re: Gmail password first character is case insensitive on mobile device

#134
post #122

Earlier quoted context omitted.

Is this implemented by Facebook holding 3 hashes of your password? It doesn’t save your actual password clear text (or encrypted clear text), does it? A related question: when a password system tells me I need to change my password, and it has to differ by 3 letters from my previous password, is that system storing my password text rather than the hash of the password? Is that safe?

Most certainly not. Those systems normally work by A) you providing the old password for verification or B) storing hashes of password substrings.

This sounds like a combinatorial explosion situation for longer passwords and longer changes required.

Re: Gmail password first character is case insensitive on mobile device

#135

That's a nice feature. It got me thinking - imagine wanting to let users log in with a single character typo in their password, could you do this without storing hashes of all edit distance 1 passwords?

(I just work up and my brain is not yet fully functional, so what follows is probably totally stupid)

Notation: "||" means string concatenation.

Let password P = P1 || P2, where len(P1) + len(P2) = len(P) and |len(P1) - len(P2)| Let H1 = hash(P1), H2 = hash(P2), where hash() is a cryptographic hash function that produces at least as many bits as the longest allowed password and satisfies whatever slowness and memory use requirements that you have for a password hash.

To store a password, store P ⊕ H1 and P ⊕ H2.

To check a password candidate C received at login, let C = C1 || C2 using the same splitting rule as used for P above, and compute C ⊕ hash(C1) and C ⊕ hash(C2).

A login is successful if either P ⊕ H1 or P ⊕ H2 is within edit distance 1 of either C ⊕ hash(C1) or C ⊕ hash(C2).

(I've omitted salt from the above for simplicity. Replace the hash with a salted hash if you want salt).

Re: Gmail password first character is case insensitive on mobile device

#136
post #122

This is a well-understood feature. Facebook does the same thing[0]. Quote: Facebook actually accepts three forms of your password: * Your original password. * Your original password with the first letter capitalized. This is only for mobile devices, which sometimes capitalize the first character of a word. * Your original password with the case reversed, for those with a caps lock key on. [0]: https://www.zdnet.com/a…

Is this implemented by Facebook holding 3 hashes of your password? It doesn’t save your actual password clear text (or encrypted clear text), does it? A related question: when a password system tells me I need to change my password, and it has to differ by 3 letters from my previous password, is that system storing my password text rather than the hash of the password? Is that safe?

You could normalize the PW before hashing (invert case unless last letter is lower case, then make 1st letter lower case)

Re: Gmail password first character is case insensitive on mobile device

#137
post #122

Earlier quoted context omitted.

Is this implemented by Facebook holding 3 hashes of your password? It doesn’t save your actual password clear text (or encrypted clear text), does it? A related question: when a password system tells me I need to change my password, and it has to differ by 3 letters from my previous password, is that system storing my password text rather than the hash of the password? Is that safe?

They wouldn't have to store 3 hashes, would they? They could just get the hash of each of those transformations, e.g., reverse case, get hash. If the transformation make the incorrect password into the correct one, it will match the original hash.

I think that’s a likely route. It’s a question of what is more efficient, compute of hash or storage/retrieval and comparison to multiple.

To implement, choice of storing three hashes or computing n * hashes where n < 1, the probability of getting a match before having to try another.

Re: Gmail password first character is case insensitive on mobile device

#138

Probably a feature, not a bug. Most mobile keyboards automatically capitalize the first character by default. With the ephemeral nature of password characters upon entry; it would be easy to miss the capitalization, annoying users. This one small trick probably prevents millions of people from becoming frustrated with Google every single day. And I'll bet it only works one way. If your password was "ABCD", then by my…

I would have thought password fields in particular would never auto-capitalize. Is this not the case?

Some sites have a little switch that transforms the password field into a regular text one so you can see what you’re typing.

Re: Gmail password first character is case insensitive on mobile device

#139
post #130

Earlier quoted context omitted.

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

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

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

Re: Gmail password first character is case insensitive on mobile device

#140
Ever call Fidelity phone support and hear "enter your password on the keypad"? That means collapsing ~62 chars into 10 char options, a massive space reduction.

Then there's the fact that many banking sites (BofA, IIRC) only used the first 8 char of your password anyway.

Post reply on HN