44

What's wrong with generating a password for you without storing it?

Like why is MasterCard on the plain text offenders list?

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
Ulkoma
  • 8,793
  • 16
  • 65
  • 95
  • 48
    Because exactly this, they email your password in plain text. – Marcel Mar 17 '16 at 14:54
  • Is the question about emailing passwords or about displaying passwords on a browser? All the answers so far focus on email, i've seen some sites show you a new random password in the browser window, in a HTTPS session. – Mindwin Mar 17 '16 at 17:21
  • 7
    @Mindwin I am asking because I found it rather wrong (in my opinion) to call such sites plain text offenders, they generate the password to help you and they send it to your email, that's all. They don't store the password and if your email is compromised or if you don't change the password the issued for you how is this their problem? – Ulkoma Mar 17 '16 at 17:24
  • 16
    there you got it wrong. I change the keys to your car, and I toss them for you to catch. A thief jumps up in the air and snatches the key. Whose fault is it, for the key to be up in the air? Yours? You did not catch the key in time, so I can walk away without guilt, in your interpretation of the issue. The folks there disagree. – Mindwin Mar 17 '16 at 17:30
  • 8
    @Mindwin OK, so the problem is with the email right? well the reset link is also sent via email and the thief can easily jump in the air and steal the keys and it doesn't matter to him if they were a password or a reset link? – Ulkoma Mar 17 '16 at 17:35
  • 2
    still not there. check http://security.stackexchange.com/a/13042/44336 – Mindwin Mar 17 '16 at 18:12
  • 2
    @Mindwin I am particularly a fan of the "same session" method since it would be easy to just use the reset link within a short period of time and if there's a man-in-the-middle it's all too possible they are behind the same router as you (same public ip). Very good point, though! – d0nut Mar 17 '16 at 18:24
  • 10
    @Mindwin: Rather than "catching" the key, the thief takes a photo of the key in the air and then produces a key from it. Much better analogy since you don't know they did it. – R.. GitHub STOP HELPING ICE Mar 17 '16 at 18:24
  • 3
    I can't think how this is any worse than sending a unique password reset link, which seems to be the standard for websites, as the url is still sent as plaintext. As long as after the first log in with the supplied password, it forces you to change it before you continue, I can see no difference. – Adi Bradfield Mar 18 '16 at 10:48
  • @AdiBradfield exactly! That's what I was wondering as well – Ulkoma Mar 18 '16 at 10:50
  • @Ulkoma see the answers on this new question, why is this considered goo, but sending the temporary password by email considered bad? security.stackexchange.com/questions/117854/how-to-implement-forgot-password-functionality – Adi Bradfield Mar 18 '16 at 13:20
  • 1
    @Ulkoma did you read the link that Mindwin posted? With a verification link, you can check that the client that attempted to create the verification link has the same session as the one who is visiting the link. If they do, then it should be the same user. – d0nut Mar 18 '16 at 13:48
  • 1
    @iismathwizard I know, but I have tried using two different browsers one for requesting a new password and one for browsing the reset link and it worked so I highly doubt that many sites use that, should we call them plain text offenders as well? – Ulkoma Mar 18 '16 at 13:50
  • 1
    @Ulkoma personally, I think so. – d0nut Mar 18 '16 at 13:55
  • @iismathwizard I'll contact that website and make them aware of this question. – Ulkoma Mar 18 '16 at 13:57
  • @iismathwizard. Couldn't the same verification (same session/same ip) be performed with a temporary password as with a temporary 'reset' link? Who is to say they don't do that, or that the temporary password doesn't expire in 30 minutes or so on? PlainTextOffenders is rapidly becoming a worthless site because of these additions which no-one can verify the security of. Was much more useful when it had only legitimate 'passwords stored in plain text' entries. – PaulG Mar 18 '16 at 17:24
  • @PaulG password expiration (especially at 30 minutes) it's not particularly useful since the password is captured en transit via email and then could easily be used within 30 minutes and before the user. Yes, they could use the same verification on the temporary password but it, design wise, doesn't make as much sense to add validation to a similar/the-same login portal regarding the session and a temporary password. It makes significantly more sense to have a verification link (which leads to a separate portal where the link is part of the verification process as well as your session) – d0nut Mar 18 '16 at 17:44
  • My point is *we have no idea what verification they're doing*. It's equally possible that a reset password link could be done badly. – PaulG Mar 18 '16 at 18:37

4 Answers4

52

Because most users do not change their password after such a reset and mindlessly instruct their browser to save the new password and/or the site does not force users to change it after their first login.

Thus they effectivly send the new password in plain text, thus they are offenders.

A better way may be a One-Time-Token for a password reset, preferably sent via snail mail or SMS.

Tobi Nary
  • 14,302
  • 8
  • 43
  • 58
  • 20
    Interesting. I know I get impatient waiting 15 seconds for a reset link to show up in my gmail box. I think I'd go nuts waiting for a letter to arrive! lol – loneboat Mar 17 '16 at 20:49
  • 10
    @loneboat, I just checked: some german portals (like where submitting tax things) do require you to freshly register which involves a secret sent by snail mail. – Tobi Nary Mar 17 '16 at 21:01
  • 4
    SMS should not completely replace email as an option. Phones may run out of battery, be lost, have no signal etc. and the mobile operator isn't necessarily more trustworthy or secure than the email provider. Mail would also need a smaller token (so that the user can type it in), which an attacker would have a lot more time to bruteforce. – Artur Gaspar Mar 18 '16 at 02:46
  • 1
    @loneboat HMRC (UK tax site) certainly sends part of the _initial_ registration details by post; it's possible they'd do the same for certain account recovery operations. – TripeHound Mar 18 '16 at 13:35
  • 3
    My bank (in the Netherlands) actually requires me to send a letter, and they will e-mail me with a token and the other token (as it's a pair) will be sent back by letter. It takes a few days, but it feels pretty secure. – Stephan Bijzitter Mar 18 '16 at 22:08
  • @loneboat try the Canada Revenue Agency My Account. They send passwords only in snail mail. – chx Mar 20 '16 at 16:34
  • Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/37274/discussion-on-answer-by-smokedispenser-why-would-a-website-that-resets-your-pass). – Rory Alsop Mar 21 '16 at 09:56
33

Email (SMTP/POP3/IMAP) is plaintext, so it's possible the password could be intercepted on the network or in storage by a third party.

wireghoul
  • 5,745
  • 2
  • 17
  • 26
  • pop3 and imap password (and smtp, if used) are indeed sent in plaintext; that's no reason for them to be STORED as plaintext - they should (and usually are) stored hashed (and, maybe, peppered and salted?). Also, these protocols should be (but aren't always) avoided in favour of their SSL counterparts, which would protect these in flight. – AMADANON Inc. Mar 18 '16 at 00:58
  • 1
    I was referring to the storage of the email containing the plaintext password – wireghoul Mar 18 '16 at 06:28
  • Well, that's equally true of a password reset link, isn't it? – Casey Mar 19 '16 at 03:59
  • 1
    Not quite, if someone used a reset link to change your password you could notice. If someone was using your password you probably couldn't tell. – wireghoul Mar 19 '16 at 11:30
  • 1
    Reset links SHOULD be only valid for a very small time period, which severely reduces the time an attacker has to set his own password and which you would indeed notice. And if I intercept a reset password-mail that is 6 months old and has the password in the mail (or if I retrieve e mail from monitoring or sniffing software), I would still be able to use that password. The nature of e-mail cannot guarantee that no mail is stored in plaintext somewhere on a server between sender and receiver, hence this is considered an offender. – JDT Mar 19 '16 at 13:37
19

The description in the About section of their page gives me the impression that the definition of Plain Text Offender depends solely on the storing of data:

A website storing a password in plain text means that your password is there, waiting for someone to come and take it. It doesn’t even matter if you’ve created the strongest possible password. It’s just there.

Whether it’s someone hacking into their servers, using a simple flaw in their site or even stealing their backups, over 30% of sites store plain text passwords.

We’re tired of websites abusing our trust and storing our passwords in plain text, exposing us to danger. Here we put websites we believe to be practicing this to shame.

(emphasis mine)

Reading this, it does sound like having a newly generated password emailed to you would not necessarily make the company a Plain Text Offender according to their definition. That is assuming they still STORE the password hashed (and hopefully salted).

I would however say that emailing a user their password is not ideal regardless, for reasons stated by SmokeDispenser and wireghoul.

Fluffy
  • 437
  • 2
  • 9
18

There might be 50 shades of gray area regarding how bad the violation is. Here's a suggested order beginning with the worst offense:

  1. User creates their own password. User forgets password and the system emails them the password they originally created. This is the granddaddy of plain text offenders because it is vulnerable to a multitude of attacks. Available attack vectors: Intercepted email on the fly, access to email account in the future, database dump with passwords stored either in plain text or reversible encryption. Furthermore, once the password is known it is possible the user used it or a similar password on other sites, leading to a possible attack of the user's accounts elsewhere.
  2. User creates their own password, system immediately sends them a copy of their password (for their records). Available attack vectors: Intercepted email on the fly, access to email account in the future, possible database dump (in this case we don't know if the system stores the password in a reversible fashion, they could be hashing after sending the email). Shared password elsewhere.
  3. User creates their own password. User forgets password and the system regenerates a new random password and emails the new one to the user. Available attack vectors: Intercepted email on the fly, access to email account in the future. Note: the system could recommend that the user change their password, but the user may not do so.
  4. User creates their own password. User forgets password and the system regenerates a new temporary password and emails the new one to the user. Available attack vectors: Intercepted email on the fly, access to email account in the future, if the user has not logged in yet to change their password. Note: typically temporary passwords do not expire until after the first login.
  5. User creates their own password. User forgets password and the system emails a password reset link to the user. Available attack vectors: Intercepted email on the fly, access to email account in the future, if the user has not logged in yet to change their password. Note: this is basically the same thing as the temporary password.
  6. User creates their own password. User forgets password and the system emails a password reset link to the user which expires after a certain amount of time. Available attack vectors: Intercepted email on the fly, access to email account during the reset period if the user has not logged in yet to change their password.

Notes:

  • The above list is based on what you as a user can observe. Behind the scenes, we hope that all but #1 are hashing passwords in a secure way in case the database is ever compromised, but obviously you can't know that for sure.
  • Expiring a temporary password or reset link is useful for the scenario where the user requests the reset, and then walks away, and doesn't come back for a long time, or ever.
  • There should be a big line drawn between #2 and #3. The first 2 options are considered bad, and those are the types of offenders that Plain Text Offenders are trying to protect you from. #3 is iffy, but if the site doesn't store any personal information it probably isn't a big deal. If a bank does #3 (and it sounds like MC is using this option), then I'd personally declare it a should-fix asap, simply because if the user doesn't change their password, and someone compromises their email account in the future, their personal finances could be at risk. Ideally, for all new sites and upgrades, #6 should be the way to go.

Final Note: if an attacker has open ended access to your email account, you might argue that even #6 doesn't protect you, since the attacker could go reset your password on a banking site, receive the reset link and change your password, then login to the site. This is absolutely true. However, the next time you try to login to the site you will be unable to, and hopefully you will come to the conclusion that something isn't right, which will lead to another password change and possibly a password change on your email account too. Some sites will even tell you the last time you changed your password to help you come to that conclusion on your own.

TTT
  • 9,122
  • 4
  • 19
  • 31
  • 4, 5 & 6 can (and probably should) also require the user to complete 2 factor authentication before the system accepts a password change, which makes them somewhat less vulnerable to on-the-fly attacks or email compromise. The first three can do that too, but it isn't particularly useful if the password is still sitting in the user's email afterward. – IllusiveBrian Mar 17 '16 at 21:31
  • 3
    @Namfuak - Great points. I agree with *can* but not necessarily with *and probably should*. TFA is best implemented when there is something more important to protect than the TFA mechanism itself. For example, it may make sense to use TFA for a banking site, but maybe not for a site that provides paid (but inexpensive) access to certain content and does not store personal information beyond the account login. In the latter case an attacker with access can't really do much harm, so adding complexity and/or another piece of data to be potentially compromised isn't necessary. – TTT Mar 17 '16 at 21:49