5

It seems like plaintextoffenders.com sees sending a plaintext recovery password as wrong. Instead, a link to set a password is better. But what's the difference? If a user follows a link and sets a password, or gets a password, logs on, and changes it, the danger seems the same. If someone intercepts the email between following the link or between logging on and changing the password - they can both impersonate the user.

To be clear, I'm referring to a new temporary password. Only password hashes (PBKDF2, scrypt, ...) are stored on the server.

EDIT

Since I'm asked why I think plaintextoffenders include new passwords, take a look. Currently, the 5th, 6th, 7th, and 8th are explicitly new passwords.

AndrolGenhald
  • 15,436
  • 5
  • 45
  • 50
ispiro
  • 773
  • 1
  • 7
  • 18
  • Could you reference where the site says that? Everything I see is talking about _your own_ password being emailed back to you, not a randomly generated temporary password. – AndrolGenhald Jul 16 '18 at 18:21
  • 1
    ....if you get a password, normally you might expect to type it, which will necessitate it being shorter/typeable. A link could be of potentially any length. – Clockwork-Muse Jul 16 '18 at 18:23
  • @AndrolGenhald A quick glance shows that of the first 4 at the moment, only the 1st is what you're saying. The other 3 seem to be for the first login. There is no reason to think that passwords are stored unhashed. – ispiro Jul 16 '18 at 18:24
  • @Clockwork-Muse The difference is small for a reset password. It would only matter if it's _very_ short, or if someone hacks into the site at exactly those couple of minutes. Besides, a password sent by email will just be copied and pasted. – ispiro Jul 16 '18 at 18:26
  • @AndrolGenhald Also see http://plaintextoffenders.com/faq/devs number 9. – ispiro Jul 16 '18 at 18:28
  • @ispiro I see that they recommend using a reset link, and I think most people would agree that's best practice if for no other reason than convenience, but I don't see where they actually say sending a randomly generated temporary password is bad. – AndrolGenhald Jul 16 '18 at 18:30
  • @AndrolGenhald That's apparent from them posting all of those screenshots, where there's no reason to believe that those passwords are the users' saved passwords. – ispiro Jul 16 '18 at 18:32
  • All of them I'm seeing are blacked out, and I see no reason to believe they _aren't_ the users' saved passwords. Perhaps most people don't want to go through the trouble of creating a throwaway account just for the screenshot, so they use the email with their actual password? – AndrolGenhald Jul 16 '18 at 18:34
  • @AndrolGenhald OK. So I checked more. The fifth one is explicitly a new one. [Here's the link](http://plaintextoffenders.com/post/175808707271/ausspecscomau-eyeglasses-retailer-sent-an). Though I agree that they should've asked the user to change their password. And so are the 6th 7th and 8th. – ispiro Jul 16 '18 at 18:36
  • 5th one [here](http://plaintextoffenders.com/archive) or [here](https://github.com/plaintextoffenders/plaintextoffenders/blob/master/offenders.csv)? Looking at the 5th image from the first link, at first I thought you were correct based on the wording of that email, but the right side of the image has a conversation that indicates passwords are encrypted instead of hashed. – AndrolGenhald Jul 16 '18 at 18:40
  • @AndrolGenhald Neither. On the "url" I have as the 4th word in the question. – ispiro Jul 16 '18 at 18:42
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/80244/discussion-between-androlgenhald-and-ispiro). – AndrolGenhald Jul 16 '18 at 18:44
  • @ispiro If I added the wrong links, could you please add the correct ones yourself? Since new sites get added it would be good for future readers to know which ones you're actually referring to. – AndrolGenhald Jul 16 '18 at 19:08
  • @AndrolGenhald I don't mind you adding the links, but as I wrote, they're the currently 5-8 which explicitly state that they are new. The 4th one is only implied by the submitter in their text under it. – ispiro Jul 16 '18 at 19:11
  • @ispiro [This](http://plaintextoffenders.com/post/175704253524/logocrispcom-logo-creator) is the 8th one I currently see, and I don't see where that one implies that it's generated rather than set by the user, so I'd thought you were just off by 1. – AndrolGenhald Jul 16 '18 at 19:13
  • 2
    Possible duplicate of [Is sending password to user email secure?](https://security.stackexchange.com/questions/17979/) or [Forgot Password? - sends email with plaintext password](https://security.stackexchange.com/questions/43795/) or [Temporary passwords e-mailed out as plain text](https://security.stackexchange.com/questions/32589/). – Steffen Ullrich Jul 16 '18 at 19:14
  • Security aspects asides, getting temp passwords by email is ANNOYING. Now I have to copy&paste it, login, probably paste it again as the old password so I can change it. All this instead of getting a simple link via email that shows me a form where I can enter a new password... – ThiefMaster Jul 16 '18 at 22:03

2 Answers2

5

If a user follows a link and sets a password, or gets a password, logs on, and changes it, the danger seems the same.

Based on all of the posts there I've looked at, I think the problem is with "and changes it". None of the emails there I've seen give any indication that the password is temporary and will need to be changed. Without wanting to bother creating a bunch of accounts myself, I would be conservative and assume that, if the email doesn't say you'll need to change the password, the site won't force you to change it after logging in.

You are correct that there is no real difference between a temporary password and a reset link as long as the password has enough entropy. As mentioned in the comments, if the password is too short and the user waits a while before logging in, it could be susceptible to brute force. Since password fields should allow pasting anyway, a 20 character alphanumeric temporary password would be perfectly fine. Both the reset link and the temporary password could be implemented nearly identically, it's really just the difference between a POST and a GET.

AndrolGenhald
  • 15,436
  • 5
  • 45
  • 50
2

The reason why sending users their current plaintext passwords is bad boils down to "passwords must be stored in such a way that no one on the server side should ever be able to retrieve a user's plaintext password once they have entered it" (that means root, too). The reason passwords are hashed in the first place is precisely so that the only person who can possibly know the password is the user who entered it. This is the only way to ensure the user can't repudiate any actions taken on the grounds that someone else knows their password.

(For a little more historical information on how password hashing works and why it's important, see my answer to Why does MD5 hash starts from $1$ and SHA-512 from $6$? Isn't it weakness in itself?)

Sending users a new temporary password sidesteps that issue nicely, but that creates at least two other problems as mentioned by Troy Hunt on his blog https://www.troyhunt.com/everything-you-ever-wanted-to-know/ (referenced in item 9 of the Developer FAQs on the plaintextoffenders site: http://plaintextoffenders.com/faq/devs, which was mentioned in the comments on the question itself):

  1. the user is instantly locked out of their account with their normal password, which if they weren't the one expecting to reset their password creates an immediate Denial of Service (DOS) attack, and
  2. the login page where the site is expecting to receive the temporary password has no way of knowing it's temporary, and if not implemented properly this may result in the temporary password persisting longer than acceptable in this context.

To avoid these issues, the password reset landing page is separate from the normal login process, has a secret value which can be enforced with an https: URL, and does not invalidate the forgotten password until the ownership of the account has been re-established by the exchange of this value with the user via email.

Mike McManus
  • 1,415
  • 10
  • 17
  • 1
    This doesn't answer the question of why _temporary reset passwords_ can't be used instead of reset links. It's quite possible to email the plaintext temporary password while storing it hashed. – AndrolGenhald Jul 16 '18 at 21:02
  • 1
    From the question: `To be clear, I'm referring to a new temporary password. Only password hashes (PBKDF2, scrypt, ...) are stored on the server.`. – ispiro Jul 16 '18 at 21:07
  • 1
    OK, edited the answer to make clearer the case I'm responding to. – Mike McManus Jul 16 '18 at 21:35
  • This clearly depicts the problem of plaintext and/or temporary passwords. Every Developer should read this. +10 if I could! – Marcel Jul 17 '18 at 05:33