62

I have recently logged into a website. When I clicked on the "Update Profile" page, you are displayed with a list of text boxes for all the user fields, e.g. name, email, phone number etc.

There is also a box for password and confirm password (for if you wish to update these values), however, when you go into this page, those boxes are already populated, which made me think, why are they putting placeholders in?

When going into inspect element, they actually have the values of your password, transformed into upper case like this:

<input type="password" name="txtPassword2" size="45" value="MYPASSAPPEARSHERE">

I have also recently noticed that the case of your password or username is irrelevant when logging in - e.g. I can put it in all caps, all lower, or a mixture of both and it will still accept the password.

Is this a security hole and does this indicate they are storing passwords as plain text?

This is not a duplicate of (What to do about websites that store plain text passwords) as I’m asking here for clarification of whether this indicates the site is storing plaintext passwords, rather than what to do about it.

Response from the company: After pushing hard, the company confessed that they are in fact, storing passwords in plain text.

stzvggmd
  • 622
  • 5
  • 8
  • 42
    You might want to check this out: https://plaintextoffenders.com/ – Axel2D May 23 '19 at 12:45
  • 7
    With that security concept, one almost wonders why they bothered to add the `type="password"`attribute – Hagen von Eitzen May 23 '19 at 21:01
  • Looks like some site that uses antique software, possibly some old mainframe or something. At that point, network was in many cases presumed to be secure (no internet connection usually) and the passwords security was thought of in terms of eavesdropping by other people. – Gnudiff May 24 '19 at 07:36
  • Are you inspecting the HTLM that they are generating? – 9ilsdx 9rvj 0lo May 24 '19 at 11:24
  • 18
    Are you sure the password field is sent to you pre-populated and it's not your password manager or browser that is filling it? – zovits May 24 '19 at 12:29
  • 6
    @zovits If that were the case, the password would not show up under the `value` attribute when inspecting the element. – Herohtar May 24 '19 at 15:28
  • 3
    What site is this, so we can all make sure and never use it? – RonJohn May 25 '19 at 12:25
  • 2
    I wouldn’t be surprised if a password of `%` worked for all users of that site. – Roman Odaisky May 25 '19 at 13:31
  • @HagenvonEitzen `type="password"` only changes how it's displayed to a user. Other than preventing people from looking over your shoulder and to stop autofill from remembering it, it's the same as a `type="text"` field... It's still sent unencrypted over the network, etc, so it's not inherently more secure. – Jon May 25 '19 at 22:06
  • yes please name and shame to protect others from using this website – Nathan Adams May 26 '19 at 16:46

3 Answers3

116

Quite obviously, if they can display your password, then they are storing your password somehow. They might cache your password on the client-side when you log in (for unjustifiable reasons, like session management), but more likely their password database is in clear text. Either way, it's stored and it should not be.

And it looks like they are running a upper() function on the password, which wipes out 26 characters from the potential character set that would have otherwise added some entropy.

This is very, very poor security on their part that has had no place for 2 decades.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 12
    While it may be a distinct possibility, we can't know that passwords are stored unencrypted. They could be stored with reversible encryption. Still bad, but not quite as heinous. – barbecue May 23 '19 at 21:11
  • 42
    @barbecue eek - decrypting the password and sending it back to the client? That adds a whole new layer of ick – schroeder May 23 '19 at 21:12
  • 23
    @barbecue That is just as bad as plaintext... – Luke Park May 23 '19 at 21:14
  • Case-folding the passwords can be a reasonable security/usability tradeoff. Almost nobody uses upper-case letters in their password, but many people accidentally turn the CapsLock key on when typing in their password. Slight loss of potential password complexity, large reduction in forgotten-password calls. – Mark May 23 '19 at 22:18
  • 11
    @Mark I do not think it is a wise choice as it removes a huge part of the common domain of passwords (going from 62^n to 36^n) which substantially reduces the amount of time needed to crack passwords (Even random passwords will go from 6-ish bits of entropy per character to 5 with that sort of scheme). Just seems to me like such a thing is appealing to people who should learn to use password manages and reducing the security of everyone else in the process. – Lemon Drop May 23 '19 at 23:38
  • 1
    @LemonDrop, it removes a huge part of the *theoretical* domain of passwords. But most people don't use upper-case letters, or if they do, will make the first letter of their password the upper-case one -- and attackers know this. The actual reduction in attack complexity isn't 62^n -> 36^n, but 62*36^(n-1) -> 36^n. – Mark May 23 '19 at 23:41
  • 1
    @LukePark It is awful, yes, but it's not "just as bad as plaintext". If the decryption key is stored outside of the database, then a breach of the password database alone is less severe than it would be if the passwords were plaintext. This is still miles worse than properly storing them as a cryptographic hash, but there's no need to overstate it. – Chris Hayes May 23 '19 at 23:43
  • 1
    @Mark It probably is somewhat fine for those who do not use good passwords to begin with yes, but it's best not to reduce the security of those who are using a good purely random password just for that (even though it's likely inconceivable to crack either way). Also if someone was relying on the additional complexity case adds (as some people still do) it may completely ruin their choice. If you wanted to go full usability mode you should just store passwords in plaintext anyways so clearly usability is not the primary concern. – Lemon Drop May 23 '19 at 23:47
  • 12
    @LemonDrop , Mark not only is it bad because it reduces password complexity (at least for security aware users) but possibly more importantly it *deceives users into thinking that their passwords are more secure than they are.* The very least they could do is make it clear to users that passwords are not case sensitive – DreamConspiracy May 24 '19 at 01:21
  • Update: After confronting the company, and after pushing them hard, they confirmed that they are storing plain text and are looking to address it. Nightmare. – stzvggmd May 25 '19 at 07:14
  • “Either way, it's stored and it should not be.” — Perhaps a dumb question, but how are they supposed to implement login functionality based on a username and a password without storing the password? How can you verify something if you have nothing to verify it against? Or did you mean specifically that it’s stored _in a reversible way_ (i.e., storing the password itself as-is, rather than storing a hashed and salted, encrypted version of it)? – Janus Bahs Jacquet May 25 '19 at 08:44
  • @JanusBahsJacquet passwords should not be stored. Representations of the password should be stored instead. That's the core design pattern to use. – schroeder May 25 '19 at 09:22
  • 1
    And by “representations of the password”, you mean for example the result of a non-reversible hash-and-salt encryption? I’d still call that storing the password, even if it’s not storing the actual password as-is, but that’s semantics. At least notionally, I’d think of storing anything that can in any way yield the password (e.g., through decryption with the correct key) as ‘storing the password’. Perhaps add a clarification that you’re talking about the actual password itself as a string? – Janus Bahs Jacquet May 25 '19 at 09:27
  • 2
    @JanusBahsJacquet I do not think that a clarification is required. A hash is not the password. That's not semantics. The hash does not yield the password. – schroeder May 25 '19 at 09:43
  • 1
    @JanusBahsJacquet They need to be able to answer the question, "Is this password the correct one?" Storing a hash, the password, or an encrypted form of the password all permit this. They should *not* be able to answer the question, "What is the password?" Storing the password or an encrypted form of the password both permit this. Storing a hash does not. – Ray May 26 '19 at 16:38
13

The plaintext password is a gaping security issue.

  1. First, they shouldn't even know it. Passwords should be stored hashed and salted. Anyone who doesn't do that is an [censored by editors].
  2. Second, sending the password over the wire when not strictly necessary is a second huge security mistake.
  3. Third, including it in the webpage at this point only adds insult to injury.

That they throw out the case is harmless compared to that. It is actually something that can be a reasonable trade-off between security and usability. It might also be that they're using some ancient backend system that doesn't support upper/lowercase. I've seen that with mainframes. It should be written somewhere that passwords are case-insensitive, but honestly, compared to the first three strikes, this one is barely worth mentioning.

Tom
  • 10,124
  • 18
  • 51
  • 2
    Is *Anyone who doesn't do that is an idiot.* an overstatement? There may be cases where high security isn't as important. For example, the Mailman mailing list manager stores and sends back passwords in plain text, and clearly indicates this behaviour, explicitly telling people to not use a valuable password. If a user password is stolen, all the offender can do is unsubscribe them from the mailing list. Although questionable design, are the designers of Mailman idiots? – gerrit May 24 '19 at 07:44
  • 7
    @gerrit Yep. There are zero technical reasons to use plaintext passwords since the invention of the secure hash function, which - for reasonably generous values of "secure" - dates back to at least 1989 (the MD2 hash function; I didn't exhaustively check the other archaic ones). Sure, you shouldn't use something like MD2 or even SHA-256 today, but one of the great things about secure hash functions is that they're pretty interchangeable and thus easy to upgrade; at worst you need to enlarge your database fields. – CBHacking May 24 '19 at 07:52
  • 9
    @gerrit "idiot" is an understatement. Even if your system is the lowest imaginable security, we know for a fact that users re-use passwords across sites. You are endangering not only your own site, but also many other sites. **Especially** if your site is low security, because then it most likely has fewer security controls in place. – Tom May 24 '19 at 10:45
  • @CBHacking To Mailmans credit, I should stay that starting with Mailman 3, passwords are apparently stored hashed and no longer in plaintext. – gerrit May 24 '19 at 10:56
  • @gerrit I think the main problem with this is for people who mostly use the same password (or slight different ones) on multiple websites – IEatBagels May 24 '19 at 14:20
  • 2
    @IEatBagels which is the vast majority of people. – Tom May 24 '19 at 17:54
  • @Tom I live in a world with so many core business systems that are "legacy" that hashing and salting are not possible. Idiocy does not apply. Every admin involved knows the system needs to be better. Throwing insults around does no one any good and derating people does not affect change. I'm not an editor, I'm a mod. Please be professional, even in your critiques. – schroeder May 26 '19 at 12:57
  • @CBHacking pinning the best practice for passwords to the invention of MD2 is a logic error. The idea of hashing (and salting!) passwords dates as early as 1978. ***But** It was in the early 90's where Windows starting implementing hashes (poorly). Just because something is possible and known does not mean that everyone is expected to immediately switch over to a new way of operating. There are always a lot of factors to consider and berating people is not a way to affect change. – schroeder May 26 '19 at 13:04
  • @schroeder - I am obviously speaking from the perspective of today. Of course I don't require hashed passwords from ENIAC. :-) – Tom May 26 '19 at 16:32
  • @schroeder I did not say anything about "best practices", I was speaking of *technical reasons* and merely used the oldest (nominally) cryptographically secure hash function I knew of (see https://en.wikipedia.org/wiki/Comparison_of_cryptographic_hash_functions). I didn't even claim that this was the earliest that it was possible, the words "at least" were in there for a reason. Nor did I make any claims about when the idea of password hashing (or salting) was first published (I wouldn't have guessed it to be as far back as '78, that's cool). – CBHacking May 29 '19 at 22:47
6

To be honest, we don't know.

They could store the password in plaintext, they could store it encrypted. Both would be quite desastrous. They could store it in the session (i.e. server-side) when you log in which would be somewhat less desastrous but still bad. They could even have you store it in a cookie (i.e. client-side) and then have the script showing the user profile insert it to the form, which would also still be bad.

Whatever it is, there is no good reason, or sane reason, or in fact any reason that I could imagine why one would need, or even want to keep the password around needlessly and longer than absolutely necessary. Or, why it would need to be in the form.

The longer you keep something that's secret around, no matter how safe or unsafe, the higher the likelihood that "something" may happen and secrets are not secret any more.

So... whatever it is, it's generally not a good pattern. How serious it really is, we cannot tell.

Same goes for uppercasing the password. We don't know what they're doing there. They might consider every password all-uppercase, which would be quite bad since it makes a brute-force attack approximately twice as effective. Though in the light of possibly storing plaintext passwords, that's kinda neglegible. Online brute-force attacks are unlikely and easily thwarted, and offline attacks, well... if the passwords are plaintext... you know. Who cares, at that point.

They might just uppercase it for that form so some "super smart" Javascript snippet will tell you "that's too similar" when changing password, whatever. We don't know. But again, whatever it is, it's no good.

Damon
  • 5,001
  • 1
  • 19
  • 26
  • 2
    "it makes a brute-force attack approximately twice as effective" - Much worse! It removes up to 1 bit of entropy from every *character* of a password, i.e. a 10-character password would lose 10 bits, hence the search space would be reduced by a factor of 2^10=1024. – JimmyB May 24 '19 at 11:01
  • 2
    Actually, I can think of why they have the password in that form. Their backend is lazy and takes an entire object that is persisted without processing to the database. That opens the whole thing up to a whole lot of attacks that I'd want to try if I knew which website it was... – Tom May 24 '19 at 11:38