Website returning plaintext password [duplicate]
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
This question already has an answer here:
What to do about websites that store plain text passwords
12 answers
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.
passwords web-application account-security
asked May 23 at 11:34
stzvggmdstzvggmd
4182 silver badges6 bronze badges
marked as duplicate by forest, Tobi Nary, Conor Mancone, LvB, A. Hersean May 29 at 9:33
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
|
show 5 more comments
This question already has an answer here:
What to do about websites that store plain text passwords
12 answers
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.
passwords web-application account-security
asked May 23 at 11:34
stzvggmdstzvggmd
4182 silver badges6 bronze badges
marked as duplicate by forest, Tobi Nary, Conor Mancone, LvB, A. Hersean May 29 at 9:33
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
42
You might want to check this out: plaintextoffenders.com
– Axel2D
May 23 at 12:45
7
With that security concept, one almost wonders why they bothered to add thetype="password"attribute
– Hagen von Eitzen
May 23 at 21:01
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 at 12:29
6
@zovits If that were the case, the password would not show up under thevalueattribute when inspecting the element.
– Herohtar
May 24 at 15:28
3
What site is this, so we can all make sure and never use it?
– RonJohn
May 25 at 12:25
|
show 5 more comments
This question already has an answer here:
What to do about websites that store plain text passwords
12 answers
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.
passwords web-application account-security
asked May 23 at 11:34
stzvggmdstzvggmd
4182 silver badges6 bronze badges
This question already has an answer here:
What to do about websites that store plain text passwords
12 answers
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.
This question already has an answer here:
What to do about websites that store plain text passwords
12 answers
passwords web-application account-security
passwords web-application account-security
asked May 23 at 11:34
stzvggmdstzvggmd
4182 silver badges6 bronze badges
asked May 23 at 11:34
stzvggmdstzvggmd
4182 silver badges6 bronze badges
edited May 25 at 7:28
stzvggmd
asked May 23 at 11:34
stzvggmdstzvggmd
4182 silver badges6 bronze badges
asked May 23 at 11:34
stzvggmdstzvggmd
4182 silver badges6 bronze badges
asked May 23 at 11:34
stzvggmdstzvggmd
4182 silver badges6 bronze badges
4182 silver badges6 bronze badges
marked as duplicate by forest, Tobi Nary, Conor Mancone, LvB, A. Hersean May 29 at 9:33
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by forest, Tobi Nary, Conor Mancone, LvB, A. Hersean May 29 at 9:33
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by forest, Tobi Nary, Conor Mancone, LvB, A. Hersean May 29 at 9:33
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
42
You might want to check this out: plaintextoffenders.com
– Axel2D
May 23 at 12:45
7
With that security concept, one almost wonders why they bothered to add thetype="password"attribute
– Hagen von Eitzen
May 23 at 21:01
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 at 12:29
6
@zovits If that were the case, the password would not show up under thevalueattribute when inspecting the element.
– Herohtar
May 24 at 15:28
3
What site is this, so we can all make sure and never use it?
– RonJohn
May 25 at 12:25
|
show 5 more comments
42
You might want to check this out: plaintextoffenders.com
– Axel2D
May 23 at 12:45
7
With that security concept, one almost wonders why they bothered to add thetype="password"attribute
– Hagen von Eitzen
May 23 at 21:01
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 at 12:29
6
@zovits If that were the case, the password would not show up under thevalueattribute when inspecting the element.
– Herohtar
May 24 at 15:28
3
What site is this, so we can all make sure and never use it?
– RonJohn
May 25 at 12:25
42
42
You might want to check this out: plaintextoffenders.com
– Axel2D
May 23 at 12:45
You might want to check this out: plaintextoffenders.com
– Axel2D
May 23 at 12:45
7
7
With that security concept, one almost wonders why they bothered to add the
type="password"attribute– Hagen von Eitzen
May 23 at 21:01
With that security concept, one almost wonders why they bothered to add the
type="password"attribute– Hagen von Eitzen
May 23 at 21:01
18
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 at 12:29
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 at 12:29
6
6
@zovits If that were the case, the password would not show up under the
value attribute when inspecting the element.– Herohtar
May 24 at 15:28
@zovits If that were the case, the password would not show up under the
value attribute when inspecting the element.– Herohtar
May 24 at 15:28
3
3
What site is this, so we can all make sure and never use it?
– RonJohn
May 25 at 12:25
What site is this, so we can all make sure and never use it?
– RonJohn
May 25 at 12:25
|
show 5 more comments
3 Answers
3
active
oldest
votes
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.
answered May 23 at 11:55
schroeder♦schroeder
84.5k34 gold badges188 silver badges227 bronze badges
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 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 at 21:12
23
@barbecue That is just as bad as plaintext...
– Luke Park
May 23 at 21:14
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 at 23:38
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 at 1:21
|
show 10 more comments
The plaintext password is a gaping security issue.
- 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].
- Second, sending the password over the wire when not strictly necessary is a second huge security mistake.
- 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.
answered May 24 at 7:21
TomTom
6,2879 silver badges37 bronze badges
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 at 7: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 at 7: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 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 at 10:56
2
@IEatBagels which is the vast majority of people.
– Tom
May 24 at 17:54
|
show 5 more comments
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.
answered May 24 at 10:53
DamonDamon
3,42012 silver badges19 bronze badges
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 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 at 11:38
add a comment |
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered May 23 at 11:55
schroeder♦schroeder
84.5k34 gold badges188 silver badges227 bronze badges
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 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 at 21:12
23
@barbecue That is just as bad as plaintext...
– Luke Park
May 23 at 21:14
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 at 23:38
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 at 1:21
|
show 10 more comments
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.
answered May 23 at 11:55
schroeder♦schroeder
84.5k34 gold badges188 silver badges227 bronze badges
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 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 at 21:12
23
@barbecue That is just as bad as plaintext...
– Luke Park
May 23 at 21:14
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 at 23:38
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 at 1:21
|
show 10 more comments
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.
answered May 23 at 11:55
schroeder♦schroeder
84.5k34 gold badges188 silver badges227 bronze badges
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.
answered May 23 at 11:55
schroeder♦schroeder
84.5k34 gold badges188 silver badges227 bronze badges
edited May 23 at 12:04
answered May 23 at 11:55
schroeder♦schroeder
84.5k34 gold badges188 silver badges227 bronze badges
answered May 23 at 11:55
schroeder♦schroeder
84.5k34 gold badges188 silver badges227 bronze badges
answered May 23 at 11:55
schroeder♦schroeder
84.5k34 gold badges188 silver badges227 bronze badges
84.5k34 gold badges188 silver badges227 bronze badges
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 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 at 21:12
23
@barbecue That is just as bad as plaintext...
– Luke Park
May 23 at 21:14
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 at 23:38
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 at 1:21
|
show 10 more comments
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 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 at 21:12
23
@barbecue That is just as bad as plaintext...
– Luke Park
May 23 at 21:14
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 at 23:38
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 at 1:21
12
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 at 21:11
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 at 21:11
42
42
@barbecue eek - decrypting the password and sending it back to the client? That adds a whole new layer of ick
– schroeder♦
May 23 at 21:12
@barbecue eek - decrypting the password and sending it back to the client? That adds a whole new layer of ick
– schroeder♦
May 23 at 21:12
23
23
@barbecue That is just as bad as plaintext...
– Luke Park
May 23 at 21:14
@barbecue That is just as bad as plaintext...
– Luke Park
May 23 at 21:14
11
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 at 23:38
@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 at 23:38
12
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 at 1:21
@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 at 1:21
|
show 10 more comments
The plaintext password is a gaping security issue.
- 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].
- Second, sending the password over the wire when not strictly necessary is a second huge security mistake.
- 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.
answered May 24 at 7:21
TomTom
6,2879 silver badges37 bronze badges
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 at 7: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 at 7: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 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 at 10:56
2
@IEatBagels which is the vast majority of people.
– Tom
May 24 at 17:54
|
show 5 more comments
The plaintext password is a gaping security issue.
- 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].
- Second, sending the password over the wire when not strictly necessary is a second huge security mistake.
- 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.
answered May 24 at 7:21
TomTom
6,2879 silver badges37 bronze badges
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 at 7: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 at 7: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 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 at 10:56
2
@IEatBagels which is the vast majority of people.
– Tom
May 24 at 17:54
|
show 5 more comments
The plaintext password is a gaping security issue.
- 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].
- Second, sending the password over the wire when not strictly necessary is a second huge security mistake.
- 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.
answered May 24 at 7:21
TomTom
6,2879 silver badges37 bronze badges
The plaintext password is a gaping security issue.
- 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].
- Second, sending the password over the wire when not strictly necessary is a second huge security mistake.
- 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.
answered May 24 at 7:21
TomTom
6,2879 silver badges37 bronze badges
edited May 26 at 16:30
answered May 24 at 7:21
TomTom
6,2879 silver badges37 bronze badges
answered May 24 at 7:21
TomTom
6,2879 silver badges37 bronze badges
answered May 24 at 7:21
TomTom
6,2879 silver badges37 bronze badges
6,2879 silver badges37 bronze badges
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 at 7: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 at 7: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 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 at 10:56
2
@IEatBagels which is the vast majority of people.
– Tom
May 24 at 17:54
|
show 5 more comments
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 at 7: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 at 7: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 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 at 10:56
2
@IEatBagels which is the vast majority of people.
– Tom
May 24 at 17:54
2
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 at 7:44
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 at 7:44
7
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 at 7:52
@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 at 7:52
9
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 at 10:45
@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 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 at 10:56
@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 at 10:56
2
2
@IEatBagels which is the vast majority of people.
– Tom
May 24 at 17:54
@IEatBagels which is the vast majority of people.
– Tom
May 24 at 17:54
|
show 5 more comments
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.
answered May 24 at 10:53
DamonDamon
3,42012 silver badges19 bronze badges
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 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 at 11:38
add a comment |
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.
answered May 24 at 10:53
DamonDamon
3,42012 silver badges19 bronze badges
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 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 at 11:38
add a comment |
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.
answered May 24 at 10:53
DamonDamon
3,42012 silver badges19 bronze badges
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.
answered May 24 at 10:53
DamonDamon
3,42012 silver badges19 bronze badges
answered May 24 at 10:53
DamonDamon
3,42012 silver badges19 bronze badges
answered May 24 at 10:53
DamonDamon
3,42012 silver badges19 bronze badges
answered May 24 at 10:53
DamonDamon
3,42012 silver badges19 bronze badges
3,42012 silver badges19 bronze badges
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 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 at 11:38
add a comment |
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 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 at 11:38
2
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 at 11:01
"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 at 11:01
2
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 at 11:38
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 at 11:38
add a comment |
42
You might want to check this out: plaintextoffenders.com
– Axel2D
May 23 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 at 21:01
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 at 12:29
6
@zovits If that were the case, the password would not show up under the
valueattribute when inspecting the element.– Herohtar
May 24 at 15:28
3
What site is this, so we can all make sure and never use it?
– RonJohn
May 25 at 12:25