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

241–250 of 278 posts

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

#241

Post by stevula »

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?

Most apps use the appropriate type of input field ("password") which the browser or mobile OS recognizes should not be capitalized. But some apps use a normal text input (with some masking/styling to make it look like a password field) which a mobile keyboard will normally capitalize. I get very annoyed when I see the latter.

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

#242

Post by josefx »

ademarre wrote: post #238
josefx wrote: post #229

Earlier quoted context omitted.

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…

https://tools.ietf.org/html/rfc8265

Correct me if I am wrong but this doesn't seem to allow case conversion:

> Case Mapping Rule: There is no case mapping rule (because mapping uppercase and titlecase code points to their lowercase equivalents would lead to false accepts and thus to reduced security).

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

#243

Post by ipaddr »

dylan604 wrote: post #150
adolph wrote: post #137

Earlier quoted context omitted.

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.

why would you have to retrieve multiple? could you not calculate the 3 hashes, and then do SELECT WHERE pass = HASH1 OR pass = HASH2 OR pass = HASH3? You don't care which one was correct just that one is.

By retrieving three you can perform an if on one value; if that fails check the other two values. This allows you to save the other two calls for most logins.

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

#244

Post by adolph »

dylan604 wrote: post #207
adolph wrote: post #188

Earlier quoted context omitted.

Unless it has been edited since i saw it, the pseudo sql doesn’t select anything, a logical assumption is user identity and not needed. The comparison is between the original hashed password and the hashes made at auth-time. The name of the original is “pass” but since it wouldn’t make sense to compare a plaintext string to a hash another logical assumption is that “pass” is a hash. Maybe these generous assumptions a…

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.

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

#245

Post by adolph »

brigandish wrote: post #196
adolph wrote: post #188

Earlier quoted context omitted.

Unless it has been edited since i saw it, the pseudo sql doesn’t select anything, a logical assumption is user identity and not needed. The comparison is between the original hashed password and the hashes made at auth-time. The name of the original is “pass” but since it wouldn’t make sense to compare a plaintext string to a hash another logical assumption is that “pass” is a hash. Maybe these generous assumptions a…

> The comparison is between the original hashed password and the hashes made at auth-time. Didn't I write that this shouldn't be done via the clause? I haven't edited my comment either so it should still be there and I see it is. > the pseudo sql doesn’t select anything It should select the hash(es) and bring them back to the app for comparison. > The name of the original is “pass” but since it wouldn’t make sense to…

> It should select the hash(es) and bring them back to the app for comparison.

Agreed 100%. Calculating three hashes and sending them to sql for comparison—maybe index lookup—seems backward to me.

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

#246

Post by ipaddr »

jacurtis wrote: post #211
freemint wrote: post #186

Earlier quoted context omitted.

This would be bad for rate limiting though.

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?

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

#247

Post by scbrg »

caymanjim wrote: post #209
spicybright wrote: post #158

Earlier quoted context omitted.

Really?

They might do the same stupid thing Gmail does, and ignore certain characters. My Gmail is "first.m.last@gmail.com", but I constantly get mail from idiots who don't know their own email address, and use my "firstmlast@gmail.com" to sign up for things. This problem would go away entirely if Gmail didn't do this. Facebook might do similar things to make it "easier" to login, even though there are security implications.

> This problem would go away entirely if Gmail didn't do this

No it wouldn't. The problem is that people believe they have addresses they don't. They don't have firstmlast@gmail.com any more than they have firt.m.last@gmail.com.

I have a surname@ address, and I receive similar mails all the time. People just simply assume they have my email address. No dots involved.

https://xkcd.com/1279/

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

#248

Post by freemint »

smrq wrote: post #214
nitrogen wrote: post #212

Earlier quoted context omitted.

It's one bit per alphabetic character, isn't it?

No, it's only one bit for the first character and one for the second. The case of every other character is maintained relative to the second character, so the parity there provides the one bit of information for each subsequent alphabetic character.

*and one for the caps lock key

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

#249

Post by staticassertion »

nitrogen wrote: post #213
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)

There are formalized approaches to keeping the server from knowing the password at any time: https://en.m.wikipedia.org/wiki/Password-authenticated_key_a... SRP is one such system: https://en.m.wikipedia.org/wiki/Secure_Remote_Password_proto...

The various ZKP approaches are considerably more complex to implement properly vs the trivial approach of a client side hash. There are obvious tradeoffs, of course, but I wouldn't fault someone for an additional hash step on the client.

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

#250

Post by Mogzol »

juloo wrote: post #203
cylon13 wrote: post #192

Earlier quoted context omitted.

More importantly if the server just accepts hashed passwords and stores them, then if you got ahold of a hashed password through a leak you could just use it directly to authenticate by modifying the client. The hashed password just becomes the password with one extra client-side step that you can trivially skip. Salting is more about making it non-obvious which passwords map to which hashes so you can’t easily build…

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.
Post reply on HN