Recently I applied for a job at a company creating

security-critical solutions for military, aerospace, ...

After registering at their webpage, I received an email with my username and a plaintext one-time password. My first reaction was to jump in horror at their incompetence, especially given that security should be their core competence, but after giving it a second thought, I realized that I am a new user and that nothing is at stake yet. But afterwards I see that their password reset feature actually sends a plaintext one-time password.

This got me thinking, is it really so bad to send a one-time password in plaintext? Especially when someone who claims to make a living out of security does so?

I was reading this highly upvoted answer saying that you should never send any passwords by e-mail. Instead if your user forgets his password, you should send them a one-time password reset link.

But what is the fundamental difference between a one-time password and a one-time link?

So far, I couldn't find any. The closest two clues I got are:

  1. The highly upvoted answer mentions that:

    Do all of this over SSL.

    That is, send the one-time link over SSL. I do not understand this point at all. How can you send someone a one-time reset link (in email presumably) over SSL?

  2. There was a comment by @Anders under this question mentioning that a link will expire, but a one-time password will not. But again, I do not buy this. Passwords do expire if you want them to.

Furthermore, if the user has a username which is different from his email address, then a one-time password can be actually safer than a password reset link. Anybody can intercept the link, log in, and steal data, but if it is only the user who knows the username, then only he can use the one-time password.

You know how people dealing with information security react when they hear the words password and plaintext in the same sentence, right? If a one-time password reset link is just a one-time username+password, then this practice should be looked down upon even more, am I right?

All in all: Does sending one-time passwords over email in plaintext mean absolute incompetence?

  • Your last paragraph misses the key: You are talking about ONE-TIME-Passwords in plain-text. Please correct that, if you are not absolutely meaning ordinary passwords. – Marcel Jan 20 '17 at 13:39
  • Does the last sentence implies that you suppose that the one-time random password is not hashed before stored in db ? – elsadek Jan 20 '17 at 17:00

I don't know exactly why @Polynomial suggested what he suggested but here is what I think about your confusion.

is it really so bad to send a one-time password in plaintext?

I don't believe so. For a malicious user to misuse this, they would need to have access to your mailbox or as you say, the username. Though username might not always be applicable. If you are sent a password reset link, even in that case the attacker will have to have access to your mail.
The areas where I believe the password reset link wins over the one time passwords is that when you implement one time password, you need to do the following:

  • Ensure that the password is changed immediately when the user logs in. What if a user and the malicious user both enter the website simultaneously before the password is reset?
  • Limit/throttle the number of invalid requests that can be made at password reset using the one time password. What if an attacker tries bruteforce/dictionary attack on the password reset feature? If you have a one time password reset link, you will not have to worry about them.

Does sending passwords over email in plaintext mean absolute incompetence?

Nope. It's just a different philosophy.

  • I'm not agreeing with this. Sending a password via e-mail albeit a temporary password and even when you need to change it immediately after login is still no good. It's still a password stored in an insecure medium and besides a crap user experience. As the password is immediately changed in the system a malicious user can just do a DoS and lock someone out of his account – John Opdenakker Jan 20 '17 at 14:51
  • @JohnOpdenakker That does depend on the implementation doesn't it? You can have a system that sends one time password and just doesn't expire the one time password. In that case the password remains there till either the user or malicious user uses it. But the OP said that he was keeping such requirements in his system. So I didn't cover those points – Limit Jan 20 '17 at 14:53
  • Like I understood the plain text password was a persisted password in the database. If so, even very shortly you can be locked out your account. That's why I would always prefer the link. Anyway I understand now why you gave that answer – John Opdenakker Jan 20 '17 at 15:14

This could be fine - after all a password reset email contains a "one time password", albeit one that is really a secret key and based upon a long, pseudo random sequence that is unfeasible to brute force.

Also, this could also mean there is a Denial of Service attack against a legitimate user:

  1. Attacker goes to website, knows that Bob@example.com is a user (e.g. through a username enumeration vulnerability).
  2. Attacker presses to reset Bob's password.
  3. New temporary, secure password sent to Bob@exmaple.com
  4. Bob, without current access to his email now cannot log into the system.

Password reset links do not have this flaw, however minor it may be to the system in question.

If temporary passwords are issued, it would be wise to generate one with at least 80 bits of entropy (the current NIST recommendation), and force the user to change it immediately on login, even if they "force browse" to any other URL in the authenticated section of your website. i.e. it should redirect them back to the change password screen until they do, and it should also make sure that they select a different password.

The other problem you've now got it that if the user does not use the temporary password immediately. You've got a password sitting in cleartext in the user's mailbox, which isn't the best location for password storage. You may have to expire this password somehow, leading to additional complexity in your application. Having separate password reset links simplifies things, as its only the instance of a link itself that expires, not their primary password.

In short, it is much easier and more secure to have a separate password reset mechanism that doesn't touch the user's password until they've confirmed that they can in fact access the mailbox associated to the account.


A one-time password and a reset link could be implemented in such a way that they are functionally equivalent. In practice though, a one-time password is probably slightly more secure.

Consider the following reset link:


Compared with a one-time password of:


The typical workflow for the reset link is:

  1. Click on the link.
  2. You are presented with a screen to change your password.
  3. Enter in your new password, confirm it, save.

The typical workflow for the one-time password is:

  1. Go to the login page.
  2. Enter in your username and your one-time password.
  3. (Behind the scenes your one-time password is now invalidated.) You are presented with a screen to change your password.
  4. Enter in your new password, confirm it, save.

The reason the one-time password is slightly more secure is, as you pointed out, with the one-time password you still need to know your username, whereas typically a reset link does not require you to enter your username. Also, once you have entered in the one-time password, it likely would be immediately invalidated and can no longer be re-used, whereas a reset link typically can be clicked more than once as long as you don't submit the new password change.

In order to make them functionally equivalent, after clicking the reset link you would have to immediately expire the link, and also ask the user to enter in their username along with their new password. Note that one potential downside to immediately expiring the reset link after the first click is that some email and anti-virus programs will follow links to check for malicious content, and this could expire the link before you get the chance to click it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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