I recently discovered a service where the password was not case sensitive. I understand basic principles of encryption and hashing so I am a bit worried, is this service storing my password in plain text?

Could you explain to me why being able to login with Caps Lock, when my password is NOT capitalized, is bad? And should I be worried?

More testing revealed that all forms of the password were accepted, such as "HAPPY", "HaPpY" and "hAPPY".


5 Answers 5


Whether you should be worried or not depends on the sensitivity of what you're protecting. The lock protecting my filing cabinet holding my taxes and medical information doesn't need to be that secure, and I don't worry that the lock is cheaply designed. But I want the locks protecting my money to be extremely secure. It does show that they may not be thinking very clearly about security when designing the system.

Making passwords not case sensitive reduces the number of possibilities dramatically. A 6 non case sensitive character alphabet only password has 2^28 possible passwords,while a 6 character case sensitive password has 2^34 possible passwords. This reduced search space makes an attack on a leaked hash database more feasible.

As Jeff Ferland points out below, having caps lock on doesn't mean the site isn't case sensitive. If I type Password, then hit caps lock, it comes out pASSWORD. The case is merely inverted. If the site is doing this, then the password is still case sensitive, but merely tries the original, and inverted password. This merely halves the search space. That's simply a usability/security tradeoff since people commonly have caps lock on and don't know it, and (at least IMO) a good one.

It's impossible to tell if the service is storing your password in plaintext from this one fact. It's trivial to just change everything to one case before the hashing is done.

  • 6
    For a reference, my memory is that Facebook tries a few combinations of your password against the raw hash including inverted first case letter and inverted case.
    – Jeff Ferland
    Commented Sep 4, 2015 at 17:41
  • 5
    And further, it does not reduce the search space for an offline attack. Since online attacks are usually rate limited enough for this kind of thing to not really matter, the only real cost incurred is in higher CPU by the authenticating servers. Functionally speaking for security, it's pretty much a no-op.
    – Jeff Ferland
    Commented Sep 4, 2015 at 17:58
  • 4
    On a Mac, caps lock puts everything in upper case; shift doesn't give lowercase.
    – Random832
    Commented Sep 4, 2015 at 18:10
  • 3
    @SteveSether I disagree. The role of any expert, security or otherwise, is to make the best product. That needs to account for imperfect reality, otherwise we would just say "why do we need security at all? Its not group A's problem that person B is a criminal." I'm certainly not saying that in your example Site A should solve or even care of Site B's security issues; I'm just saying Site B shouldn't do silly security tradeoffs Commented Sep 4, 2015 at 19:50
  • 3
    If I type Password, then hit caps lock, it comes out pASSWORD. If I type Password, then hit caps lock, it doesn't change what I typed before I hit caps lock. I'd have to hit caps lock first, and then type Password to have it come out pASSWORD. Commented Sep 4, 2015 at 23:48

Whether a password system stores your password in plaintext has NO CONNECTION to if it is case sensitive or not. Plenty of badly designed systems require case sensitive passwords but store them in plaintext.

As to whether or not you should be concerned, any system that does not require case sensitive passwords has greatly cut the amount of unique passwords in half or less. It may be convenient to the user, but for example, an 8 character password that's not case sensitive has 208,827,064,576 (208 Billion) possible variations. Case sensitive? 53,459,728,531,456 (53 Trillion) combinations. The amount of time a brute-force cracker needs to run to find your password is so much smaller when Case is not an issue. Add digits (0-9) and that number quadruples to 213 Trillion.

Of course, users tend to ignore good password security features, like using strong mixed character passwords, not reusing passwords, changing them regularly, not using dictionary words, so they may have made a decision not to require too complex passwords.


The behavior with regards to caps lock does not tell you anything about the hashing algorithm used on the server side.

It may be the hash on the server is indeed computed using your password exactly as you entered it. But on an invalid password the server might simply reverse the case of every letter you entered and try again with that. Such an approach has practically no impact on security, but may reduce the number of support cases significantly, if users often forget that their caps lock is on.

It is also possible that the password is not case sensitive at all. Again it doesn't tell you anything about the hashing. They might simply be converting the entire password to lower case (or to upper case) before hashing. This reduces the amount of possible entropy, so on such a system your password needs to be about 15% longer to have the same strength.


Being able to login with with caps-lock doesn't necessarily mean your password is stored in plain text because the service maybe applying uppercase to all passwords before hashing and storing them in the database, and it's of course doing the same when a user logs in.

Using both upper-case and lower-case letters in a password is recommended to make passwords more difficult to guess.


Logging in with capslock is dangerous because you are essentially eliminating entire password lists by having it all uppercase. The safest password is a combination of uppercase and lowercase letters, at least one number, and at least one special character and should be between 8 and 16 characters long.

  • An 8-character upper/lower/numeric password has 47 bits of entropy, the same as 9.2 characters of uppercase+numbers, or 10.1 characters of only uppercase letters.
    – Random832
    Commented Sep 4, 2015 at 18:12
  • "Dangerous" is relative. It can only be determined with additional context, which we do not have. It is true that you are eliminating portions of the password space. That is not necessarily dangerous in and of itself.
    – Xander
    Commented Sep 4, 2015 at 20:02
  • 1
    Additionally the password you suggest, is not, the absolute sense, "the safest". A much longer password, randomly generated without the constraints you suggest (one special character, etc.) would in fact be much safer.
    – Xander
    Commented Sep 4, 2015 at 20:04
  • 2
    -1 for limting passwords to 16 characters. The maximum length of a password should be virtually unlimited (it's acceptable to have some so-big-nobody-reasonable-will-reach-them limits, to avoid that a 16GB file is used as password for facebook ☺), Remember: you are only storing a hash of the password. You shouldn't mind about its maximum length.
    – Ángel
    Commented Sep 4, 2015 at 22:04
  • @Random832 I doubt YESTERYEAR (ten uppercase characters) has anywhere near 47 bits of entropy against a real life attack. However, CEIKJAIAHP might be close to 47 bits of entropy (but not anymore, obviously). It is often claimed that English has something like 100k words; thus, a random English word has log2(100k) or about 17 bits of entropy. Real-life English sentences have less entropy than the sum of the respective words' entropy, because many combinations of valid words do not form valid real-life sentences (and this holds true for all languages).
    – user
    Commented Sep 5, 2015 at 13:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .