It is widely known that it is insecure to send credit cardnumbers by email, as email is transmitted through the internetunencrypted (in "plaintext") and can be read by anyone with access tocomputers through which the email passes on its way from the sender tothe receiver. The risk is that the credit card number might bedisclosed and used by an unauthorized party.
A lesser known fact is that it is also insecure to send bankaccount numbers by email (for the purpose of performing a wiretransfer). The danger here is not one of disclosure. It would not bedamaging for bank account numbers to be publicly disclosed; somecompanies even put them in their website. Rather, the danger is one ofmodification. Because email is so insecure, it would be possible forsomeone to modify the email during transmission so as to replace thebank account number with a different bank account number. This couldresult in the recipient of the email transferring a large amount ofmoney into the wrong bank account!
This security problem is potentially a significant security risk,as it is so easy to get into the habit of treating email as a securemedium. Two parties might have an email conversation lasting formonths involving intricate negotiations which finally culminate in oneparty emailing a bank account number to the other party so that theycan transfer a few million dollars. All it would take, at that point,is a malicious person to substitute just a hundred or so bytes in thefinal email to cause the second party to transfer a few milliondollars into the wrong bank account! The email conversation may feelsecure to the parties because it has been conducted so reliably, butit is still vulnerable to this kind of substitution attack at thecritical moment.
The danger may not be recognised by many business people who maythink of email as being insecure only from a privacy point of view,and forget that the integrity of email may be compromised as well.
Suggested Policy
I advocate the following policies with respect to emailedbank account numbers:
The reality is that an attack is not likely to occur in theshort-term. However, if you get into the habit of emailing bankaccounts in plaintext email, you leave yourself vulnerable, in thelong term, to a sudden, unexpected and irreversible financial loss.
Pretty Good Privacy (PGP)
If you want to transmit bank account numbers, credit cardnumbers, computer passwords and other such critical information byemail, you should encrypt your email. To do this, I recommend PGP. PGPis an encryption program that integrates with popular email programsto provide email encryption. PGP provides encryption so strong that itis generally accepted that not even governments can decryptmessages encrypted using PGP without the correct decryption key.
To use PGP, both the sender and receiver must have installed PGP.
PGP is available in various free and commercial forms. If you wantto, you can purchase it from Network Associates, or one of theirdistributors.
Assessing The Risk (For Technical Types)
How easy, in practice, would it be for someone to substitute thetext of an email message with a different text without being detected?It turns out that there are two levels at which such an attack couldbe made.
When a sender S wants to send an email message M to a recipient Rwhose email address is user@domain.com, S's email client (e.g.Eudora) connects to mailserver X and transmits the email message to X.X then acesses the domain name system (DNS) to identify the computer Ythat is the mailserver for domain.com. Once Y is identified, X opens adirect TCP connection to Y and sends the email message using theunencrypted SMTP protocol. The packets that flow in this directconnection may pass through many computers (e.g. 10) C1, C2, ... Cn onthe internet. The message is then stored on Y until R invokes R'semail client to transfer the email to R's computer.
This transmission process implies two levels of attack. Themessage can either be substituted when it is being stored on disk onone of these computers, or it can be substituted during transmissionbetween the computers.
Let's assume that S and R's computers are secure. It's possiblethat they might not be secure, but in this exercise we are mainlyattempting to measure the risk of email transmission through theinternet. If the senders or recipient's computers are compromised,then all is lost anyway! Let us also assume that the links from S to Xand from Y to R are secure. Typically these will be local ethernet, ordirect dialup, and relatively secure.
This leaves two main points of attack. The message can besubstituted while it stored by X or Y ("mailqueue attack"), or when itis in transmission through C1..Cn ("transmission attack").
It would be possible, but relatively messy to intercept the IPpackets forming the email conversation between X and Y and substitutea different message. The IP packets are forming TCP windows andsatisfying all sorts of complicated protocol requirements. There aretwo ways in which a substitution might be performed easily. The firstwould be for one of the computers C1..Cn to pretend that it is Y andreceive the message as a complete email message and then substitute itand pass the substituted message onto Y using a separate TCPconversation with Y. I am not sure how difficult this would be to do,but I suspect it wouldn't be too easy. The second way would be simplyto find the IP packet that contains the body of the message and modifythe bank account number in-situ and fix up the IP packet checksum.This might work. Such an attack could be automated by taking controlof a router on the internet and configuring it to search each IPpacket for strings such as "BSB" and "Account" and substitute adifferent account number in-situ and on-the-fly! To avoid unnecessaryearly detection, it would be wise to substitute only packets thatcontain large dollar amounts. In fact, it would probably be optimalfor the fraudulent party to wait for a single large transaction andthen jet off to a tax haven.
A far easier way to perform the substitution would be to haveaccess to either email server X or Y. On servers such as these, emailmessages are routinely stored in their complete form as files forhours, sometimes days. It would be very easy to substitute a message.As email servers X and Y typically reside within ISPs, the people whowould have the greatest opportunity to perform such an attack are thestaff of ISPs, or intruders who break into the ISP mailservers.
I would estimate that it would take a month to engineer atransmission attack with access to one of C1..Cn and a day to organizean automated mailqueue attack, given access to X or Y. While it may beunclear exactly how difficult it would be to substitute an emailmessage using various methods, it is clear that the level ofdifficulty is minor when compared to the amounts of money that aretypically moved around the world using wire transfers. Even if it tookan intruder a month to set up an attack, this investment would clearlybe worthwhile if it yielded the intruder a million dollars!
Conclusion
I hope that this page has clarified the dangers of transmittingby email bank account numbers and other such critical information thatwill be acted upon in significant ways by the email recipient.
Ross Williams (ross@ross.net)
31 July 2001
