On 12 August, 2009, a Rocky Mountain Bank employee sent sensitive information to the wrong GMail address. The tale of how the problem was ultimately resolved is a bit long, sordid, and painful to read. A court order was issued to have Google shut down the recipient's email account long enough to delete the missent message from Google's servers, and Google was eventually allowed by the court to reactivate the unfortunate user's email account. The missent email itself, it turns out, was never actually viewed by anyone before being deleted.
CNET writer Elinor Mills asked:
should the person who registered the e-mail address lose access to the account or have items deleted without his or her permission, particularly through no fault of their own?
what recourse would the bank have if the data had been sent via regular mail to the wrong address?
These are important questions that lead to the very heart of the matter — the availability of privacy technologies, the implementation of good privacy protection policies, and the way most of the world is failing at both tasks. Given the easy availability of privacy technologies such as OpenPGP that can be used to prevent problems exactly like this, the only excuses that come to mind for such issues ever arising are laziness, ignorance, and incompetence.
Why do banks, utility companies, and other organizations that offer online services that deal in sensitive data not have adequate security policies in place to guard against these problems? Why do they not at least allow users to opt-in for secure messaging via standardized privacy technologies? Why does the Chase Online site for JP Morgan Chase Bank not allow its customers to limit communications containing sensitive information so that they will only occur over secure channels?
If your organization ever sends any sensitive information via plain text email (or, worse, unencrypted Webpage), it is not serious enough about privacy. Even if they are sent to the correct person, there is always the possibility that someone else eavesdropping on the network might be able to capture that sensitive data — and, conversely, even if you think you're safe because both ends of the communication are secure, your bank might have an employee who will send an email to the wrong address.
Banks and other institutions that regularly deal with sensitive financial data, or equivalently private information, should take a number of simple steps to ensure the privacy of their customers, all of which are solved by the capabilities of public key encryption protocols such as OpenPGP:
They should stamp all emails with verifiable cryptographic signatures, so the legitimate emails can be differentiated from spam and phishing emails that spoof the source address or otherwise pretend to be something they are not.
They should ensure that customers cannot set up access to sensitive data without either doing so in person or making use of some out-of-band, second factor authentication mechanism.
They should ensure that customers never need to worry that any sensitive data will ever be sent — or requested — via unsecured channels such as unencrypted email.
I understand that many end users are not quite technically savvy enough to be able to make use of the cryptographic tools that already exist, but we have a chicken and egg problem here. Someone needs to start pushing things toward a better way of doing things so that others can follow. Part of the problem is that, for the majority of users, securing their communications is far from "second nature". Many of them do not even understand that plain text email is not entirely private or secure, especially when that email is stored on a third party's servers.
Still, some of us are fully aware of the implications of using plain text email, and a step in the right direction would be for organizations like our banks to offer at least an option to require all communications concerning sensitive data (anything but unpersonalized mass mailings, in other words) to be delivered only via secured channels. I should be able to click checkboxes at my bank's Website saying "Always Digitally Sign Emails" and "Always Encrypt Emails", ideally with an option I can check that says "Use OpenPGP Public Key Encryption". Go ahead and set it under an "Advanced" tab — I promise I won't be offended. Call that the opt-in advanced security option.
The default, opt-out basic security option should be that plain text emails will only tell me to go to my bank's encrypted Website and log in to receive a critically important message. The information would then still be encrypted, and while both verification and the security of the encryption might be slightly less certain, it would be a lot better than sending plain text emails with sensitive information in them for anyone with a packet sniffer to read. Make the "Use Unsecured Email" option opt-in, with plenty of disclaimers to let people know just how stupid it would be to turn off all the secure communications options.
To be fair to Chase, it does do some things correctly that many other banks do not. For instance, when signing up for a user ID at the Chase Online site, it gives you three options for out-of-band verification that you are who you say you are — an SMS text message sent to your cellphone if that is the number they have on file for you, a voice call to the telephone they have on file for you, or an email to the address they have on file for you, in each case to provide you with a one-time password to complete the sign-up process. None of these options encrypts the communication, but I suppose we should be happy with baby steps for now.
GSM communications are encrypted.
— Nitpicker · 2009-11-25 · #
Good point. You are technically correct, though the practical privacy offered by GSM security is questionable. The encryption is not end-to-end, and uses a pre-shared key whose secrecy is in no way guaranteed. While that does protect against random eavesdroppers at your end of the conversation, that's really all it protects against. For purposes of secure communications with your bank, I wouldn't say this qualifies.
— apotheon · 2009-11-25 · #