I am about to set up a new account on my Linux server for a user that lives in another state in the U.S.

I can't think of a good way to get them this user their password. There must be a standard mechanism for this, right?

  • 1
    can you please explain what you mean by 'bootstrap a password with somebody'? SSH keys should really resolve the need to exchange any password or secret information, so why insist on passwords? (of course you have to verify that the public key is valid/not-tampered, but depends on your situation, that's usually easier)
    – Yoav Aner
    Commented Mar 27, 2012 at 8:06
  • 1
    @Legolas I don't see the update reflected in your question, but in some situations it might be much easier to protect the integrity of a public key than a confidentiality of a password. For example, the user can post their public key on their own website, facebook, their stackoverflow profile, or any other trustworthy channel. You can also check the fingerprint of the key via other channels (email / phone / sms).
    – Yoav Aner
    Commented Mar 27, 2012 at 19:27
  • 1
    @Legolas I suggested other publicly available sites, which should be safe enough for users to post a message untampered (there are many). Since the confidentiality of the message is not the issue, all you need to worry about is whether or not someone can change it. If for example, I post my public key on my stackoverflow profile - I think it's reasonably safe to assume it's not going to be easy to change it. If on top of that I email / sms / telephone and confirm the fingerprint you then have pretty robust security without the need to exchange any passwords.
    – Yoav Aner
    Commented Mar 28, 2012 at 7:57
  • 1
    Not if you already know the person, so e.g. know their facebook account, email address, stackoverflow username, skype account etc. I do believe that knowing the person by some means is implied. If the question is about giving access to a total stranger you never met (not sure why anyone would want that?), then this should be clarified. anyway, this is getting too long for comments so I'll stop here.
    – Yoav Aner
    Commented Mar 28, 2012 at 8:36
  • 2
    I think this question is flawed, you initially describe a leap of faith taken where you identify a person that you want to share a password with, you then ask us to identify a way for you to securely identify him or share a secret with him. To share you secret you should use the same method that you have authenticated him with in the first place.
    – Andy Smith
    Commented Mar 30, 2012 at 13:35

11 Answers 11


Key distribution is a subject on which quite a lot of papers have been written, and probably will. Basically, one needs some sort of secure channel to get the key send, but that secure channel is not there yet, which is why the key is needed in the first place.

The powerful attacker

For this answer, start with imagening a very powerful attacker, e.g. a Dolev-Yao attacker who can overhear, intercept, and synthesise any message on the network. Of course, this attackers has much more power than commonly reasonable, but it is also the starting point in common security research. We will lower the barier later on.

Given our very powerful attacker, we actually need some bootstrapped trust. For example, if you have some sort of e-mail encryption scheme in place, that could be used. Think PGP or S/MIME. This still leaves a trust problem, but in the first case can be delegated to a informed decission based on their web of trust or in the second case the decission of the certificate authority (probably only based on e-mailverification). In other words, the trust is contained in one of the existing structures, and we can base our decision on assumptions over what are normally considered trusted third parties.

If you intend on using public key cryptography, e.g. SSH keys. You turn the problem around. Now, you do not need confidentiality of the key, but your user needs to be able to maintain integrity when sending you the public key. In the e-mail encryption example, one would need to make sure the message with the public key to be used for the server is signed by your employee (instead of rightly encrypted for him and only him to read).

Thus, when confidentiality is your problem, encrypt using some bootstrapped trust, such as provided by e-mail encryption tools (or comparable), and when integrity is your cause, let your employee sign using bootstrapped trust.

The attacker who is powerful on only one channel

More realisticly, the attacker has power over only one or more insecure channels. In other words, you assume the existence of a secure channel on the side of your main channel. This channel can be used to send additional information that is required to understand the main message, or to verify the main message. For example, you encrypt the password with another password and e-mail it. On the side, you send a SMS with the password needed to decrypt the password. This way, two channels need to be compromised. Please note that this could be any combination (postal, phone, SMS, e-mail, fax, etc.) as long as they are disconnected enough for it to be sure. Thus, a smart phone which handles both the incomming SMS and e-mail is not good enough!

The two channel approach could be played similarly in the integrity situation, e.g. sending the public key over two separate channels. THis way, you need to verify these outcomes against each other.

Conclusive notes

There are numerous other methods, but I expect that this will generate a way too high burden against not too much extra security, as you are still dealing with humans.

Furthermore, things as to directly require a password change on first login would be smart additions.

Finally, you will notice that these are all questions of trust, which are fundamental to a lot of cryptographic systems and other methods of security. You should find the right balance between paranoia and being naive, e.g. the system of certificates used by SSL and S/MIME is most certainly not fantastic, but it is commonly found good enough for online banking, so when you are not communicating about nuclear missiles, it will probably do just fine. Just make sure you also do some reasonable auditting.


Talk to them in a two way conversation in as close to real time as conveniently possible (in person/phone/instant message/email conservation) and give them an initial password that has to be reset on first login.

This is typically done with the chage command on linux/unix:

sudo chage -d 0 the_new_user

Verify afterwards that they got the new account using an independent method (e.g., if you called them previously; send them an email), so in case you were social engineered somehow (e.g., their cell phone was stolen or email was intercepted) there was an independent check afterward. Also don't give them root or other elevated permissions until you've verified them.

EDIT: The initial password should be something random; e.g. 12 random characters generated by a computer.

EDIT2: Mitigating against eavesdroppers is simple if the people at both ends can be trusted. If you can confidently identify the person on the other end of a phone/videoconference/etc give them a one time initial password (that they then have to reset), verify that they are in, and then elevate privileges. If its a web app, this initial password could be an token in an emailed link (that works once; auto-expires after short period). If its a work account, maybe only let the webapp send password emails from/to your local domain (which you've configured to use SSL). Even if an eavesdropper intercepted, they would have to beat the person to initially using it (and then the legitimate user would have issues which would kick the eavesdropper off).

The thorny issue is one of establishing trust that a remote third party should have access to the account. This starts with verifying the reason you giving this user this account? Are they a well-known co-worker/acquaintance who needs access to something new? Or did your boss say give you an email saying give [email protected] access to server X? Could you be social engineered (someone pretending to be boss over phone/stolen bosses email)? This is not a straightforward task; however checking the instructions in person, or via video conference, or phone mitigates risks of the command being socially engineered. Granted your boss may be social engineered -- maybe the new person should not be trusted.

  • Seems like if the verification step is necessary, it has to happen before you've let them in. Otherwise, it's already too late. Real-time does sound like part of the solution though.
    – mlissner
    Commented Mar 27, 2012 at 6:20
  • @mlissner, if its a trusted well-known acquaintance, sure just get them on the phone, small-talk, and give them a initial password that must be changed on first-login. If there's a new collaborator who could be easily impersonated; I will try re-verifying after the fact somehow (defense-in-depth) before giving them a non-limited account. Yes privilege escalation attacks exist, but it adds another layer of defense. Obviously, it depends on the account (e.g., if the server houses confidential stuff then there isn't a limited acct; so more initial verification must happen).
    – dr jimbob
    Commented Mar 27, 2012 at 14:33
  • Thanks for the added details and the direct explanation. I think you and @legolas basically had the same answer, but I'm a person that likes lots of details, so I gave him the bounty and you the upvote. Good stuff though.
    – mlissner
    Commented Apr 2, 2012 at 20:47
  • @mlissner - No worries; gave him a +1 myself. I don't think its is what's typically done unless its very high security (and then I'd only do it in person). One-time passwords/links are fine to leave in email (and if your email is sent from and to your work's email server internal to the VPN/intranet and uses SSL for authentication; the threat of eavesdroppers/spoofed users is mitigated). Most people/workplaces do not have PGP trust chain in place; but most systems have capabilities to easily setup one-time initial passwords. And if you trust a stolen key with pgp the trust chain is broken.
    – dr jimbob
    Commented Apr 2, 2012 at 21:25

This may or may not be helpful, but you could also consider allowing them to authenticate only via SSH keys:


You've still got to verify that the public key you're accepting comes from the user you think it is (ie, that you're not being social-engineered, as pointed out above), but it's more secure to email around a public key than it is a password. (I say this because public keys are intended to be distributed, while passwords are not. There's less harm in leaving a public key sitting on a mail server/mail client "forever" than a password.)

  • +1 good point about public keys being fine sitting in mail server/mail client. I don't see a problem with a randomly generated immediately expiring password sitting in a mail server. (I feel the need to add don't re-use the same initial password).
    – dr jimbob
    Commented Mar 24, 2012 at 16:00
  • SSH keys are useful, but I think the real question I'm getting at is the bootstrapping one.
    – mlissner
    Commented Mar 27, 2012 at 6:21
  • +1. I tried to give some examples on the comments above how to use (at least one) third party sites that the user can post their public key to. I think this is in practice far easier and more secure than bootstrapping a secret key/password exchange (although in theory both problems are very similar).
    – Yoav Aner
    Commented Mar 28, 2012 at 8:43

To keep it practial make arrangements through regular mail or messenger. Then send a text message from your mobile phone (SMS) just containing the password. Ask the receiver to confirm through mail or messenger. As dr jimbob states, and if possible, expire the password so it needs to be changed with first login.

  • Regular mail seems slow and unnecessary. Surely we can do better, right?
    – mlissner
    Commented Mar 27, 2012 at 6:27

Here are some quick and easy solutions I haven't seen mentioned yet:




You are asking for the "official correct way" to do this and the well-established methods are to either use public key cryptography or a trusted third party (like with Kerberos) for both ends to trust each other. Both of these have real-world equivalents such as some form of escrow or a notary public, but whether technical or non-technical, the implementation often isn't practical.

The only other alternative is to establish a pre-shared secret beforehand that both ends can use to authenticate each other. It's kind of like how one spy will present a phrase and the other spy must properly complete it so that both sides know that the other side is authentic. On the technical end, this is usually accomplished by using a key derivation function with a pre-shared initialization vector. Of course this method requires the ability to securely pre-share a secret.

There certainly are less-than-ideal methods that would still work quite well for most situations. For example, using one of the services such as pwpush.com listed above can allow you to encrypt and limit exposure of the secret. Sending the link to an email address will authenticate the user. You are basically doing the same as the first situation but you are using the email provider as a trusting authority to authenticate the user. Of course, email isn't a very secure method but it is just an example. There are a number of channels that provide some measure of authentication (such as being in physical possession of a mobile phone you call).

No matter what method you use, it would always need to involve either a trusted third party or a pre-shared piece of information.


There is a better solution. Don't distribute passwords. Instead, distribute SSH public keys. Ask the other person to send you their SSH public key. Then, add their SSH public key to a ~/.ssh/authorized_keys file in the home directory of their new account. This will allow them to log into the account.

You can reasonably have them email you the SSH public key. The public key is not secret, so you don't have to worry about people stealing it. (You do need to make sure you are getting the proper SSH public key from the right person, but in ordinary practice, it's often enough to contact the person and ask them to email you their SSH public key. If you are paranoid or have a high-security installation, you can call them up and ask them to read off the hash of their public key.)

In addition to simplifying the communication problem, this also has the benefit of avoiding passwords, which have known problems: they tend to be susceptible to eavesdropping, social engineering, and dictionary attack.

  • Agree that SSH is better. @chrisallenlane also suggested this, and my response was that I'm more interested in the authentication issues of key distribution.
    – mlissner
    Commented Apr 3, 2012 at 18:09
  • @mlissner, I'm confused. Your question refers to passwords, but now you say you are interested in distributing keys. Can you clarify? What is it you are interested in distributing? Passwords? Keys? If keys, what kind of keys? Private keys? Public keys? These details matter, so I encourage you to edit the question to clarify.
    – D.W.
    Commented Apr 3, 2012 at 18:17
  • I mean keys in the general sense, and include passwords as a variety of key. Sorry to be unclear. My question really is: "What is the best practice for getting a new user into a system," which I hope I've asked above. If you look at @legolas's answer, you can see it's basically about key distribution.
    – mlissner
    Commented Apr 4, 2012 at 17:24
  • @mlissner, I guess what I am hinting at is that I feel you have over-generalized. The considerations for distributing passwords are different from the considerations for distributing public keys, which are in turn different from the considerations for distributing private keys. The answer will differ depending upon which you are really asking about. I recommend that you pick one, and edit your question to ask about that one; or ask three separate questions.
    – D.W.
    Commented Apr 4, 2012 at 17:38

I am going to be naive here.

Lets suppose that you don't want to use any Diffie-Hellman key exchange based protocol i suggest you this very empirical technique:

create the account and set the password to randomShortString

call the user:

ADMIN: Hello user A, this is your password: randomShortString please login right now and then type "passwd" and set a new different password.

USER A: Hello admin, thank you i am logged in....and yes, now i've change my password.

ADMIN: su user A, password...login fail. "Ok thank you user A"

I would say that if it is only for one user this will work...

  • +1, but using a very short string for initial passwords is a bad idea if there could be any significant time period between setting the initial passwords and when its used/reset by the user. Also sudo chage -d 0 the_new_user (or sudo passwd --expire other_user) or just doing it manually in /etc/passwd file. E.g., if you set it; call the person up; get voicemail and decide to call back later; you don't want a weak password out there.
    – dr jimbob
    Commented Apr 3, 2012 at 21:20

If you only know the person as a voice on a phone in another state, no amount of secondary verification will provide you with any additional guarantee of that identity. Phoning them provides an out-of-band circuit, authenticating via voice and giving them a temporary password is industry norm.

If you push this question far enough, you get into a very abstract concept of "Identity". What is a name? Why does it have meaning? What value is it that the government has a record linking that name to that face? Why does that matter for your interaction? Do you trust the government-issued-ID, or do you really trust the person you met at that convention, regardless of what they tell you their name is?


If this person is decently tech savvy, GPG (PGP) is an ideal and easy way to accomplish this:

  1. Your long-distance user would create a key of their own
  2. They would send you a copy of their public key
  3. You then encrypt a plaintext file with the password in it, using that public key
  4. Afterward, you can email it, dropbox it, or even post it on a public site--the data is perfectly safe, assuming that they have kept the private key safe.


  • This is only security theatre if the long-distance user does not build up his web of trust to create a trustworthy enough connection with the local user, which generally requires some time. In other words, if the user is not already on PGP, this will not work.
    – Legolas
    Commented Mar 28, 2012 at 6:03
  • It will work as long as mlissner has some way of independently authenticating the public key-- eg, if the user were to generate a key, email it or post it somewhere, and then call mlissner with the serial of that key, it's a done deal. Web of trust is only a factor if you have absolutely no other means of authenticating.
    – Bryan Agee
    Commented Mar 28, 2012 at 17:33
  • That approach is no more secure than using a temporary symmetric key that is told by a separate channel, e.g. phone.
    – Legolas
    Commented Mar 28, 2012 at 18:02
  • It absolutely is--a symmetric key passed by a separate channel can be used to decrypt the data if intercepted. An authenticated public key only allows the encryption; the worst that can happen is that someone else can send encrypted data to the owner of that key--the encrypted data is only usable with the private key.
    – Bryan Agee
    Commented Mar 28, 2012 at 18:05
  • No, if the public key is send over an untrusted channel it may be altered, thereby causing the password to be encrypted wrongly and interceptable. Edit: the only positive factor of public key encryption here is that it is easier to note that it has been intercepted, as the original receiver is unable to decrypt it.
    – Legolas
    Commented Mar 28, 2012 at 18:50

PKI-infrastructure (corporate or 3-rd party), personal S/MIME certs, exchange by public keys (e-mail, snail-mail), verification of author by key-fingerprints (voice), S/MIME encrypted mail for final data-transfer.

Unbreakable (in measurable time, now) way


I hate to say it but if you cant give it to them over the phone just stick with an old school fax machine. Verify that they are waiting for the transmission and send it, then confirm that they got it directly.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .