How to Deliver New Account Login Information

Question

I have a customer whose site does not allow end users to register. How do I go about delivering the new user their login/sign in information without sending it in plain text? I don't want to end up on http://plaintextoffenders.com/.

Here is what I'm dealing with:

1. Site admins must create accounts, not end users, so there is no "registration" page.
2. These admins do not want to manually call the people and tell them their password.
3. This site does not require phone numbers so sending a text message is out of the question.
4. The automated e-mail about their new account cannot be encrypted.

I could easily code a one-time password or send some long unique key as part of a URL that will take them to a screen where they can create their password, but I don't see how that solves anything because if someone is watching the e-mail traffic they could easily get all that info, just the same as if the password was in the e-mail. So is there just no way around this? I'm thinking a one-time password that expires after a set time is the best option. Is there any other option I'm missing? Thanks!

UPDATE: @Chris had the idea of traditional mail. My site won't allow that but it is an "outside-the-box" idea I think is worth mentioning here in case it could help others. I found services like this one https://www.trypaper.com/, it's really cool, they have an API so you could make your site automatically fire off a real snail mail letter containing their login info at the time you create their account. Kind of archaic, but it's an option.

Answer 1

That's not easy.

What you can do is either let the people collect their passwords from a central location (I don't know if they are all on the same location?). Another alternative would be to do it per traditional mail. Or maybe there is another trusted third-party where the user can collect its initial password?

However personally I would go with the URL and Token with timeout solution. You are right, that this information is transfered in cleartext. However if an attacker uses this information, you know that this happened, as the legitimate user is not able to set his/her password, resulting in a help desk call. If you transfer a password in plain text, you don't have this advantage (at least if you don't do it with a one-time password).