Why You Shouldn't Email Bank Account Numbers

It is widely known that it is insecure to send credit card numbers by email, as email is transmitted through the internet unencrypted (in "plaintext") and can be read by anyone with access to computers through which the email passes on its way from the sender to the receiver. The risk is that the credit card number might be disclosed and used by an unauthorized party.

A lesser known fact is that it is also insecure to send bank account numbers by email (for the purpose of performing a wire transfer). The danger here is not one of disclosure. It would not be damaging for bank account numbers to be publicly disclosed; some companies even put them in their website. Rather, the danger is one of modification. Because email is so insecure, it would be possible for someone to modify the email during transmission so as to replace the bank account number with a different bank account number. This could result in the recipient of the email transferring a large amount of money 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 secure medium. Two parties might have an email conversation lasting for months involving intricate negotiations which finally culminate in one party emailing a bank account number to the other party so that they can 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 the final email to cause the second party to transfer a few million dollars into the wrong bank account! The email conversation may feel secure to the parties because it has been conducted so reliably, but it is still vulnerable to this kind of substitution attack at the critical moment.

The danger may not be recognised by many business people who may think 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 emailed bank account numbers:

Do not transmit your own bank account number to other people by email.

If someone emails you a bank account number, verify it by phoning them and have them read it out to you.

If you expect that someone will wiring you a large amount of money soon, notify them in advance that you will not be providing them with your bank account number by email and provide it via some other secure channel in advance. This will reduce their susceptability to a well-timed created (not substituted) forged email instructing them to transfer money into a particular bank account.

If you need to email bank account numbers, use PGP (see below).

The reality is that an attack is not likely to occur in the short-term. However, if you get into the habit of emailing bank accounts in plaintext email, you leave yourself vulnerable, in the long term, to a sudden, unexpected and irreversible financial loss.

Pretty Good Privacy (PGP)

If you want to transmit bank account numbers, credit card numbers, computer passwords and other such critical information by email, you should encrypt your email. To do this, I recommend PGP. PGP is an encryption program that integrates with popular email programs to provide email encryption. PGP provides encryption so strong that it is generally accepted that not even governments can decrypt messages 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 want to, you can purchase it from Network Associates, or one of their distributors.

Assessing The Risk (For Technical Types)

How easy, in practice, would it be for someone to substitute the text of an email message with a different text without being detected? It turns out that there are two levels at which such an attack could be made.

When a sender S wants to send an email message M to a recipient R whose 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 Y that is the mailserver for domain.com. Once Y is identified, X opens a direct TCP connection to Y and sends the email message using the unencrypted SMTP protocol. The packets that flow in this direct connection may pass through many computers (e.g. 10) C1, C2, ... Cn on the internet. The message is then stored on Y until R invokes R's email client to transfer the email to R's computer.

This transmission process implies two levels of attack. The message can either be substituted when it is being stored on disk on one of these computers, or it can be substituted during transmission between the computers.

Let's assume that S and R's computers are secure. It's possible that they might not be secure, but in this exercise we are mainly attempting to measure the risk of email transmission through the internet. If the senders or recipient's computers are compromised, then all is lost anyway! Let us also assume that the links from S to X and from Y to R are secure. Typically these will be local ethernet, or direct dialup, and relatively secure.

This leaves two main points of attack. The message can be substituted while it stored by X or Y ("mailqueue attack"), or when it is in transmission through C1..Cn ("transmission attack").

It would be possible, but relatively messy to intercept the IP packets forming the email conversation between X and Y and substitute a different message. The IP packets are forming TCP windows and satisfying all sorts of complicated protocol requirements. There are two ways in which a substitution might be performed easily. The first would be for one of the computers C1..Cn to pretend that it is Y and receive the message as a complete email message and then substitute it and pass the substituted message onto Y using a separate TCP conversation 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 simply to find the IP packet that contains the body of the message and modify the bank account number in-situ and fix up the IP packet checksum. This might work. Such an attack could be automated by taking control of a router on the internet and configuring it to search each IP packet for strings such as "BSB" and "Account" and substitute a different account number in-situ and on-the-fly! To avoid unnecessary early detection, it would be wise to substitute only packets that contain large dollar amounts. In fact, it would probably be optimal for the fraudulent party to wait for a single large transaction and then jet off to a tax haven.

A far easier way to perform the substitution would be to have access to either email server X or Y. On servers such as these, email messages are routinely stored in their complete form as files for hours, sometimes days. It would be very easy to substitute a message. As email servers X and Y typically reside within ISPs, the people who would have the greatest opportunity to perform such an attack are the staff of ISPs, or intruders who break into the ISP mailservers.

I would estimate that it would take a month to engineer a transmission attack with access to one of C1..Cn and a day to organize an automated mailqueue attack, given access to X or Y. While it may be unclear exactly how difficult it would be to substitute an email message using various methods, it is clear that the level of difficulty is minor when compared to the amounts of money that are typically moved around the world using wire transfers. Even if it took an intruder a month to set up an attack, this investment would clearly be worthwhile if it yielded the intruder a million dollars!

Conclusion

I hope that this page has clarified the dangers of transmitting by email bank account numbers and other such critical information that will be acted upon in significant ways by the email recipient.

Ross Williams (ross@ross.net)
31 July 2001