4

This question already has an answer here:

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.

marked as duplicate by AndrolGenhald, S.L. Barth, forest, Overmind, multithr3at3d Jul 27 '18 at 1:35

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.

  • 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
  • 2
4

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.

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.

  • 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 5:33

Not the answer you're looking for? Browse other questions tagged or ask your own question.