NOTE: I am aware that many similar questions exist on the topic of storing passwords safely, however, I am posting this because I believe it is different enough from existing password storage questions because this question is primarily about how a service can securely send the user a randomly-generated password in plaintext and yet keep it secure on their end (I.e. in the database) instead of storing a user-provided password securely.

I noticed the VPN service I use (PIA) is on the list of plain text offenders, and my biased opinion is that they don’t. Regardless, I’m wondering if it is indeed a good idea for a service like PIA to generate user passwords and send them to the user in plaintext while still securely storing them in a database using best practices as described elsewhere (hashing, salting, multiple iterations, etc).

If I were to implement something like this, my thought would be to make a flow something like this:

  1. User signs up (and doesnt provide a password)
  2. Generate a password and temporarily store it
  3. Transmit the password in plaintext to the user via whatever method
  4. Hash the password and store it in the database
  5. Permanently delete the stored plaintext password and/or overwrite it a bit.

My question is, is it possible to achieve the functionality described above in bold either in a way similar to what is listed above or in a different way?

Note: I am not asking about the security of transmitting the password, just about if there is a good way for the service to keep it secure on their end while still being able to send the user their password in the clear.

  • Office365 does the same thing
    – schroeder
    Commented May 2, 2018 at 22:55
  • 1
    A "reasonable possibility of being a secure way" is the wrong way of looking at it. The question is, does it counter the threats that the system is exposed to.
    – schroeder
    Commented May 2, 2018 at 22:56
  • It might be notable to add that PIA accounts seem to delete themselves if your subscription expires (also usernames cannot be changed and are randomly generated by their system) Commented May 2, 2018 at 22:56
  • Possible duplicate? security.stackexchange.com/questions/7045/…
    – schroeder
    Commented May 2, 2018 at 22:57
  • 1
    @forest I acknowledge my opinion doesn’t matter, and I agree that plaintext offenders requires proof, however, they accept a screenshot of an email with a plaintext password as proof, which could easily falsely categorize sites that use the method I described in my question as “offenders” when they may actually be securely storing passwords. Commented May 3, 2018 at 2:00

4 Answers 4


The best idea here, to avoid storing the password at all, is to have a key K that only your server knows. Then when a user signs up, you create a link like: signup.php?username=xxxx&[email protected]&password=randomrandom&expiry=nnnnnnnnnn&hash=(*)

(*) then consist of sha256(K + ":" + [email protected] + ":" + xxxx + ":" + randomrandom + ":" + nnnnnnnnnn)

By using this method, you don't need to store anything at all. When user signs up, the only thing that happens is that above link is generated and sent, nothing is stored in database.

When the link is clicked, then the account is created for real. (Of course, you need to recheck that the username is not taken and that the email is not already registred for example)

This ensures that nothing needs to be stored until the action has been fully completed by the user.

You can also have that above link to directly create & login the user (without any initial random password) and have the user select a password on first visit.

  • It's generally better to use HMAC for signing instead of simple hashes like SHA256, as the latter are often vulnerable to length extension attacks. Commented May 3, 2018 at 15:09

So after a conversation in chat with @forest, I arrived at the answer/confirmation I was looking for. Essentially, yes, something like what I was asking is possible to do, but it would only be truly secure if the method of transmission was secure too.

If they sent it [the password] via a medium as secure as the password submission form, it would be fine. If a one-time password were used, there would be a window for attack if the OTP were sent over an insecure medium, but it wouldn't be nearly as severe.


So, if we ignore the insecurity of email then you're saying:

  1. User signs up
  2. Service generates password
  3. Service salts, hashes and stores password
  4. Service security sends password to user by some unspecified method

Well yeah, that better be secure as some services today do that, though most let the user specify a password.

As for securing the emailing of the password, what you want to do is to be to have one party share a secret with a second party without having any offline way of pre-sharing a secret. The only way I'm aware of to securely transfer data between two parties that aren't interactively communicating with one another, and don't have a pre-shared secret, is public key encryption. So, if you had a way to independently generate a public/private key pair and you specified your public key when you signed up for the service, the service could encrypt your password using your public key and you could decrypt with your private key when you received the email.

  • This answer seems mostly based on securing the transmission of the password. I am just curious how the service that is generating the password can securely store it and still send it to their user just like the steps in my question Commented May 3, 2018 at 1:41
  • Generating and securing a password on a service is easy: generate a random password of some length (say at least eight characters), salt it and hash it. You're done. Commented May 6, 2018 at 13:52

I am not asking about the security of transmitting the password, just about if there is a good way for the service to keep it secure on their end while still being able to send the user their password in the clear.

Well, if you are comfortable with them, anyone who hacks them, any rogue employees, and probably {whatever country they operate in}'s secret services having access to your password, for no good reason, just because you trust them, then that's perfectly secure!

There is no good reason because there are solutions to password storage which do not need to store your actual password. See this question: How to securely hash passwords?

Perhaps there could be a use-case for being able to retrieve a plaintext password, but off the top of my head, I can't think of any, especially for this application (a VPN service). I see no need for storing it in a retrievable manner.

Whether plaintext offenders is correct is out of scope here, I'm not saying anything about that. But if they store your password plaintext, then that's just stupid. I cannot think of any justification.

So is it secure? Yes, so long as they don't get hacked, none of their employees go sour, and they don't get any infamous national security letters (or their country's equivalent). Not sure I'd want to bet on that.

  • Apologies for the ambiguity, i meant to ask if there is a way companies can send their users a generated password in plaintext one time when the user creates the account. I totally agree with you that storing passwords in a retrievable manner is a terrible idea. Commented May 3, 2018 at 14:24
  • @DeveloperACE Sure, someone could write something along the lines of pass = generatePassword(); mail(user, pass); hashedpass = hash(pass); store(hashedpass); delete(pass);
    – Luc
    Commented May 3, 2018 at 21:02
  • Or just pass = null; instead of calling a delete method Commented May 3, 2018 at 22:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .