Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I've come across a few organisations stating that passwords are case-insensitive. Obviously this is ridiculous, and a gigantic red flag from a security point of view.

Is there any explanation for why a password might be case-insensitive, other than them storing the passwords in plaintext?

share|improve this question
    
The same reason why people sometimes still use LANMAN hashes, legacy... Not that it's an excuse btw :) –  Lucas Kauffman Jul 30 '12 at 9:27
1  
At the end of the day the number of possible passwords are not increased by that many when a password is case-insensitive. There are many organizations, Blizzard Entertainment for example, that implement case-insensitive passwords and do not store their user's passwords in plaintext. At the end of the day when you are talking about your typical password which is secure enough to even be used, the length of time it would take to brute force that account, is high enough where it is not even a concern. PaSsWoRd is no more secure then password or PASSWORD –  Ramhound Jul 30 '12 at 11:53
2  
@Ramhound Actually PaSsWoRd is more secure as attacker is less likely to make such attempt then password. It's just not secure enough to use it. –  Andrey Botalov Jul 30 '12 at 12:26
7  
@Ramhound - really? An 8 character password that allows digits and letters has ((26 + 10) ^ 8) == 2,821,109,907,456 possible combinations, whereas case sensitivity doubles the number of possible letters: ((26 * 2 + 10) ^ 8) == 218,340,105,584,896 combinations. That's 77 times more combinations to try in brute forcing, and that number grows with password length. Of course, a longer password is better, and you should allow special characters, too. But disallowing capitals is clearly bad. –  Nathan Long Jul 30 '12 at 14:03
1  
Why would "storing the passwords in plaintext" be an explanation for (or even related to) having case-insensitive passwords? –  w3d Jul 31 '12 at 23:21
add comment

4 Answers

up vote 6 down vote accepted

The only reasons I know of are either legacy or performance based (with the latter really being a legacy issue too)

  • Some old password code removed case to suit the limited platform it was written for, and some to just limit the complexity of the code.

Both useless reasons which should have no applicability these days.

share|improve this answer
2  
I would emphasis "useless" :) –  Cyril N. Jul 30 '12 at 10:23
    
@CyrilN. - done :-) –  Rory Alsop Jul 30 '12 at 10:37
add comment

I agree with Emil that it's a question of usability. Making passwords case-insensitive puts an end to the common user error of entering the password with caps lock on.

Also, a case-insensitive password doesn't have to be stored in plaintext, it can simply be converted to lower case before it is hashed. The only security concern with having case-insensitive passwords is that it lowers password complexity, but this can be mitigated by requiring longer passwords or passphrases.

share|improve this answer
    
+1 one for the counter example to plain text requirement. –  Joshua Drake Jul 30 '12 at 14:08
2  
"puts an end to the common user error of entering the password with caps lock on." It does not on the typical Windows where CAP LOCK actually is a shift (not capital) lock. It only helps for [alpha]. –  curiousguy Jul 30 '12 at 20:11
1  
I've had (older) members of my website make this mistake so many times "My password doesn't work!" that I was considering forcing one case behind the scenes to avoid it. Ugh. –  Andrew Heath Aug 9 '12 at 7:32
add comment

One possible reason could be usability. We have all seen how some users have difficulties correctly typing their password, due to cap locks or wrong case.

Having case insensitive passwords increases the success of login in.

share|improve this answer
    
I would have said this was a probable reason. IT departments pandering to the lesser tech savvy user (and thus saving time in support calls). I can understand this being used internally, but on a public network it is obviously unwise. –  w3d Jul 30 '12 at 12:25
1  
I favor usability in the correct context. (Not my banking, though!) As long as the website implements fairly decent password requirements and some form of invalid password logic (say after 5-10 attempts) that bans the IP address, I don't see the issue. These days, you got to worry more about DDNS attacks than say a brute-force or dictionary attack. Hackers don't typically try the front door anyway. –  ROFLwTIME Jul 30 '12 at 13:30
1  
"We have all seen how some users have difficulties correctly typing their password, due to cap locks" Windows has a "CAPLOCKS is activated" message when entering account password, it is much more user friendly approach. –  curiousguy Jul 30 '12 at 20:15
1  
"some form of invalid password logic (say after 5-10 attempts) that bans the IP address" when an ISP uses carrier wide NAT with a few IP addresses for all customers, this means blocking a fraction of all ISP clients. –  curiousguy Jul 30 '12 at 20:17
1  
@curiousguy, the windows approach is more secure, not more usable. –  Emil Jul 30 '12 at 21:19
show 1 more comment

By flattening case, you allow people to enter passwords on a traditional phone keypad. I have seen more than one example of a bank that does this so that customers can have the same password at the website, as they do over the phone.

ie.

password: joe123

on-phone: 563123

This is obviously a significant compromise in security, and limits the password to 24 of the 26 letters in an English alphabet, if you assume really old phones.

In some early systems, in the days of 7-bit connections, if you gave your username in all uppercase, it assumed you couldn't do mixed case, and flattened your password during authentication.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.