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

191–200 of 278 posts

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

#191

Post by listenallyall »

kevincox wrote: post #181
listenallyall wrote: post #178

Earlier quoted context omitted.

Right, but it's user-hostile. I prefer thinking of, and typing, my phone number as a mix of numbers and letters... so why won't you allow me to do so?

I am letting you. It is just when the number is sent to the backend it is converted into a usable format where I can for example generate tel: links and otherwise use the number. I agree that there is some value to being able to each your number back how you typed it, but I'm not sure it is more valuable then showing you the number how I am actually going to try to call it.

Isn't that exactly what I stated in my initial comment? Not sure why you were so quick to disagree

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

#192

Post by cylon13 »

phailhaus wrote: post #189
cylon13 wrote: post #184

Earlier quoted context omitted.

Hashing is done on the server. Hashing on the client would defeat the whole purpose.

Why? If you hash on the server, then you have to send the password in plaintext to the server. EDIT: Oh right, salts.

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 tables of hashes for common passwords.

Sending the password to the server in “plain text” is fine over https, it’s a secure channel. Hashing isn’t meant to hide the password on the wire, it’s to prevent anyone with access to the database from learning what the passwords are.

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

#193

Post by randallsquared »

joebob42 wrote: post #179
Taywee wrote: post #167

Earlier quoted context omitted.

I'd say that would be much more surprising and unintuitive behavior just for the sake of slightly more convenient REPL use. I wouldn't want stringifying any function to automatically call it. What if you store the function somewhere and print it for debugging, and then have to figure out why your program keeps crashing when you try to just print a list of functions? Besides, you usually have a more convenient exit av…

Not for every function, just for exit.

The surprise is just not worth it.

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

#194

Post by kevincox »

listenallyall wrote: post #191
kevincox wrote: post #181

Earlier quoted context omitted.

I am letting you. It is just when the number is sent to the backend it is converted into a usable format where I can for example generate tel: links and otherwise use the number. I agree that there is some value to being able to each your number back how you typed it, but I'm not sure it is more valuable then showing you the number how I am actually going to try to call it.

Isn't that exactly what I stated in my initial comment? Not sure why you were so quick to disagree

Sorry, sounds like a misunderstanding. I always meant to accept anything, that is why I put a replace in my top comment not saying that I would reject the form.

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

#195

Post by phailhaus »

cylon13 wrote: post #192
phailhaus wrote: post #189

Earlier quoted context omitted.

Why? If you hash on the server, then you have to send the password in plaintext to the server. EDIT: Oh right, salts.

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…

Great point, thanks!

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

#196

Post by brigandish »

adolph wrote: post #188
brigandish wrote: post #180

Earlier quoted context omitted.

Because the pseudo code looks quite bad? The clause should pick the user not the password or hash or anything like it. The hash (and possibly salt etc) should come back via the selected column list. The other way round is inviting trouble and could indicate a poor understanding, though I agree they shouldn't be so snarky without some explanation.

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 compare a plaintext string to a hash another logical assumption is that “pass” is a hash.

It doesn't matter whether it's a password or a hash, the form of the SQL statement is going to cause trouble and should be the other way round.

> Maybe these generous assumptions about someone’s pseudo code are unwarranted?

Perhaps you meant to reply to someone else?

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

#197

Post by eterm »

dylan604 wrote: post #164
eterm wrote: post #161

Earlier quoted context omitted.

Please never implement a password feature without reading more about how passwords should be stored.

good lord, why would you ever expect psuedo code to be my level of understanding of how to store a password. i don't ever store passwords. hashes only.

You can't compare hashes like that unless they're not salted.

The same password won't hash to the same thing without the same salt so you can't compare them like that.

(If you could, then you would notice multiple users with the same hashes, i.e. the same passwords).

To verify a hash you need to retrieve the user's salt (typically stored with the hash the algorithm in a single string) then re-hash with the same salt.

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

#198

Post by iso1210 »

squeaky-clean wrote: post #45
the_gipsy wrote: post #38

Earlier quoted context omitted.

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.

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

#199

Post by richard_todd »

Taywee wrote: post #167
vbezhenar wrote: post #106

Earlier quoted context omitted.

It is result of calling `exit.__str__()`. This function could have called exit() itself instead.

I'd say that would be much more surprising and unintuitive behavior just for the sake of slightly more convenient REPL use. I wouldn't want stringifying any function to automatically call it. What if you store the function somewhere and print it for debugging, and then have to figure out why your program keeps crashing when you try to just print a list of functions? Besides, you usually have a more convenient exit av…

Yeah but I can also say it’s a surprise to see instructions on how to exit the REPL when printing a list of functions. Honestly I think there should be no special case, and the REPL should print the “how to exit” text upon startup. As is, the user still has to guess ‘exit’ rather than ‘quit’ ‘abort’ ‘stop’ ‘bye’ etcetera to get the help text. (edit: actually they have the text on 'quit' as well)

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

#200

Post by teawrecks »

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.

You're now doing up to 3x the work for every login. When servicing millions of requests a second, that cost adds up.
Post reply on HN