This is a great example to try to explain a mod practice because this post is right at the line for topicality, and really a little over the line into off-topic. Lobsters isn’t customer support for popular services, and is not the torch and pitchfork outlet. A post from the person who designed this system would be much better. But this link most likely will just prompt an thoughtful discussion about a small security design issue (that’s novel, at least to me and comments so far) and seems very unlikely to turn into a flamefest or brigade mob, so I’m OK leaving it.
Thanks for pointing this out! Bit of context: I was myself very surprised to learn of this feature, as I had never heard of it before. There was a mysterious issue with a colleague of mine, who said he could log-in using his phone but not with his desktop machine on a Gmail account. The phone had the password stored in its keychain, and when unmasking the password field we saw it clearly: it worked for signing in. Typing it over then resulted in an error on the desktop. We were baffled! Could not find a better source of it than this discussion, but wanted to share the “thing” here on Lobsters.
Huh. Cute. I guess spending a single bit of entropy on that is no big deal in terms of overall security.
I don’t think they spend any entropy at all.
Well they could be adjusting the rate limit to account for these two checks. By some logic that is making the password 1 bit easier to guess.
Yeah, most likely they specifically check if the first letter of the submitted password is lower case and try a second attempt to compare against the hash with that first letter capitalised.
How would this not result in an effective loss of entropy?
First character alpha is 52 possibilities, or ~6 bits.
If it’s case insensitive, 26 characters, ~5 bits, which is half as entropic.
I see two ways to implement this:
Second one is no loss of entropy, because the password in the database can still be uppercase or lowercase (of course hashed). Since the client has to submit the password twice it will go through the same protection that is setup for login security, e.g. slow hashing with PBKDF2.
Yeah, you’re right. Your second implementation hadn’t occurred to me. I note that it’s the rate limit imposed by the web server which is the main protection in practice; the cost of the hash is only relevant for attackers who have already stolen the hashed passwords.
“Hash/iterate/some sort of proof of work” to login is an interesting idea.
Since many passwords are already low entropy, I fear loosing any bits. I remain skeptical, but I also despise passwords in general.
From what I understand, server only stores and accepts one version of the password. The trick is that client - after unsuccessful login - tries modified version of the password (pretty much like a human might try).
200% the number of expected passwords work in this scheme.
Here’s a relevant research paper on this subject: https://www.cs.cornell.edu/~rahul/papers/pwtypos.pdf.
My non-expert judgment impression is that correcting a common subset of typos can be done securely, and is a win.
Facebook does, or at least used to, apparently allow for quite “extreme” password and email changes while still allowing you to enter (two years ago, Why can I log in to my Facebook account with a misspelled email/password?).
So it sounds to me like Google rolled their own password entry field instead of using the OS provided one, forgot to turn auto-capitalisation off, and then “fixed” it.
I can see why, given how iOS and Android just love to capitalize the first letter of input fields.
I remember back in 1998 or so, when I was sysadmin for a small mom’n’pop dial-up ISP, I was asked to consider modifying the system (RADIUS from the Ascend devices talking to radiusd on FreeBSD) to try each password as entered in all possible casing combinations, because fully 80% of all of our tech support calls were people typing their password in the wrong case.