Bulk load of accounts to website - email users the password - security issues

Question

I have a new web project where the user can login to the site. My client (the site's owners) has a database of existing customers that they want to load into the new site.

So, I was thinking, I will import the existing customers into the site's database, assign a random password, which is good for 1 login and must then be changed, and email the login details to the users (with password in plain text).

So, given that email is not secure, I must assume it was read in transit. So, lets say I sent an email Alice who I intent to have access to my site. Lets say :

A - Before Alice reads the email, Nasty Nick reads it and logs into the site, and is forced to change the password. Alice then tries to login but the password does not work.

B - Alice reads the email, logs in and sets a new password. Nasty Nick then reads the email, tries to use the password but it fails.

In case A, the rightful owner is locked out and will (presumably) contact my client and we can take action. If she does not make contact, Nick will continue to have access - but the account has no info in it or any value until the account holder enters data.

In case B, no harm apart from Nick knowing that a specific username exists on the system.

Am I missing anything in my risk assessment there? Obviously I would prefer that the people sign themselves up, but my customer wants to leverage an existing database. And it is too expensive to sent the login details by post.

Any other ways to do a bulk import?

EDIT

If, instead of sending the password, I send a link/token that logs the user in and then they must set a password, similar to what is suggested here for a forgot password system - is this better?

Answer 1

In case A, the rightful owner is locked out and will (presumably) contact my client

Well, unless the rightful owner wasn't expecting to be signed up to an online account, and so:

• doesn't check their mailbox, or
• disregards or discards the mail as probable spam, or
• doesn't get the mail because the address was wrong or outdated

Typically to mitigate this you would:

• time-limit the random password/token so that if Nick gets access to the e-mail account a few months down the line, he can't get into the account without generating more e-mail noise;
• ideally, only send the mail with the token when explicitly asked to

B - Alice reads the email, logs in and sets a new password.

There's also the corner case where Alice reads the e-mail, logs in, gets distracted or isn't interested, and so doesn't set a new password. You should try to make sure the initial ‘one-use’ password isn't re-usable at this point.

If, instead of sending the password, I send a link/token that logs the user in and then they must set a password, similar to what is suggested here for a forgot password system - is this better?

It's not functionally different, assuming both are correctly implemented with the same constraints. But if you can re-use some of the same code for forgotten-password vs verify-email-address-at-signup then you've got less code to review and thus more chance of making it secure (and possibly the UX is more consistent).

It may be a good idea to go all the way and use only the forgotten password system: don't set an initial password and send only an informational e-mail at first, instructing/linking customers to use the forgotten-password feature to get access.