I have a problem I need to solve - specifically, how to hand out passwords to people in a variety of locations, and with a wide variety of access.

I've thought of some options, but there are drawbacks to all:

  • Email: insecure and travels in the clear, unless it is kept internal to the company. However, some mail is forwarded outside the company, and some user access from the Internet is no doubt done with unencrypted access. In any case, not all have email access (e.g., contractors).
  • "Briefcase": I could add the password to the user's Zimbra briefcase, but this suffers from most of the same problems as email.
  • Telephone: Problem with using the phone is that VoIP can be tapped and is, I believe, generally unencrypted (though I don't know). It is also possible that the recipient is using VoIP and whether it is encrypted or not is unknown - in fact, the very nature of the receiving phone is unknown. In any case, some user's are in a time zone 12 hours off from ours - so this is out for the most part.
  • Encrypted Email: I hesitate with this one as it includes user education, but it may be the best way. Also, it means handing out keys somehow. There is also the email client support issue: users mostly use Outlook, but there are users using Gmail, Hotmail, Evolution, iPhone Mail, Apple Mail, and the Zimbra web interface, among others.
  • Web Portal: With this, users could access a web page inside the company or over an encrypted link and get a password (or perhaps, request one as well). I'd have to set this up (not a problem: I'm a programmer and administrator in one...) but it still requires handing out a password for the VPN or to log in the first time.

Here are the problems that have to be overcome, in a nutshell:

  • User education
  • Unencrypted traffic
  • User access
  • User timezone differences
  • User location differences

My inclination is that I'll probably wind up with some form of encrypted email and/or web portal; for now I'm using a mobile phone.

EDIT: The big problem here (as in all encryption methods) is in getting the initial password or key to the source. In particular, there needs to be a way to identify the originator and to prevent disclosure of the key. The problems we face in preventing disclosure are the following:

  • User workstations are not all on central network
  • Some users are isolated (work at home, etc.)
  • Some users are international: 12-hour time difference
  • Many users are not even employees, but contractors with sister companies or with outside vendors

I wonder if I'm just going to have to accept some risk.

  • 2
    What's the password for? If it's for a website, we do it by simply offering a password retrieval function. When an admin sets up the user, we already have the full name and email address. We let the system provide a password that even we don't know, and let the user get the password from the password retrieval function. Is something like that an option? A good website will have a password retreival function that uses a one-time, limited time temporary password and a link to login/change password immediately. Jan 26 '12 at 19:58
  • Passwords would be for a variety of things: VPN, email, ticketing system, internal servers, etc.
    – Mei
    Jan 26 '12 at 22:58
  • @DavidStratton I'm not sure I understand completely. We have external web sites that require a user name and password; how do you let the system generate a password if you don't know who the user is - and if you send the password via email, how do you keep network sniffers from picking up the password plaintext?
    – Mei
    Jan 27 '12 at 16:44

I would think that your only real way around this road block is with a pre-issued two-factor token, and an email with a one time password that has to be reset to the user's new password upon first login.

The one time password would be of no value without the two-factor token.

  • Could you expand on this? I've used OPIE under Linux before: the possibility of using a time-sensitive password is intriguing... However, note that many of these people I will never see face-to-face.
    – Mei
    Jan 26 '12 at 20:34
  • I'm assuming you're using some type of LDAP derivative. There's quite a few 2factor options out there, and it would be even easier for you in this day and age with mobile phones hosting the two-factor token. I'm actually really happy with just using google two-factor auth across my domain. But there's always RSA, wikiD, etc. Another option is a token via [SMS as well ](esecurityplanet.com/network-security/…)
    – neil
    Jan 26 '12 at 20:51
  • wikiD is interesting. Part of the problem is that some of the time users are on the internal network and some of the time the users are not yet on the internal network. LDAP is coming but is not yet set up.
    – Mei
    Jan 26 '12 at 22:57
  • one thought might be if your company has an employee id number, or something unique to each employee and salt their one time password against that. give them a simple script requires them to enter their employee id number.
    – neil
    Jan 27 '12 at 0:18
  • Our company's not big enough for an employee number (sigh). Many "employees" are in actuality working for other corporations, too.
    – Mei
    Jan 27 '12 at 14:49

Have a sub-administrator at each office location, and set up administrative procedures and a proper toolchain with these local admins.

It's the only really scalable and flexible way. The on-site admins can verify the users identity in person, and educate users on practical matters like password policies. And the local admin will gain familiarity with the tools you're using, so with a bit of training they can often use the platform tools (i.e. Active Directory, LDAP) directly.

A local admin like this doesn't need to be a technician. A centrally placed secretary, office manager or other administrative profile with good people skills and a methodical approach to things is often a great fit.

  • Some of the people work at home and alone, so this won't work either. Also, the "network" doesn't necessarily extend to all of our employees, either: most offices are independent of each other. Otherwise, this is a good idea.
    – Mei
    Jan 27 '12 at 14:46

Maybe another solution would be to provide the credentials via an established secure channel, e.g. send a secure mail to the boss of the employee. This of course means that the password has to be changed immediately upon reception. For contractors, they would have to check in to a local associate.


The system needs to allow them to set up their basic profile information themselves.

The only other secure method is either a pre-configured two factor authentication (2fa), or by hard-copy print (my bank will only send my pin number by post and separate to any other linked data). There is a reason for this.

I'm concerned by @DavidStratton's comment about a password retrieval system. That sounds worryingly as if you have stored passwords in plaintext and built an automated password delivery system.


Using email to deliver passwords is only an effective solution if you're not sending out the password used to access the email account.

Anything other than having the email written down (i.e. telephone in your examples) and you've got all the fun of explaining which letters are capitals, what's a punctuation mark etc.

SMS or a bit of paper or the only practical solutions if you really want tight security. But if you've created the account and know the users email address then it's possible that you will also be able to capture a secondary authentication token (which can be used for account activation rather than having to present it every time for access).

Certainly any password you issue by such means should be temporary - i.e. time limited and only allow access for the user to pick their own password.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.