Gmail password first character is case insensitive on mobile device • Hacker News Board

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

#151

Post by farmerstan » Sat, Oct 09, 2021, 2:19 PM UTC

hahajk wrote: post #122

josalhor wrote: post #78

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?

I’m sure it’s client side and it just retries the different ways if it encounters a password error. Much easier and more secure than 3 versions of the password.

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

#152

Post by dylan604 » Sat, Oct 09, 2021, 2:20 PM UTC

atoav wrote: post #68

martincmartin wrote: post #35

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.

This is like when on a cli application -h displays a hint that you probably meant --help (or the other way around). If you already know someone wants to display the help, why not just display it?

or just build in both options to getopts

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

#153

Post by ufmace » Sat, Oct 09, 2021, 2:23 PM UTC

gertlex wrote: post #143

klodolph wrote: post #93

Earlier quoted context omitted.

In Python, it is expected that typing an identifier will not cause an action to happen... so this is consistent with that expectation.

In Python3, that is. I'd love to find (never looked...) a python3 repl where `print`, `dir`, `help` all behave like python2's `print`, since they're debug/lookup tools. It's rather often I'll open a terminal and want to check one of those things, and... typing () characters just adds significant effort (for lack of better description).

Maybe you want Ruby instead?

I always found Ruby's optional parenthesis to be annoying in stored code, but I gotta admit it's nice on the REPL.

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

#154

Post by lelandfe » Sat, Oct 09, 2021, 2:33 PM UTC

martincmartin wrote: post #79

jpswade wrote: post #43

Earlier quoted context omitted.

There's a school of thought in interface design that you shouldn't change what the user inputs, as it can be a jarring experience for regular users.

But the changing isn't user visible. To the user, the phone number is the string "(416) 555-1270". If you want to store it differently in your database go ahead. But to the user, the phone number has dashes. In fact, on my phone, when I type in just the digits, my phone inserts the parens and dashes. Presumably, users consider this easier to read, and dare I say, more canonical. So, many applications can't handle pho…

> I just want a phone number input box that will strip dashes for me.

So you don't actually want the input box to strip dashes, right? It sounds like you want more sites to accept dashes.

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

#155

Post by lelandfe » Sat, Oct 09, 2021, 2:37 PM UTC

Aachen wrote: post #81

kevincox wrote: post #49

Earlier quoted context omitted.

Yup. My role of accepting phone numbers is `input.replace(/[^0-9+]/g, "")`. It might strip some expected information in rare cases but good enough for me. This works for a lot of other things that people format wildly like Canadian postal codes (which are A1A 1A1 format but many places require presence or absence of a space), credit cards (strip the spaces) and so many other fields.

Why not simply leave it as the user input the value? Validation is one thing, but silently dropping information cannot possibly be helpful for the person that then has to call this number. I agree it should work for any phone number I've ever encountered, but just why

This is one of the reasons why I generally don't like `maxlength` on telephone input fields: browsers will truncate pasted-in phone numbers with nary a peep to the user as to why.

Validation with onblur or submission is great, but changing my input makes me angry.

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

#156

Post by ufmace » Sat, Oct 09, 2021, 2:37 PM UTC

This doesn't bother me that much, but what really grinds my gears is how many sites won't let you log in with the correct username and password. I don't care enough about the account to want to set up 2FA, and I'd rather preserve a bit more privacy by not sharing my real phone number or another email address. Some sites seem to insist, and I think it's more about advertising and anti-spam than actual security.

Yahoo seems to be big on this these days. I had an old Yahoo account that I don't use much, but every time I try to log in, they seem to change around exactly what pseudo-2FA they want. Now they won't even let me try to type my password. Good grief, guess I'll just write off that account.

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

#157

Post by pawelmurias » Sat, Oct 09, 2021, 2:41 PM UTC

weird-eye-issue wrote: post #66

pawelmurias wrote: post #59

Earlier quoted context omitted.

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.

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

#158

Post by spicybright » Sat, Oct 09, 2021, 2:42 PM UTC

snthd wrote: post #147

josalhor wrote: post #78

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…

Facebook doesn't even require you get your login email address 100% right.

Really?

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

#159

Post by baybal2 » Sat, Oct 09, 2021, 2:43 PM UTC

williamdclt wrote: post #28

baybal2 wrote: post #23

Earlier quoted context omitted.

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?

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

#160

Post by azernik » Sat, Oct 09, 2021, 2:44 PM UTC

remram wrote: post #145

ineedasername wrote: post #129

Earlier quoted context omitted.

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.

You can also normalize the password, e.g. always make the first letter lowercase and reverse the case of the rest if the second letter is uppercase. Then you only have to hash that. HeLLo, heLLo, hEllO, HEllO all normalize to heLLo

That only works if they have the same insensitivities across time and platforms. In this case, they still need to preserve the original information, because they're case sensitive on that first transformation for non-mobile devices.