Best practice for password distribution

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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

https://help.ubuntu.com/community/SSH/OpenSSH/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.)

Answer 4

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.

Answer 5

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

https://pwpush.com/

https://onetimesecret.com/

Edit:

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.

Answer 6

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.

Answer 7

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

Answer 8

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?

Answer 9

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.

http://www.dewinter.com/gnupg_howto/english/GPGMiniHowto.html

Answer 10

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

Answer 11

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.