

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

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.<p>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.<p>Now, seeing as my application <i>definately</i> 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).<p>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.<p>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.<p>Thoughts? 
Alternate ideas would be a once use password free click link in the email.
======
ColinWright
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
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
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

------
byoung2
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
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.

------
brudgers
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
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 k _nda_ *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
> _"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.

------
arghnoname
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.

------
JoachimSchipper
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
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
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.

------
soho33
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.

