6 ms·

Ask HN: The correct way to email users their PLAINTEXT passwords.

10 points by chrisacky 15y ago

In about two weeks, I will be migrating about 5-600 paying customers from a website which my partner bought to the web application that I have been developing for the last year. When he said that I should start thinking about pulling all of the user accounts and user data from this older web application and creating everything on my application, I started thinking about how best to manage the user accounts... however, he then informed me that all of the account passwords are stored in plaintext. Now, seeing as my application definately does not store any passwords in plaintext, and I have access to the plaintext versions, do you think it appropriate, to just use this plaintext version when creating the new user accounts and then send out an email to the users to notify them that their information has been ported to our new application (and include their plaintext password alongside). We aren't some large company where it would make page 1 of HN if we sent out the plaintext version for this one time. Additionally, because people pay for a year in advance, it could be that some people actually don't remember their passwords, so there is some high value in giving them a friendly nudge. Thoughts? Alternate ideas would be a once use password free click link in the email.

JoachimSchipper 15y ago
Why don't you simply port the user accounts to your system (including passwords, stored hashed this time) and be done with it? "Plaintext passwords bad", of course, but I don't even see what you hope to gain - don't you already have a password recovery system for your current subscribers? (And a one-click-from-email login may be nice, but again - why not for current subscribers?)
- chrisacky 15y ago
  Yeah, don't think that I would maintain the plain text passwords. After I create the hashed version, I would drop the plain text and rm -rf the old site. (Well not quite but it will be on it's on from there on). My concern isn't so much about what to do in the future, because from here on out, we will only be using the hashed passwords... I guess the original question could of been summarized to: "Do you think that non-technical people realise that when they receive their passwords in an email that this is bad". Because I would like to make the transition for the users as easy as possible. They will now be accessing and editing their details from the new site.
  - japhyr 15y ago
    You can just tell the users that their old accounts should work perfectly well on the new system. You can't sort out "non-technical" people from technical people in your userbase. Bad practice is bad practice, and anything to do with plain text passwords is bad practice.
byoung2 15y ago
I just expereienced this a few days ago. I had some domains registered with an old shared hosting company that were up for renewal. I the few years since I last logged in, the company had been bought by a new company, so when I went to the website, I was redirected to the new site. I clicked the forgot password link and got an email with my password in plain text. It was so jarring to know that a web host and domain registrar would hold the keys to several domains (including the one that houses my email domain) in plain text. I transferred all of my domains to a new registrar who encrypts passwords. I would advise sending anyone a plain text password, because when you do, they will realize that not only did the old company store them that way, they also transferred them to a new company in plain text.
huxley 15y ago
Rather than emailing the passwords, you might want to look at the way Django does transparent upgrades of passwords. It has a prefix for the hashing algorithm at the beginning, so it can check which algorithm is being used for each password: sha1$a1976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4 So in your case, you could add a prefix 'txt$' in front of plain text passwords, and when the user successfully logs in, have it hash the password and save it in the database. The advantage of doing it the way Django does is that the "upgrade on successful login" lets you change your hash without causing problems with the users. Give the users a bonus or some reason for logging into their account and most of your passwords will get fixed automatically.
arghnoname 15y ago
You could send an e-mail that has a single use one-click autologin deal that takes them to their account preferences so they can do whatever they might want there. EDIT: To address the original question, if I got a plaintext back from a web site I know it's bad, but I don't reuse passwords, so for me it is not the end of the world (assuming it's not my bank or something!) Hopefully this is generally true of more technical users.
ColinWright 15y ago
I must be missing something - why not just hash all the plaintext passwords, store the hases on the new version of your site, and have it so when users login to the new site it does the right thing. Why should the users have to know anything?
- chrisacky 15y ago
  Because the original subscription was for 39.00 for a year, and some users might have done this a year ago. It would be nice for them to log in, check out the new platform, see how much uber awesomesauce it has, and then realise that if they get asked to renew again, that their new price of free, is definately worth relisting. It's just important to not lose any of the new users which this industry has a high churn rate (and we are providing the new service that they have previously been paying for for free, but we have a lot of upsells)
  - mattvot 15y ago
    Maybe I'm misunderstanding, but could you not just email the customers and tell them how much better the service is now? and hash the passwords as suggested
_ud4a 15y ago
as it was previously mentioned, i don't see the need to send any passwords to the user to begin with. you can just follow this flow: 1) Port all the username and password to the new site and hash the passwords 2) update the login mechanism to check against the hash password 3) send a note out to users saying "we've upgraded our site to a new system. You can still use your old credential to login with no problem. if you've forgotten your password use our "Password recovery" feature." then users can login just as they would before and the transition would be transparent. and if they've forgotten their password they can use the recovery feature on your site which would generate a new one for them.
brudgers 15y ago
Is the nature of your site such that unauthorized access will have significant impact on the health, safety, or welfare of the users? If you're a bank, plaintext passwords are bad. If you're HN, it really doesn't matter much(IMO). The level of security should match the level of the threat - most people don't need bodyguards for a trip to the grocery store. Yes, plaintext passwords are less secure, but they may be the result of business analysis regarding the costs associated with unauthorized access versus the costs associated with poor customer service when someone loses their password.
- chrisacky 15y ago
  Yes brudgers, that was the kind of analysis which I am waying, it is probably a kind of moot point, because I think that for this one time usage of plaintext, sending the users (who might have been inactive for 10 months and forgotten their password, a friendly reminder of it, outweights the potential fallout from a few users who are knowledgable enough to know that plaintext is bad. I was pretty shocked to be honest when I was told that this site used plain text. I didn't think anyone did that, but it is also a kind of blessing, since now we can merge the accounts exactly and keep the passwords. I just would hate for the new users to think that we store plain texts. Few options. 1) Transfer all the accounts from (old) site A to site B hash correctly then provide a one time URL that gets emailed and have them pick a new password immediately regardless. 2) Email them the plain text password and say here you go, but don't store plaintext. 3) Email something like this: Your password is knda*r (While trying to give some pseudo impression that you don't store the entire plaintext. 4) Transfer the accounts and don't tell them anything about their passwords, but point them to our forgotten password if they can't remember it.
  - brudgers 15y ago
    >"I was pretty shocked to be honest when I was told that this site used plain text. I didn't think anyone did that" Again, there may be a business case for doing so. If my HN password is compromised, the consequences are relatively trivial. Therefore if HN spent a lot of time dealing with lost passwords, it might make economic sense to store them in plaintext. If my Lloyds of London password is compromised, there are relatively significant consequences. Therefore, it should not be stored in plaintext. In other words, ask your client about their needs and their operation and determine the appropriate way to store the password based on those things not your preconceptions.

10 points by chrisacky 15y ago

JoachimSchipper 15y ago

Why don't you simply port the user accounts to your system (including passwords, stored hashed this time) and be done with it? "Plaintext passwords bad", of course, but I don't even see what you hope to gain - don't you already have a password recovery system for your current subscribers? (And a one-click-from-email login may be nice, but again - why not for current subscribers?)

chrisacky 15y ago
Yeah, don't think that I would maintain the plain text passwords. After I create the hashed version, I would drop the plain text and rm -rf the old site. (Well not quite but it will be on it's on from there on). My concern isn't so much about what to do in the future, because from here on out, we will only be using the hashed passwords... I guess the original question could of been summarized to: "Do you think that non-technical people realise that when they receive their passwords in an email that this is bad". Because I would like to make the transition for the users as easy as possible. They will now be accessing and editing their details from the new site.
- japhyr 15y ago
  You can just tell the users that their old accounts should work perfectly well on the new system. You can't sort out "non-technical" people from technical people in your userbase. Bad practice is bad practice, and anything to do with plain text passwords is bad practice.

byoung2 15y ago

I just expereienced this a few days ago. I had some domains registered with an old shared hosting company that were up for renewal. I the few years since I last logged in, the company had been bought by a new company, so when I went to the website, I was redirected to the new site. I clicked the forgot password link and got an email with my password in plain text. It was so jarring to know that a web host and domain registrar would hold the keys to several domains (including the one that houses my email domain) in plain text. I transferred all of my domains to a new registrar who encrypts passwords. I would advise sending anyone a plain text password, because when you do, they will realize that not only did the old company store them that way, they also transferred them to a new company in plain text.

huxley 15y ago

Rather than emailing the passwords, you might want to look at the way Django does transparent upgrades of passwords. It has a prefix for the hashing algorithm at the beginning, so it can check which algorithm is being used for each password: sha1$a1976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4 So in your case, you could add a prefix 'txt$' in front of plain text passwords, and when the user successfully logs in, have it hash the password and save it in the database. The advantage of doing it the way Django does is that the "upgrade on successful login" lets you change your hash without causing problems with the users. Give the users a bonus or some reason for logging into their account and most of your passwords will get fixed automatically.

arghnoname 15y ago

You could send an e-mail that has a single use one-click autologin deal that takes them to their account preferences so they can do whatever they might want there. EDIT: To address the original question, if I got a plaintext back from a web site I know it's bad, but I don't reuse passwords, so for me it is not the end of the world (assuming it's not my bank or something!) Hopefully this is generally true of more technical users.

ColinWright 15y ago

I must be missing something - why not just hash all the plaintext passwords, store the hases on the new version of your site, and have it so when users login to the new site it does the right thing. Why should the users have to know anything?

chrisacky 15y ago
Because the original subscription was for 39.00 for a year, and some users might have done this a year ago. It would be nice for them to log in, check out the new platform, see how much uber awesomesauce it has, and then realise that if they get asked to renew again, that their new price of free, is definately worth relisting. It's just important to not lose any of the new users which this industry has a high churn rate (and we are providing the new service that they have previously been paying for for free, but we have a lot of upsells)
- mattvot 15y ago
  Maybe I'm misunderstanding, but could you not just email the customers and tell them how much better the service is now? and hash the passwords as suggested

_ud4a 15y ago

as it was previously mentioned, i don't see the need to send any passwords to the user to begin with. you can just follow this flow: 1) Port all the username and password to the new site and hash the passwords 2) update the login mechanism to check against the hash password 3) send a note out to users saying "we've upgraded our site to a new system. You can still use your old credential to login with no problem. if you've forgotten your password use our "Password recovery" feature." then users can login just as they would before and the transition would be transparent. and if they've forgotten their password they can use the recovery feature on your site which would generate a new one for them.

brudgers 15y ago

Is the nature of your site such that unauthorized access will have significant impact on the health, safety, or welfare of the users? If you're a bank, plaintext passwords are bad. If you're HN, it really doesn't matter much(IMO). The level of security should match the level of the threat - most people don't need bodyguards for a trip to the grocery store. Yes, plaintext passwords are less secure, but they may be the result of business analysis regarding the costs associated with unauthorized access versus the costs associated with poor customer service when someone loses their password.

chrisacky 15y ago
Yes brudgers, that was the kind of analysis which I am waying, it is probably a kind of moot point, because I think that for this one time usage of plaintext, sending the users (who might have been inactive for 10 months and forgotten their password, a friendly reminder of it, outweights the potential fallout from a few users who are knowledgable enough to know that plaintext is bad. I was pretty shocked to be honest when I was told that this site used plain text. I didn't think anyone did that, but it is also a kind of blessing, since now we can merge the accounts exactly and keep the passwords. I just would hate for the new users to think that we store plain texts. Few options. 1) Transfer all the accounts from (old) site A to site B hash correctly then provide a one time URL that gets emailed and have them pick a new password immediately regardless. 2) Email them the plain text password and say here you go, but don't store plaintext. 3) Email something like this: Your password is knda*r (While trying to give some pseudo impression that you don't store the entire plaintext. 4) Transfer the accounts and don't tell them anything about their passwords, but point them to our forgotten password if they can't remember it.
- brudgers 15y ago
  >"I was pretty shocked to be honest when I was told that this site used plain text. I didn't think anyone did that" Again, there may be a business case for doing so. If my HN password is compromised, the consequences are relatively trivial. Therefore if HN spent a lot of time dealing with lost passwords, it might make economic sense to store them in plaintext. If my Lloyds of London password is compromised, there are relatively significant consequences. Therefore, it should not be stored in plaintext. In other words, ask your client about their needs and their operation and determine the appropriate way to store the password based on those things not your preconceptions.