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?

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)

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

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.

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.

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.

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.

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

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.

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?)

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.

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.

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.