Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gmail password first character is case insensitive on mobile device

support.google.com

Post reply on HN
Print view View original

261–270 of 278 posts

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

#261

Post by volkanvardar »

ipaddr wrote: post #246
jacurtis wrote: post #211

Earlier quoted context omitted.

Note that the client would only need to do this on a failed attempt. So if i typed "Password" on mobile. The client would first send the request as "Password". If that succeeds, then no worries. If it fails, then the client could send a second request by reversing the case of the first letter. In this case, it would send a second request for "password". At most, it is 2 login requests per password. Many other comment…

Why would you need the client to send the request over and over when you control the backend?

Not to send the password in plain, maybe?

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

#262

Post by josefx »

josefx wrote: post #229
remram wrote: post #145

Earlier quoted context omitted.

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

I hope Facebook passwords are limited to US ASCII, because I seem to remember that there are country specific conversion rules for various Unicode characters that may or may not be subject to change, not to mention the lack of 1:1 mapping for case conversions. Example the German lower case ß converts to SS, so does ss. Of course they also created an upper case variant ẞ of ß a few years ago so who knows what mapping…

Small addition since I completely forgot it: Since here the attempt is to fix caps lock issues the upper case of ß also depends on the users keyboard layout, for my keyboard ß would map to ?. Does anyone even have a list of all the keys that map to ? in different keyboard layouts?

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

#263

Post by atoav »

dylan604 wrote: post #152
atoav wrote: post #68

Earlier quoted context omitted.

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

This is the way.

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

#264

Post by dylan604 »

adolph wrote: post #244
dylan604 wrote: post #207

Earlier quoted context omitted.

Jeebus, it's just meant to show that you could do a select in one go without having to do them one at a time cascading to the next one if no match. I don't know what you need to select, that's up to the reader. That's the point of psuedo code. You saw select and made the connection to "it's a database query". Boom. point made. Again, I understand the concept of user provided pass and a hash with a salt. If you can't…

> it's just meant to show that you could do a select in one go without having to do them one at a time Which means you are performing 3 hashes, two of which are likely unnecessary and sending all of them to sql for evaluation.

What's more costly, sending 3 separate queries or calculating 3 hashes? I honestly don't know.

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

#265

Post by vort3 »

Gigachad wrote: post #258
vort3 wrote: post #256

Earlier quoted context omitted.

Their account security is so good, I'm not able to log in to my own account even when I know the exact username/password, and I hate it.

For what reason? Lost 2FA access? Triggered some kind of attack detection system?

Due to my work I travel a lot (and by that I mean that I can be in new city every day). I don't want to give google my phone number or my other email, so my account is not tied to anything, the only factor is the password.

Turns out if you try to log in from new device from new location (I guess your account is tied to IP from which it was created), just password alone isn't enough to log in. And there's no alternative way to prove that account actually belongs to me.

I understand that most services try to provide you with good security, but I hate it when everything is overcomplicated and everyone tells me what to do. No, I don't want to give you my phone number. Yes, I know I won't be able to recover my password, I don't need that. Yes, I actually want my password to be this long. No, I don't want you to block login attempts from new locations. Believe it or not, people do travel and want to log in from more than 1 city. It's none of your business if I want to give my password to my friend and let him login, just stop this please. Let me choose whatever password I want without any backup emails, phone numbers, and let everyone who knows the password log in. Is it too much to ask?

Why is it even allowed to let users create accounts without providing a phone number, but then not letting those same users to log in because their accounts are not tied to any phone number? How does it make any sense?

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

#266

Post by jhanschoo »

chrisshroba wrote: post #74
johnnyApplePRNG wrote: post #69

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?

As someone else mentioned, it's dependent on your choice of keyboard app on Android. The problem of having to trust another vendor is probably why my financial institution provides its own in-app keyboard for its apps.

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

#267

Post by freemint »

volkanvardar wrote: post #261
ipaddr wrote: post #246

Earlier quoted context omitted.

Why would you need the client to send the request over and over when you control the backend?

Not to send the password in plain, maybe?

Are you aware of transport encryption?

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

#268

Post by brigandish »

dylan604 wrote: post #264
adolph wrote: post #244

Earlier quoted context omitted.

> it's just meant to show that you could do a select in one go without having to do them one at a time Which means you are performing 3 hashes, two of which are likely unnecessary and sending all of them to sql for evaluation.

What's more costly, sending 3 separate queries or calculating 3 hashes? I honestly don't know.

You have to calculate at least one hash and you only have to perform one query (as it can grab multiple hashes at once), and that query should not choose what to return based on the content of the hash(es).

Pseudo code is supposed to strip away details that might distract from fundamentals, yet your pseudo code and subsequent replies suggest that your understanding is contrary to the actual fundamentals of checking a password securely. Start with limiting the set by choosing by user, never by hash.

Jeremy Evans goes over many of the fundamentals[1], including why restriction of the selection is important, and why restriction of access to hashes (i.e. not sending them from the initial machine) are important. In his own framework (Rodauth) he doesn’t even allow selects of the hashes to be returned to app, let alone used as part of the where clause. Note the clause in each of the functions he defines (12:53 and 14:05).

[1] https://www.youtube.com/watch?v=z3HZZHXXo3I

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

#270

Post by naniwaduni »

Mogzol wrote: post #250
juloo wrote: post #203

Earlier quoted context omitted.

The server could hash again the hashed password sent by the client. Especially if the client use an insecure hash algorithm (no secret salt for example). I feel like if the client always hash passwords as soon as it is typed (the javascript never sees the unhashed password), no one would notice. (except some with crazy password rules that would disallow a hash-looking password)

Hashing on the client still seems redundant though. In the end, whatever value is sent to the server is essentially plaintext, because it's all an attacker needs to know to authenticate. Whether it's the raw text the user typed or some transformed version of it isn't really relevant.

In a world where password reuse is rampant, whether it's the raw text the user typed or a hard-to-reverse transformation on it is absolutely relevant to the user, just not to the service provider.
Post reply on HN