I have heard from different people and in different places that if I send an encrypted file to someone else, I should send them the password in a separate email; but why? If someone is sniffing, they will capture both and if the inbox is compromised, they will capture both. But apparently, it's "best practice" to send it separately.

Now personally, I would send a password via other means, such as a phone call. What would you guys recommend?

  • 29
    One reason could be that if you send the email to the wrong address by accident, they won't have both the file and password at once.
    – BadSkillz
    Commented Jul 16, 2015 at 13:06
  • 4
    @JayMee - If both mails are sent, yes. But if you wait for confirmation that the other party has received the data, or see it right after you've hit 'send', your data would still be safe.
    – BadSkillz
    Commented Jul 16, 2015 at 14:02
  • 1
    @BadSkillz - ahh, I see what you mean now.
    – user81147
    Commented Jul 16, 2015 at 14:11
  • 5
    Perhaps you are already aware but the "proper" way to handle this kind of situation is to use PGP email encryption (i.e, public key crypto). With PGP, there will be no way to get the password even if all communications are intercepted.
    – tlng05
    Commented Jul 16, 2015 at 15:40
  • 22
    The trouble with email is that people tend to forward, use reply-all, or whatever, without realizing the full consequences of it. By keeping passwords in a separate email that contains nothing else, it is far less likely to be accidentally shared.
    – Brandon
    Commented Jul 16, 2015 at 15:50

12 Answers 12


There is added noise to the channel if you send them separately, assuming there is a delay in sending the second email the attacker would have to listen for a longer period of time and filter more content. It is simply a little bit safer than sending everything in the same package, think of ordering a safe box and shipping the keys along with it, its basically the same idea.

You are right in thinking that sending the password via a different channel (sms, phone, etc) is more secure, however it also requires more management and collection of more information, the logistics of doing it come with an added cost.

  • 19
    Also, it does not hurt if Agnes agrees with Bob to send the file and the password from (and/or to) different addresses. Commented Jul 16, 2015 at 20:32
  • 5
    I definitely prefer receiving two separate e-mails because this allows me to keep the first one for reference and throw the seconds one away after copying the password to my password manager. This way passwords won't linger in my mailbox and I will still have the other account info in the place where I expect to find it.
    – mgr326639
    Commented Dec 13, 2015 at 8:18

It certainly doesn't hurt your security to send two separate emails, but I agree that it's not a silver bullet.

The better practice is to send the password "out of band", meaning that you send the file and the password by different communication channels; one on the internet, and one not. If you send the file by email, send the password by SMS, if the file is on a network share, write the password on paper and physically give it to them, etc.

To understand why people make these suggestions, we need to think about which threat model this practice is trying to protect us from. In this case, both the sender and the recipient have both pieces, so it's not protecting us from end-point compromise (like someone having access to your computer or email account), instead it is protecting us from a malicious mail-man while the data's in transit. The idea is to break the data into crypto-pieces and send each piece by a different channel so that no one mail-man has enough to reconstruct the data.

With this threat model, even sending two separate emails with the same To: and From: addresses does some good when you consider that 1) email is a plaintext protocol, and 2) any two packets will take two very different paths through the internet. This way, any 3rd-party router in the middle can see the contents of the message, but is only likely to see half the crypto-data. It certainly won't stop your ISP, or the NSA, (who log everything) from putting both bits back together, but they have to sift through a monumental amount of data to do it, which is expensive for them.

Clearly, sending both chunks with completely different To: and From: addresses, or delivering one piece by a non-internet method makes the reconstruction that much harder. You don't have to make reconstruction impossible, you just have to make it more effort than breaking into your computer so that it's no longer the weak-point in the chain.

  • 19
    "any two packets will take two very different paths through the internet" -- any two packets can take different paths, but unless one end is moving they probably won't. Commented Jul 16, 2015 at 22:34
  • 2
    Mike's also forgetting that each single email in isolation probably already is made up of multiple packets. That's the starting point, not the mitigation. Commented Jul 16, 2015 at 23:59
  • 1
    @MikeOunsworth It protects against future compromise if you delete the email before the compromise. It's not a panacea, but at least it has some use. Commented Jul 17, 2015 at 19:04
  • 2
    @Gilles How is that different from putting them in the same email and then deleting that? Commented Jul 17, 2015 at 19:06
  • 1
    @Gilles Keeping the data but deleting the key kinda makes the data useless, but I concede that you can construct a situation in which this suggestion (in conjunction with deletion policies) can protect you from end-point compromise. Fine. Commented Jul 17, 2015 at 19:18

In my experience, most people who recommend this have previously worked in similar situations with snail mail, such as sending out the ATM card and the PIN separately.

It makes sense with snail mail, as in most cases it's not usually practical for a compromised node to intercept all traffic, and correlate cards to PINs. Or if it is practical, it's generally a node close to either the source or destination (your postal worker, or someone in the bank's mail room), who would be easily identified.

However, with email, it's relatively easy to intercept all traffic and correlate messages, so this advice has little value.


What you are proposing is certainly better than putting a userid and a password in the same email, but it is still not a great solution. Consider some other options:

  • Services like LastPass offer secure messaging.
  • You can transmit passwords using text message or other non-email methods.
  • Services like privnote.com allow you to send a one-time link, which the other person can access and retrieve credentials. This way the credentials won't live forever on an email server somewhere.

I understand this as security by obscurity, which doesn't really "work" and is certainly not considered best practice. The information will be in two separate places however, making it harder for an attacker to collate the information.

I would avoid sending the password in a separate E-mail. Especially not in plain-text. Use another communication method to send the password after you've sent the encrypted file.


Caveat: Yes, its always much better to use asymmetric encryption for this purpose of exchanging secrets like this or to communicate the password over a separate channel.

By separating or compartmentalizing information, the task of peicing togethr all of that information is made much more difficult.

Consider an email which is something like:

Username: JohnSmith

Password: sdfs##ds

It's relatively easy for an automated process to go through this an identify a set of information which belongs together. Now instead, if you have information spread across multiple emails a AI or real human needs to check information across multiple emails. This will be difficult and time consuming, unless an attack has tailored specifically for this set of emails and its in a common known format. Consider this case if someone has offline or direct access to the emails and can go through them one by one.

If someone is listening on the wire or doing active MitM, the likelihood of that access being available decreases over time. The quantity of information required to be analyzed also increases over time for a given eavesdropping session. Therefore, delays in time increase the cost of the attack.

I would not quite equate this to security by obscurity because you are not hiding anything in this case, you are just increasing the costs for the attacker (like purposefully pretending to fall for a 419 scam to waste their time, i.e., scambaiting).

  • "much more difficult" - do you have any justification for that claim? I think you're over-stating the amount of security it adds to send the information separately. No, an eavesdropper would not need an AI to match two emails that were sent from the same sender to the same recipient on the same day.
    – D.W.
    Commented Jul 16, 2015 at 20:14
  • @D.W. Identifying two emails from one person would not be difficult, but correlating the value between them would be. Yes, if you are targeting one individual you will manually read all of his/her emails. If you are using automated means on a large number of users it may not be; maybe those same two people exchanged 30 other emails or were involved in threads with multiple people. All the information in one email is likely correlated, but out of 5 messages you may need to do some type of context searching, etc.
    – Eric G
    Commented Jul 16, 2015 at 22:15

While many good reasons have been given already, the over all concept is to separate the lock and key which can improve security.

For instance, if an attacker is indeed sniffing network traffic, where are they sniffing it? Let's say that the sender or receiver is sending information on the move and they switch from a wifi hotspot to a 4G network, to another hotspot, etc. If that is the case, then your separation is very far indeed.

Take another case where the receiver's inbox is 'compromised'; when does the attacker actually steal the information? If an attacker steals the password and file immediately but it takes time to tie the two together, then the information may become obsolete and thus inactionable.

As you can see there are a few instances where this sort of behaviour would be more secure than simply passing them both in one email. While this behaviour is not ideal, it is an easy and effective way for lay-people to add a tiny bit of security while sending information -which is why it is used.


If you're going to send the password by email, then yes, it is good practice to send separate emails. If you send an encrypted file and the password to decrypt it in the same email, the encryption is useless, you'll get just as much security sending plain text.

(That's not completely true: sending an encrypted file with the password may bypass some automated surveillance. But such surveillance would be likely to pay extra attention to content that looks encrypted.)

There are two main threats against email. The email may be captured in transit. This is actually a low risk: most email systems are protected by TLS from the client endpoint to their server, and server-to-server communication is not vulnerable to eavesdropping except by high-powered attackers who have other ways to get your emails anyway. The other risk is that either the sender or the recipient's mailbox is compromised. Sending the password in a separate email at least allows both sides to delete the email containing the password from their archive once they've copied it to their password repository — deleting the encrypted file would make the content harder to find, so it is usually not desirable.

There is also a risk that the email with the encrypted attachment will be part of a conversation, perhaps involving new parties, and that would leak the password if it was included in quoted text. A separate email avoids this risk as well.

But relying on a password sent by email is not good. Sending the password by some other means is an improvement, because it increases the difficulty for an adversary to obtain both the content and the password.

However the Right Way to exchange encrypted content is with public-key cryptography. This is harder to set up: unfortunately there is not easy way to set this up with non-technical users outside of an organization. However it makes it possible to reach a much higher level of security. First you obtain, once and for all, the recipient's public key. Sending the public key by email is secure enough for many uses, but doesn't protect against a communication channel that is already compromised to the extent of allowing undetected modifications; confirming out of band (e.g. reading a checksum over the phone) provides a sufficient level of security for all but the most paranoia-requiring scenarios. During and after the public key exchange, the confidentiality of the emails is irrelevant.

  • It bypasses censors that don't allow you to send or receive certain kinds of files even if zipped.
    – JDługosz
    Commented Jul 20, 2015 at 0:27
  • @JDługosz Yes, but that's a different scenario. This question was about an encrypted zip with an expectation of confidentiality. Commented Jul 20, 2015 at 0:30
  • It doesn't actually say that, FWIW.
    – JDługosz
    Commented Jul 20, 2015 at 1:09
  • @JDługosz Yes, it does: the question is asked on a site about security. So I didn't bother to discuss scenarios not related to security in my answer. Commented Jul 20, 2015 at 1:12

Provided you want or have to send the password via e-mail, unencrypted, I would recommend sending half of the password in the second mail and second half of the password in the third mail.

Better yet send the first half via e-mail, and the second half via SMS/Other means.

(Still better yet use asymmetric crypto, and exchange the public keys via snail-mail. But this has been covered in a zillion other places, so I will not repost it here).


As the sender, you not only have a problem if the data is compromised. You also have a problem if the data might be compromised. If you send encrypted data and password to the same wrong recipient by mistake, you must consider it compromised with all consequences (cleanup, explanations to the press, paying fines and so on), even though a random recipient will most likely just ignore that mail and throw it away.

Sending encrypted data and password separately means the data only needs to be considered compromised if the encrypted data went out to the wrong party, and the password also went out to a wrong party (even if it is a different wrong party you need to consider it compromised). Which saves you lots of money if there was no actual attack but just stupidity.

It's not security against a determined attacker, but it can safe you lots of trouble and money if there is just the normal everyday stupidity involved. And it's so simple to do that it is really bad practice not to do so.


well sending both password and file is very risky especially if you are targeted and if the contact is only available via email and parties haven't agreed to use certain password in advance this scheme can be followed to securely sending a file

send an email containing public key of a known public key crypto algorithm and ask for the password to be encrypted using this key

after you receive the password encrypted with the public key you can decrypt it using the private key now both of you have the password (Notice that the password can be decrypted if and only if you have the private key which of course you wont share with anyone however to encrypt you will need the public key which you will send by email ) now you can encrypt the file using the password both of you share. this is bullet proof technique for your personal uses and for most of other applications .


There is unfortunately a need to at least have an understanding of the threat model you are facing. If you even think the local network has been compromised then you should do it face to face, but if that were the case, then you'd be enacting other procedures besides this.

You must log in to answer this question.

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