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
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?
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.
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.
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:
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).
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.
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.
