2

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.

DeveloperACE
  • 170
  • 9
  • Office365 does the same thing – schroeder May 02 '18 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 May 02 '18 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) – DeveloperACE May 02 '18 at 22:56
  • Possible duplicate? https://security.stackexchange.com/questions/7045/sending-temp-password-when-users-first-registered-is-that-good-for-anything – schroeder May 02 '18 at 22:57
  • @schroeder yeah, that question is essentially the same as this, I’m just wondering how this kind of thing can be done securely on the service’s side – DeveloperACE May 02 '18 at 23:03
  • As long as the password is used only once and the user is forced to change it on first use, this should be okay (and handled not differently than a regular password. I cannot see where this is not a duplicate on how to store passwords or the question @schroeder linked. – Tobi Nary May 02 '18 at 23:53
  • `however I really doubt that they would do such a thing given that they otherwise seem fully committed to privacy and security` Even years later (last I heard), PIA still hasn't fixed a trivial deanonymization bug caused by their poor NAT configuration. – forest May 03 '18 at 00:44
  • @forest is that still an issue? – DeveloperACE May 03 '18 at 01:35
  • As far as I'm aware. I think it was hdm who found it out (you'd have to ask him for details). – forest May 03 '18 at 01:36
  • @SmokeDispenser it’s very similar I agree. I feel like this is more like “how to securely send a user their password when you automatically generate it” than it is “how to store what the user gives you” – DeveloperACE May 03 '18 at 01:37
  • Plaintext Offenders requires proof, so if PIA is on there, your opinion doesn't matter. – forest May 03 '18 at 01:56
  • 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. – DeveloperACE May 03 '18 at 02:00
  • So verify it yourself using whatever method was claimed (many people already do this). PIA does _not_ have great security practice in their networking configuration, so I would not be surprised at all if they also did not have good password security. [Apparently others have noticed](https://www.privateinternetaccess.com/forum/discussion/18295/security-101) and PIA doesn't care. – forest May 03 '18 at 02:01
  • @forest as i said i am already a customer and i have recieved my email with my password, however, i am asking this because to me it is theoretically possible to be secure and still send users a password in plaintext, which is *why i asked this question* – DeveloperACE May 03 '18 at 02:25
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/76936/discussion-between-developerace-and-forest). – DeveloperACE May 03 '18 at 02:29

4 Answers4

3

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=myemail@domain.tld&password=randomrandom&expiry=nnnnnnnnnn&hash=(*)

(*) then consist of sha256(K + ":" + myemail@domain.tld + ":" + 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.

sebastian nielsen
  • 8,779
  • 1
  • 19
  • 33
  • It's generally better to use [HMAC](https://en.wikipedia.org/wiki/HMAC) for signing instead of simple hashes like SHA256, as the latter are often vulnerable to length extension attacks. – Marc Schütz May 03 '18 at 15:09
1

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.

DeveloperACE
  • 170
  • 9
0

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.

Swashbuckler
  • 2,115
  • 8
  • 9
  • 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 – DeveloperACE May 03 '18 at 01: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. – Swashbuckler May 06 '18 at 13:52
0

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.

Luc
  • 31,973
  • 8
  • 71
  • 135
  • 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. – DeveloperACE May 03 '18 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 May 03 '18 at 21:02
  • Or just `pass = null;` instead of calling a delete method – DeveloperACE May 03 '18 at 22:17