Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
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.
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.
openssl aes-256-cbc -out FILE, email the encrypted file to them, and then send the decryption password via SMS.
May 22, 2014 at 20:11
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.
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.
For SSH keys, I have them generate the key and send me the public key, then we can simply compare fingerprints over the phone.
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.
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.
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.
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.
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.
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:
There are a number of services which allow you to enter either plan text or HTML into a browser and generate a one time link to share via the relevant channel.
The basis is that you do not send sensitive data anywhere it's stored or processed as plain text!
These services are good because the link is a one time use, the data in transit and at rest is encrypted and without the right link it's garbage. They can also have the link sent via normal channels and can be accessed by anyone so makes for a much easier end user process.
Some examples are:
Full disclosure, Burn After Reading this is one of our products.
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.
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).
First, I hope that you've got your credentials set up so the user MUST change them during the first login, so those setting them up cannot know them anymore.
If a remote office has a trusted admin, send that admin an encrypted set of one time use keys/passwords to share with other users, so you can just ask them to use Password #12 for their initial login.
Depending on your threat model (are you worried about nation-state level actors, i.e. are you working with a foreign office in Country 4, which may engage in commercial espionage on behalf of their local competitors of yours), this is actually a classic case where calling someone on a landline is a great solution.
Just calling someone on a landline and telling them the initial login credentials over the phone works very well.
Beyond that, GPG is always a classic way of doing this, as many people answered. I have examples of both public key usage as well as more secure than default symmetric usage in this answer on Superuser.com.
Depending on your regulatory requirements, OTR is a method of encrypting communications, particularly IM's (see Pidgin as an example) that also allows for "shared secret" authentication; you could share an easy to type password on the phone while on IM's to validate the IM session doesn't have a Man in the Middle, or use some aspect of the work they're doing that would be hard for someone else to have ahold of.
If you already have a way to send email that you trust only your recipient and your own network/email admins can access, and you can trust certain other products/companies, then you could use a "secure email" service like Cisco Registered Envelope Service or an alternate.
Particularly for SSH keys or extremely long and difficult passwords, you can do a combination of these; you can encrypt - perhaps using GPG symmetric mode (see link above) - using a secure password, and then deliver that password via the phone or other method, so they can decrypt the actual authentication token/SSH key/certificate/etc.
All depends on the threat model and the working scenario.
First, please note that in 2021 most emails, and at least all emails through major business providers are transport-encrypted, and plaintext SMTP is deprecated in any decent business environment. Eavesdropping is not part of the threat model.
Impersonation? I assume, because it's not disclosed in the question, that the user(s) are member of the same organization or another trusted organization. Make sure you send emails to the correct domain, do never just hit reply for credential requests coming from someone who claims to be your collaborator. Double-check the destination address in your email client before sending, type in the email address if necessary.
Credential abuse? If you believe that someone will continue to use the passwords after the job is done, you should have plans to change them before and after work. I understand that production passwords are often related to applications. When possible, set up dedicated accounts with same permission levels. This is also good for auditing
Credentials stolen after mailbox leaks (in the future). A regular password rotation policy is good at mitigating this.
For SSH, as noted by @SimonRichter, the flow is opposite. You have them send you the public key, but yet again you must validate the sender address. Either make sure the (business) domains enforce DKIM/DMARC, or call the party over the phone to a trusted number to verify the signature.
When possible, I'd always recommend to switch to SSO and federated login. If this is supported by the underlying applications (e.g. MS SQL Server, Azure SQL), you won't be giving the password to anybody, but granting access to a directory user (e.g. (Azure) Active Directory)
