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

161–170 of 278 posts

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

#161

Post by eterm »

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.

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

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

#162

Post by klodolph »

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

Have you considered ipython? It has commands like that.

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

#163

Post by names_are_hard »

eterm wrote: post #161
dylan604 wrote: post #150

Earlier quoted context omitted.

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.

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

Instead of just telling the parent that they're doing something can wrong in a condescending way, can you explain what it is they should do differently? At least a link to an article that explains this?

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

#164

Post by dylan604 »

eterm wrote: post #161
dylan604 wrote: post #150

Earlier quoted context omitted.

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.

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.

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

#165

Post by DangitBobby »

pansa2 wrote: post #86
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?

>>> exit Use exit() or Ctrl-Z plus Return to exit

Notably, the ipython shell does the right thing here. That reason alone warrants an install in most virtual environments in my mind.

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

#166

Post by spookthesunset »

tsimionescu wrote: post #61
jeroenhd wrote: post #56

Earlier quoted context omitted.

Most competent websites I know accept general UTF8 characters like emoji perfectly fine. There are a lot of crappier websites that don't even have proper unicode support for usernames or profile descriptions out there, though, so your mileage may vary. As far as I know, there's nothing preventing a password field from containing any valid unicode string. The problem may be IME support or servers stuck in ASCII, but t…

Even surprisingly big names are surprisingly bad at this. Don't know recently, but Hotmail/Outlook used to have a rule of only using letters, numbers, and a handful of symbols, also limiting you to at most 16 characters or something. You couldn't even type a space!

For what it’s worth the “big” company I work for stores usernames in MySQL. 15 years ago when the username column was created it was set for ASCII (or whatever legacy charset it was). Changing it to utf8 would be a royal pain in the ass, requiring all kinds of testing and crazy updates across the entire company.

So while we’d love to make it utf8, it is just too much work to justify doing over other things.

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

#167

Post by Taywee »

vbezhenar wrote: post #106
wcoenen wrote: post #96

Earlier quoted context omitted.

This is different, there is no special case handling here for you typing "exit". Python functions are invoked with parenthesis, while typing a name without parenthesis retrieves the content of a variable. The Python CLI helpfully sets the "exit" variable to that string so that you don't get a confusing NameError when you make this mistake.

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 available with Ctrl-D anyway.

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

#168

Post by UncleMeat »

croes wrote: post #94
sz4kerto wrote: post #77

Earlier quoted context omitted.

Many people note their passwords down in eg. a text document. Not a great practice, but password management is a pain for most people. So when they do that, their editor might auto-capitalize the first character.

And then you see it's capitalized and change it.

No. What happens is people fail to login several times in a row and complain about it. This approach changes the security of a password basically not at all while reducing the number of people who become aggravated by not being able to login because they don't realize their capslock is on.

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

#169

Post by rovr138 »

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

Doing this reduces way more the space of characters and reduces security.

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

#170

Post by avidiax »

robbmorganf wrote: post #149
twistedpair wrote: post #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.

Yikes, I didn't know that. Seems like I need to make my fidelity password 6 times longer. Does this also mean they probably store passwords in clear text? Because there's no way to normalize the numeric passwords back to letters and symbols.

It doesn't mean that they store in cleartext, but they may as well.

They can generate the phone password on the client side and send both passwords to be salted, hashed, and stored separately.

That much seems OK.

But the salted+hashed phone password is incredibly weak. It can be brute forced readily unless it is very long.

From the brute forced phone password, the regular password can be brute forced as well, since the digits of the phone password tremendously constrain the characters of the regular password.

It's very much like the Hollywood hacking where the hackers progressively lock digits of your password and eventually discover the whole thing.

Post reply on HN