Here's another problem that isn't discussed very much: error messaging and failure modes.
I use a command line tool to generate passwords, and I use a password database to store them. It has happened to me before that the maximum password length is something disconcertingly small, like 20 characters. I would copy and paste my password, submit, and then failed to be able to login. Why? Because my password in the "create" page was silently truncated on the front end, but the same truncation does not occur in all places, so I would type a longer password on the login page then what was registered in the system and it would fail.
Other times a password that was too long or contained whitespace would fail with a cryptic error message, or would tell me I failed to meet some other password rule that I know I did not fail to meet.
I don't understand how something with so many widely-recognized best practices associated with it can be implemented badly.
> Why? Because my password in the "create" page was silently truncated on the front end, but the same truncation does not occur in all places, so I would type a longer password on the login page then what was registered in the system and it would fail.
Here's an even worse one than truncating the end of long passwords: truncating internal whitespace
The change/reset password dialog for Apple ID does this. If your password is "foo bar baz bam" then it will happily convert it to "foobarbazbam" but not tell you it did so. Then when you go to log into your Apple ID on your phone, you include the whitespace, you try repeatedly and then lock your account (temporarily). Then you do it again...
Some general advice is:
- Don't silently truncate anything (i.e. don't limit the length)
- Don't silently transmute anything (i.e. don't convert to lowercase)
- Don't have a password max length with a limit less than $BIG_NUM chars[1]
- Do give the user feedback rather than silently doing anything.
[1]: You're hashing them anyway right? So the storage doesn't change. Though if you're using something like bcrypt be aware of the max hashed length: https://security.stackexchange.com/questions/39849/does-bcry.... Also you can work around that by hashing the entire uses password (with say SHA-512) prior to inputting into bcrypt.
> Also you can work around that by hashing the entire uses password (with say SHA-512) prior to inputting into bcrypt.
I wonder why people are so eager to combine different hash algorithms, especially a strong with a weaker one. If this is isn't a well-established anti-pattern, it should become one.[1] Why? Because in some sense it combines the weaknesses of both algorithms.
Assume your password hash is:
h(p) = bcrypt(sha512(p))
Assume in the future somebody generates a sha512() collision with p and q, while bcrypt() holds water:
sha512(p) = sha512(q)
It follows that:
bcrypt(sha512(p)) = bcrypt(sha512(q))
and hence:
h(p) = h(q)
So any collision in sha512() translates directly to h(), bcrypt's strength is unable to protect you from that.
Had you just used bcrypt(), you would not have been affected.
Frankly, this is about collision and not about preimage attacks (the latter being more relevant for password cracking), but the former is usually a first step towards the latter. Also, this example demonstrates that combining a weaker and a stronger hash algorithms usually does not combine their strengths, but their weaknesses.
[1] It is almost like inventing your own crypto primitives, which actually is a well-established anti-pattern.
While the collisions themselves would increase it's not statistically significant to cause an issue in practice. Plus the idea here isn't to increase the strength of the overall construct. It's to ensure that all characters that the user entered have some contribution to the final product.
What I'd consider a much worse issue is considering the following to be the same by silently truncating things:
- some really long password ... that ends with foo
- some really long password ... that ends with bar
- some really long password ... that ends with baz
The only acceptable alternatives when using something like bcrypt are:
- Restrict user passwords to 72 bytes (not chars!)
- Hash with something like SHA-512 prior to passing them to bcrypt.
People are eager to combine different hash algorithms frequently because they desire to hedge against weaknesses in one of the algorithms. Or, in this case, because they want to shore up an existing 'weakness' in one of the algorithms (for bcrypt, its maximum input size).
You are correct that doing this ad-hoc should be an 'anti-pattern'. There are subtle details (see the papers linked above...). However, the idea itself is sound, if handled properly.
One thing to note is that if you manage to get access to just the hashes, they won't have sha512(p), so they wouldn't be able to figure out sha512(q). So while your are correct that there is (technically) a weakness there, it's not one that's actually exploitable.
Can you explain how a collision helps? I mean, there's trivial collisions with the truncation that would be used instead. That doesn't mean that bcrypt(f(x)) is any weaker because there may be some other x' that f(x) = f(x').
I'm siding with vog here. Do not compose hashes¹. You may not think it's relevant that it degrades the security of your site, but nobody knows what consequences it will bring, so how could you know?
Impose your size limitation as a clear password rule. That means, write on your site that passwords must not exceed the 55, 255 or whatever characters, send back an error if the user tries to create a larger password.
1 - And completely avoid weaker hashes in general, it's not like a percent or two increase in CPU usage will have a greater impact on your bottom than having to adapt your software after it's out.
I can confirm. I spent days locked out of my Apple account (and all associated devices) because I had spaces in my passwords. After several hours with support, who needed to escalate the issue to tier 2, then engineering, the only thing that fixed it was me briefly trying a simple password -- one without spaces. I'm not sure if the issue was ever fixed, but I don't imagine I'll use spaces in an Apple password again anytime soon.
Wonder what other sins are there. A couple of years ago when iCloud was first a thing, I did a couple of password changes in quick succession. It resulted in me having different login passwords for different iCloud services. It worked for a short time then broke and another reset fixed it all.
Enforced password reset questions. There's a limited set of about 10 questions (trivial stuff like "where were you born?"), and you have to set 3 of them. About half a year ago, I was forced to do this in order to be able to log in again (I'm only occasionally using it for publishing iOS apps). What is this, Hotmail in 2005?
And the questions haven't changed in decades. It's pretty simple to figure out things like "name of high school attended", "street you grew up on", "model of first car", "mother's maiden name", etc for just about anyone who has a social media account.
As my dad pointed out, the answers are passwords. If you restricted passwords to every possible make of car, for example, it would be incredibly weak - too little total entropy in the possible answers.
(Love the name of the high school mascot, by the way!)
> As my dad pointed out, the answers are passwords. If you restricted passwords to every possible make of car, for example, it would be incredibly weak - too little total entropy in the possible answers.
United Airlines does exactly this and it's hilariously insecure. The secret questions are preselected and the answers must be from their set of answers for each. There's only 8-10 choices for each (ex: Favorite music? pop / jazz / classical / etc).
> (Love the name of the high school mascot, by the way!)
There 10 types of people. Those that got that joke and ...
My favorite restaurant in college is a high-end hotel in Johannesburg (actually it's not, and I've never even been to Africa unless you count a week I spent on Tenerife as a child).
> You're hashing them anyway right? So the storage doesn't change
No, but the time spent computing the hash does change and you open yourself to denial of service attacks. Just pick a max password length of like 200, or whatever your hashing algorithm mandates (55 for bcrypt).
Extremely large password sizes can lead to a DDOS attack on the server (due to computation complexity curve). A large size such as 4096 characters is perfect. Don't accept a password that is 10GBs in size. But don't limit to MAX 16 characters either.
Oh yeah! Freedompop actually transformed a space into a "+" (or vice versa). And this is just free internet I set up for my dad. Took us like an hour to figure that one out.
I'm guessing whatever they used as an HTTP client did it for them. It's a fairly common way to encode spaces (the alternative being %20 of course - encoding as "+" looks much cleaner).
This is why the first thing I do when I create an account -- no exceptions as long as it's not a throwaway -- is always to log out and log back in.
If there was a problem with password truncation I'll know straight away and I can either figure out what the truncated password should be and switch it to something that isn't truncated or if that's impossible I can create a new account. If I'm unable to create a new account at least I'll know to stay away from them without having done anything important yet.
I have had that weird truncation happen several times. It is very frustrating, especially for someone who is first learning to make great long passwords, because they've never come across that problem before and now have to debug it.
Recently I had another scenario happen to me: signing up for a job application login, use my password manager to make a password, everything's great. Then when I go to login, "please remove the disallowed symbol (") from the password input before continuing". Needless to say, I could not log in. And they made me wait 24 hours before resetting my password. I was much less keen on applying for jobs there after that.
I read a recent anecdote bout a similar issue. The person had their long password silently truncated to 21 chars on the reset page and 20 chars on the login page. That sounds like a super fun thing to track down as an end user.
(UK mobile network) giffgaff.com does this.
You can enter any length (as far as I can tell) on the "set password" form but the login form will only submit 25 chars.
This means you can successfully set your password to something you can never enter!
I've run into this kind of issue before. I had an 11-character password silently truncated to 10 on signup, then when I typed the full one into the login form it failed to log in.
Woo. Can't remember what clue the system gave me that let me figure out what had happened now.
I ran into one of those... with a bank! Supposed 32-character limit, but the login page truncated at 31 via Javascript (was able to force my way in via using the console). Ever since I usually don't max out the listed length during generation, just in case.
And don't you absolutely love it when you realize that your password is failing because of a quotation character. It's then that you realize how seriously poor security is at this website that requires capital, lowercase, digits, and special characters in a password limited to 10 characters and doesn't like spaces.
The same way anything else well understood can be implemented badly: naïveté, incompetence, ignorant ukaze from on high, "well we had to have something but there wasn't enough time", or some combination thereof.
I think it was an account I had with Sony Planetside where the password was lowercased on signup, but not all parts of their site did it....... (e.g. forums, game itself, etc).
This partially happened to me on NBA League Pass. It was particularly confusing because I wasn't completely locked out. The failure mode was that my password was one character too long, and was truncated. On the login form, the length was restricted by javascript if you typed in the password, but using auto-fill from 1Password bypassed that.
I thought they were locking me out for proxying or something until eventually by luck I noticed what was going on.
I had a fun issue a few months ago with Team City at work. I was setting up a build to upload to our internal Nuget server, but the upload kept failing. I finally discovered (I don't remember how, but it took hours) that our randomly generated Nuget API key included a character that Team City didn't like and it was silently stripping that character from the input field in the build setup.
This just happened to me on the Wii U with my Nintendo ID. I had set a 20 character password some time in the past(probably the limit on whatever webpage I used to sign up) and when I tried to log into my Wii U recently, only 16 characters were available for entry.
Hotmail did that my super long password, it freaked me out at first and I had to guess where the cut-off happened because I couldn't find the damn password length.
Funny thing is this sort of password bug bit me on PayPal. PayPal of all places! Not sure if it was the length or a disallowed character, but no actual validation took place. Would let you "change" it to something and then never allow you login.
I use a command line tool to generate passwords, and I use a password database to store them. It has happened to me before that the maximum password length is something disconcertingly small, like 20 characters. I would copy and paste my password, submit, and then failed to be able to login. Why? Because my password in the "create" page was silently truncated on the front end, but the same truncation does not occur in all places, so I would type a longer password on the login page then what was registered in the system and it would fail.
Other times a password that was too long or contained whitespace would fail with a cryptic error message, or would tell me I failed to meet some other password rule that I know I did not fail to meet.
I don't understand how something with so many widely-recognized best practices associated with it can be implemented badly.