Minimal password security is gained from case-sensitivity

My colleague suggested that systems should compare passwords in a case-sensitive manner. He pointed out the larger space of possible passwords, and thus the longer passwords would take to crack by a brute-force attack. This is all standard knowledge.

I still maintain, however, as discussed before, that the correct trade-off between usability and security is to compare passwords in a case-insensitive manner.

The increase in usability in having case-insensitive passwords is obvious (and documented in the previous post), so to understand the usability/security trade-off, how much is security reduced by using them?

The following calculations assume the following:

• The NSA, or whoever, wishes to attack you, has access to the hashed password (e.g. database leak)
• They have a strong machine such as this one
• They use a brute-force attack and try every combination (they don't just use dictionary words)
• Assuming you're a person of interest, let's say they are prepared to expend 2 months running the machine at full power just to crack your password
• A case-sensitive password has 80 possible characters to choose from (upper-case, lower-case, numbers, symbols), a case-insensitive normalized password as described in my previous blog post has 54 possible characters.

So how long would your password have to be to defeat the above attacker, with case-sensitive and case-insensitive passwords?

SHA1 Passwords

The machine above can try 63 billion passwords per second. That means, in the 2 months available, it can try out 3.4×10¹⁷ passwords.

• A case-sensitive password with length 10 has 10.7×10¹⁷ possibilities, so cannot be cracked
• A case-insensitive password with length 11 has 11.3×10¹⁷ possibilities, so cannot be cracked

So the "lack of security" imposed by case-insensitivity can be mitigated by having a single extra character in your password, or, put another way, making your password 10% longer.

To those who would argue that it's likely people will use random 10 character passwords but not random 11 character passwords: I propose that there are those of us who will generate n character passwords using a tool (the site is free to suggest n, meaning its value doesn't matter), and there are those who would use their pet's name as their password, in which case even a case-sensitive password is insecure, meaning case-sensitivity doesn't matter either.

bcrypt(10)

But let's try a more realistic example. Who uses SHA1? We use bcrypt, like presumably everyone else.

bcrypt has a strength parameter. It re-hashes the password 2ⁿ times. So each time you increase the strength parameter by one, it takes twice as long to calculate. By default this strenth parameter is 10, which is fine for us: it takes our server 0.1 seconds to calculate such a hash.

The web-page says that monster machine can do 71k bcrypt(5) passwords per second. So that means it can calculate 2.2k bcrypt(10) passwords per second. Meaning in the two months, it can calculate 1.1×10¹⁰ passwords. So that means:

• A case-sensitive password with length 6 has 26×10¹⁰ possibilities, so cannot be cracked
• A case-insensitive password with length 6 has 2×10¹⁰ possibilities, so cannot be cracked

So we find out that with a normal hashing strategy, the password doesn't have to be made longer to remain at the same level of security.

The "lack of security" imposed by case-insensitive passwords mean that the password either has to be slightly longer, or not longer at all. The usability advantages are very real. So that, in my mind, makes the usability vs security trade-off a clear win for case-insensitive passwords.