13

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".

S.L. Barth
  • 5,486
  • 8
  • 38
  • 47
Nerotech
  • 133
  • 1
  • 6
  • 3
    Is it case-insensitive, or case-swapping? If your password is "happy", does it accept "happy" and "HAPPY" and "HaPpY" or just "happy" and "HAPPY"? If your password is "happiNESS", what does it accept? See also http://security.stackexchange.com/q/68013/971 and http://security.stackexchange.com/q/14816/971. – D.W. Sep 04 '15 at 17:59
  • 32
    It might be that they capitalize (or turn into lowercase) all passwords and then hash them. Being case insensitive does not mean that it's not being hashed. – Quora Feans Sep 04 '15 at 19:00
  • if you can log in with caps lock on that means you are not using symbols or numbers... – ratchet freak Sep 05 '15 at 18:51
  • 1
    I once read, that facebook is storing three versions of a password: the original, first character uppercase and the inverted version. http://security.stackexchange.com/questions/68013/facebook-password-lowercase-and-uppercase?lq=1 – Fabian Blechschmidt Sep 05 '15 at 19:10
  • 2
    possible duplicate of [Is there any explanation (other than storing plaintext) for case-insensitive passwords?](http://security.stackexchange.com/questions/17824/is-there-any-explanation-other-than-storing-plaintext-for-case-insensitive-pas) – MikeFHay Sep 06 '15 at 14:23
  • @FabianBlechschmidt There isn't a reason to store all of these. They can simply apply these transformations to the password being tested at the cost of up to two additional hash computations if one of the variants was entered. Or canonicalize the password before hashing. – CodesInChaos Sep 06 '15 at 16:52
  • @CodesInChaos Sorry for being inaccurate - no clue how they save it (hopefully as hash), but they allow these three transformations. – Fabian Blechschmidt Sep 06 '15 at 20:32

5 Answers5

18

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.

Steve Sether
  • 21,480
  • 8
  • 50
  • 76
  • 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 Sep 04 '15 at 17:41
  • 1
    @JeffFerland Interesting. So if I typed in Password, FB would try pASSWORD as well as Password? Probably to account for people commonly having caps lock on. That'd only halve the search space, and seems like a good usability/security tradeoff. – Steve Sether Sep 04 '15 at 17:46
  • 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 Sep 04 '15 at 17:58
  • 4
    On a Mac, caps lock puts everything in upper case; shift doesn't give lowercase. – Random832 Sep 04 '15 at 18:10
  • Can you explain in layman's terms how it goes from 2^28 possible passwords to up to 2^40? I would expect it to *increase* by 2^26, or am I wrong here? – Canadian Luke Sep 04 '15 at 18:58
  • I would disagree on the point that you should not be worried. Even if they are not storing your password in plain text, they are, as you mentioned, making it exponentially easier to crack. This might not be a problem for your "taxes and medical info" account, but many people have the same password for both that account and their bank account. – David says Reinstate Monica Sep 04 '15 at 19:00
  • @Steve: How do you get 2^28 and 2^40? Case sensitivity adds at most 6 bits of entropy, so they can only differ by at most a factor of 2^6. –  Sep 04 '15 at 19:19
  • @DavidGrinberg If you have the same password for your bank, and Facebook, then that's the security problem, and you need to correct that. – Steve Sether Sep 04 '15 at 19:23
  • 1
    @SteveSether If I do that, its my security problem. If everyone does that, its something security experts need to account for it. Its an ugly truth, but its a truth, and it means you shouldn't make your system extra weak just because its supposedly less important. – David says Reinstate Monica Sep 04 '15 at 19:26
  • I miss-calculated. Thanks to everyone for the edits. Changed the answer. – Steve Sether Sep 04 '15 at 19:30
  • @DavidGrinberg Security experts can't account for people doing dumb things. The user is always part of the equation. Also, it's not Site A's problem to solve Site B's security problems where User C has the same password for both sites. – Steve Sether Sep 04 '15 at 19:44
  • 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 – David says Reinstate Monica Sep 04 '15 at 19:50
  • Making the password case-insensitive does not reduce the *practical* search space: a real-world attacker knows that virtually all uses select all-lower-case passwords even if the system permits mixed-case passwords. If the system forces the use of an upper-case letter, it'll virtually always be the first one in the password. – Mark Sep 04 '15 at 20:17
  • Confirmed: on Macbook Pro running OS X 10.10.5, Caps Lock means all capitals; shift does not let you enter lower case. (Seems like a design flaw to me.) – Daniel Griscom Sep 04 '15 at 21:36
  • @DavidGrinberg If my password on site a (stored case insensitvely) is AbCd and my password on site b (stored case sensitvely) is also AbCd. Assuming online access only, it would certainly be easer for a hacker to brute force my password on account a than on account b. Knowing that the password for b is the same as for a (except for case), the hacker will have to go through worst case 15 candidates, average case 8 candidates to break b. If my password is 16 characters long, average case 32,768 candidates. – emory Sep 04 '15 at 22:15
  • 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`. – Dan Henderson Sep 04 '15 at 23:48
  • @DavidGrinberg I agree that the role of the company is to make the "best product", but best is a relative term. It's a blend of price, features, usability, maintenance, etc. Security is ONE aspect of that. We often make the mistake that they're trying to create a perfect product rather than a "good enough" product. "Good enough" means that any additional improvements in any one feature only add a small amount of additional value. You only have to make your product as secure as what you're trying to protect. Titanium unpickable locks on my wood shed don't make much sense, for instance. – Steve Sether Sep 08 '15 at 14:40
11

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.

cde
  • 333
  • 1
  • 6
2

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.

kasperd
  • 5,402
  • 1
  • 19
  • 38
0

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.

Elmasry
  • 198
  • 2
  • 9
-2

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.

Gerasimos.Zap
  • 1
  • 1
  • 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 Sep 04 '15 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 Sep 04 '15 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 Sep 04 '15 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 Sep 04 '15 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 Sep 05 '15 at 13:23
  • @MichaelKjörling But the use of dictionary words as passwords is not on-topic for this question. My point was that, while still using a character-by-character random password, you can simply add one or two more characters to compensate for a limited character set. (Incidentally, the hit you take by _forcing_ it to contain at least one of each character class is negligible by comparison) – Random832 Sep 05 '15 at 17:32