Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

As someone who usually works with people in other countries it has always been a problem to send login information to each-other.

For development login details like debug databases etc sure I can send them over in clear text email or something but when it comes to actual production information such as SSH keys how do you securely send them to someone when face to face contact isn't possible.

share|improve this question
Have you thought about using GPG? –  executifs May 22 '14 at 12:15
Use ietf.org/rfc/rfc1149.txt –  WernerCD May 22 '14 at 17:18
@WernerCD That is not a bad idea. South Africa: Carrier Pigeon Faster Than Broadband Internet –  Chloe May 23 '14 at 4:41
You can tell them to keep guessing random words, and when they hit the nail, stop them... –  Awal Garg May 23 '14 at 5:19
Obama snooped my president's mail.. are you sure you're safe? –  Magno C May 23 '14 at 14:56

11 Answers 11

I usually use SMS. While not perfectly secure, this is more secure than email and generally adequate. It has the major benefit of not requiring any setup, such as exchanging PGP keys.

You could make this more secure by sending half of the password by email and half by SMS. Alternatively (as suggested by Michael Kropat) send a file with the symmetrically encrypted password by email, and SMS the decryption password.

For SSH keys, you should only transfer the public key. If you're granting a user access to a server, they should send you their public key, rather than you send them a private key. You still need to confirm the received key is authentic, but you don't need to keep it confidential.

share|improve this answer
+1 for this. I also use sms for "secure" password transmission, while sending other information by other channels - email or IRC. Someone intercepting the message alone would not have enough information to find out what it is a password for. This is only valid security if the password is a one-time use pass, and the user is forced to change it on login, though. –  Riot May 22 '14 at 14:26
I wouldn't just split the password. Encrypt the password text with something simple like openssl aes-256-cbc -out FILE, email the encrypted file to them, and then send the decryption password via SMS. –  Michael Kropat May 22 '14 at 20:11
@MichaelKropat Nice idea; I have edited the answer to include this. As with everything there is a trade-off between security and convenience. –  paj28 May 22 '14 at 20:19
SMS is even better when you use something like TextSecure. –  Greg Hewgill May 23 '14 at 1:17
@GregHewgill - better... maybe, if TextSecure is actually as secure as its website claims, but this comes at the cost of requiring the recipient to have that app installed. –  paj28 May 23 '14 at 11:27

As has been said already in the comment, this is a classical use case for GPG/PGP. Everybody creates a key, you exchange them in an arbitrary way, and then you verify the fingerprints over the phone, a video chat or any other channel with reasonable protection against data tampering.

You can also sign each others' keys to create a small web of trust. For example, if you've already verified and signed the keys of developer A and developer B, then A and B can trust each other without having to verify the keys again.

share|improve this answer
Not to easy to use since some of the people I work with use services such as hotmail which don't have buildin GPG/PGP feature and you have to use a mail client to do it. Also some of the people I work with aren't that tech savy to know how to use GPG/PGP(Tho it is a good solution for developers). –  user36976 May 22 '14 at 12:43
Use the term "asimmetric key" instead of GPG/PGP. An SSH p2p connection or cripted chat or similar would do the job –  lesto May 22 '14 at 16:20
It's not just any form of asymmetric encryption. As stated above, one of the features of GPG is that users can sign keys and build a web of trust. This surely helps in team situations. The leading developer could verify and sign all keys once, and then everybody can communicate with everybody without having to personally verify the keys first. This isn't true for all protocols. –  Fleche May 22 '14 at 17:49
@Nick It isn't necessary to have GPG/PGP built-in to your mail client. You can do the encryption and decryption using a stand-alone tool, then just send the ASCII-armored text through mail. –  Istvan Chung May 25 '14 at 23:33
I've trained clients to use PGP/GPG; any one competent (enough to be trusted with a password, to anything) picks it up fairly easily. But the bit that trips most people up is they forget their passphrase. I then have to explain there is no way to get it back and they have to start over again. –  Darren Cook May 27 '14 at 8:39

When I need to send something a single time, I have used One Time Secret. It's an open-source web app that allows you to enter information that can only be viewed once. After the recipient has opened the page, the information is deleted, and the only thing remaining in your chat logs or email is a bad link.

It's not as robust as your entire team using PGP, but it's much easier to set up or explain. I've been able to use it to send login information to fairly non-technical people, and they find it easy to use.

share|improve this answer
This is an excellent solution if you don't mind someone else getting the password instead. –  Istvan Chung May 22 '14 at 17:42
@IstvanChung You could in theory not activate a key/password before the other end reports that they succesfully read/saved the key/password that was behind the link. –  Sumurai8 May 22 '14 at 17:48
@IstvanChung Nobody will guess a link like onetimesecret.com/secret/oar70yed5i53vhwzaf8la64x1e1j3ye and even if the recipient doesn't get access on their first attempt at viewing it, then you know it's been compromised and you can reset the password and try again. It also lets you password protect the info. –  Keavon May 23 '14 at 2:28
@Keavon re: "Nobody will guess a link like ..." I'm not willing to trust to the security of this- among other things, this means I have to trust the admin of the server. re: "It also lets you password protect the info." Well, if I have a secure means of transmitting the password with which I'm protecting the info, then what's the point of this in the first place? –  Istvan Chung May 23 '14 at 4:03
@IstvanChung you can also host an instance of this service yourself since they have published the source. –  JE42 May 25 '14 at 8:00

For SSH keys, I have them generate the key and send me the public key, then we can simply compare fingerprints over the phone.

share|improve this answer

You can use the slow method of mailing them (postal) the keys on a USB key but that in today's age is not practical. What I do in situations like this is, I have a dedicated NOC operations web server I use to store the keys in a directory I will create for whomever I need to send keys to. I lock down the webserver with mod_security and .htaccess rules to ONLY allow the individual I want seeing that directory (via IP).

My structure is something similar to the following. Suppose I need to create a key for say a dev group in China, I will make a directory based on the checksum of their name/group, etc:

[myoto@mymachine ~]# mkdir `md5 -s devchina | awk '{print $4}'` 
[myoto@mymachine ~]# cd `md5 -s devchina | awk '{print $4}'`
[myoto@mymachine ~/4b4dda9422c2de29f9a0364f1bd8494d]# cp /path/to/ssh_keys/what_I_want_2_copy .

This ensures no one can stumble upon a directory using something like Nikto/Wikto, etc. the .htaccess and mod_security rules enable me to control who gets to that directory, and I can clean it up after I see via logs, the keys have been copied.

share|improve this answer
Particularly if it's only for temporary use, why use a hash? Just make a GUID (mkdir -v $(uuidgen)), or take the number of nanoseconds since the second at this arbitrary point in time (mkdir -v $(date +%N)). Both will be pretty hard to just "stumble upon" in the short amount of time it exists if you clean it up afterwards. –  Michael Kjörling May 24 '14 at 19:34

You probably don't need to be sending ssh secret keys around.

The remote individual should generate a key pair on their end, keep the secret key, and send you the public key.

The public key isn't a secret, so it's not a problem to send it in the clear. Only the private key is secret, and that doesn't need to be transmitted because they already have it.

Then you just add their public key to the authorized keys list.

The only problem you might have is determining that the public key you received really is from the person you want to give access to.

If you have other secret information that you do need to share, well, now you both have secure access to shared server so you can use that.

share|improve this answer

If you both set up an account with LastPass, this service allows for you to share your passwords (and other secure information) with other parties.

share|improve this answer

If they each can setup an account with a secure file sharing site, you can share files to each of them. If you want to do it yourself, you can setup something like OwnCloud with encryption enabled and use that as a means of secure file exchange with multiple people as long as you use SSL for the OwnCloud instance and can make one secure credential distribution out of band.

share|improve this answer

The main problem about this is that we are sending passwords normally to simple users, who have problems to open a gpg-signed mail.

What the problem real worsened by that our job/wage/project depends on their judgement, how happy they are to co-working with us. Also our first priority is to make this password-thing as simple as possible for them. I am sorry to say that, but in the reality it is more important as to reduce the chance of a breakin from 0.1% to 0.01% in the next month.

Normally I do the following:

  • I send everything (username, additional login infos) in a simple, unencrypted mail, except the actual password,
  • I refer the actual password as "I sent this in SMS to you"
  • And I send an SMS concurrently with the mail, only with the simple password, without any comment.
share|improve this answer

With PGP/GPG (and most other suggested answers) you have to solve the authentication problem to prevent man in the middle attacks. SMS should not be considered save, since GSM encryption has long been hacked.

I would use OTR (can't post more links, just google).

With some chat client, such as pidgin. You can then even use some unsecure channel, such as Facebook, Google chat, ICQ, what ever, establish an encrypted connection, authenticate via the build in SMP, and then exchange confidential information.

share|improve this answer
How do you establish the OTR keys as trusted? –  Michael Kjörling May 23 '14 at 13:27
@Michael: As written above and explained in detail in the linked specifications, OTR supports SMP (Socialist Millionaires' Protocol) for authentication which is man-in-the-middle safe. (Assuming that you and your communication partner know each other well enough to have accidentally created a 'shared secret' i.e. any mutually known but private fact.) See e.g. en.wikipedia.org/wiki/Socialist_millionaire –  Echsecutor May 26 '14 at 13:32

I would use some kind of secure online portal that your remote users can access/download the sensitive information from. To give them access to the portal, I recommend two-factor authentication with a temporary (secure) password that must be changed upon using it once (but the two-factor auth ensures that even if the email with the temp pass is compromised, there is still an sms pin).

share|improve this answer

protected by Rory Alsop May 23 '14 at 12:11

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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