Software

Five guidelines for secure customer communication

Make sure your communications with customers and clients are secure. Chad Perrin outlines five guidelines to secure the sensitive data of your customers.

A Rocky Mountain Bank employee accidentally sent an email containing sensitive information to the wrong Gmail address. This very nearly resulted in disclosure of a customer's private data to the wrong person. Luckily for them, perhaps, a court order was issued instructing Google to shut down the recipient's account and delete the mis-sent email, preventing the information from ever being read by the wrong person. Unfortunately, an entirely innocent third party -- the person whose email address was shut down -- was subject to some serious inconvenience for the sake of cleaning up the bank's mess. You can read about the affair in Elinor Mills' CNET article, Misfired e-mail was never viewed by Gmail user.

None of this had to happen. The Wyoming-based bank's data security policies could have prevented the problem, if not for the fact that those policies are about as ineffective as every other bank's policies. The question that naturally arises is asked in the article Why is bank security so far behind the curve? The article expands upon that question:

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?

When specifying your own data privacy policies, particularly as they apply to communicating with customers and clients outside your organization, the ideal policy should include the following characteristics:

  1. Use cryptographic digital signatures for all communications so they can be verified, even if they do not contain sensitive data. Public key encryption protocols such as OpenPGP are perfect for this.In the case of a major bank, this ensures that emails received by customers and clients with the ability to verify digital signatures will know the difference between a legitimate email and a phishing email.
  2. Use open standard encryption protocols to encrypt all communications that contain sensitive data. Again, public key encryption protocols such as OpenPGP are perfect for this.Encrypted emails will protect customers and clients from both eavesdropping, such as man-in-the-middle attacks, and packet sniffing on local networks and accidental leaks, such as the Rocky Mountain Bank employee's missent email -- because, even if the email is sent to the wrong place, the unintended recipient won't be able to read the email.
  3. Require customers or clients to use digital signatures and encryption as above, when possible, and out-of-band verification otherwise, before authorizing any control over their accounts.A second authentication factor -- out-of-band communications -- such as a telephone call or a cryptographic digital signature will serve to improve verifiability of the identity of a customer or client sending any information or instructions.
  4. Where digital signatures and encryption in email are not practical, do not send email. Use alternate secure channels, such as TLS-encrypted Web sites, instead. Snailmail does not qualify as a secure channel.Unfortunately, the answer to Elinor Mills' question, "What recourse would the bank have if the data had been sent via regular mail to the wrong address?" is the same as it ever was. The bank's recourse for misdelivered bank statements, credit and debit cards, and other sensitive communications when they are sent via the U.S. Postal Service has always been to pretend there is not a problem. You have probably received others' bank and utility bill mailings in the past, in fact, and known that nothing would be done about it if you did not send the mail back to the source.
  5. Where a customer or client absolutely demands that security features be turned off or avoided for the sake of "convenience", make security the default, and only allow an opt-out option for downgrading security.It is of course true that many customers and clients of many organizations would never stand for the sort of "inconvenience" represented by the need to employ secure communications technologies. Let them opt out. Make it easy, in fact, but make it a conscious decision on that person's part, with a disclaimer attached detailing in broad strokes the kinds of security problems that could result. Then, let them live with their choice. Let the rest of us, who are willing and able to make use of the security technologies currently available, reap the benefits.

Given enough time, with enough organizations taking that approach, I think the default will begin to swing the other way. Ease-of-use improvements for privacy technologies, and ease of access, will both improve as more and more people use them -- because more and more organizations make it possible to use them when dealing with those organizations. Of course, this relies on the possibility of organizations actually caring enough about the privacy and security of their customers and clients to do something about it.

Even if they don't, you should. If you are in a position to offer your customers and clients a secure way to communicate, do so. If they turn you down, so be it, but if they take you up on the offer you will have helped to make more people safe. More to the point, you may become part of the long-term solution to the ubiquity of unsecure communication on the Web.

You know what they say about people who aren't part of the solution. . . .

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

9 comments
lastchip
lastchip

Elsewhere, you asked for suggestions for future articles. Security is a on-going issue, that should be at the forefront of everyone's mind. But some of us are still very much on a learning curve and what may be perfectly obvious to many of my contemporaries, is not at all obvious to me. How do I set up a secure log-in on a Linux server? I've set up htpasswd access successfully, but how do I now secure that through ssl (or whatever)? I guess, I need to generate a security certificate; how is that done and how does it tie in? Perhaps fodder for a future "how to" article, that would tie in nicely with the security theme. Thanks for yet another excellent article.

apotheon
apotheon

Are you part of the solution, or part of the problem? If you're in a position to affect security policy, you might want to think about trying to push for policy that allows customers or clients to require that communications only occur over secure channels -- if your organization doesn't do that already. Ideally, all communications with all customers or clients should be restricted to secure channels, but in cases where many of them might not tolerate the demand for the extra knowledge and effort required to use secure channels correctly, at least the option to those who would welcome greater security should be offered.

apotheon
apotheon

I assume you're asking about how to generate certificates for SSL/TLS encrypted Webpage access. That might be some good material for an article (or six). I'll add that to the queue of ideas. Thanks!

Sterling chip Camden
Sterling chip Camden

... an ISP who sent me the username and password for my online account management panel in a single, unencrypted, plain text email. I hit the roof.

lastchip
lastchip

OK, I suppose what I'm really saying is this; I've managed to set up password protected web page accounts via htpasswd, but this data is communicated in an unsecured environment. (as it's not critical information being accessed, it's not essential it's encrypted). However, if you go to properly secured site and click on log-in, you will be taken to a https page, complete with lock and any transmissions from that point forward, will be encrypted. In other words, from log in onwards, the user is in a secure environment. This is far more preferable even if it isn't essential, as I feel it provides a better user experience, gaining the trust of those accessing the data. What I guess is happening, is the lock is produced via a certificate being valid and the transmission is via ssl. Perhaps I'm misunderstanding. That's the bit I'm struggling with, and there's very little I've found, that explains in "Janet and John" language, just what's going on.

apotheon
apotheon

I only use encrypted connections -- not just the login for an email download session, but the entire session is encrypted -- when getting email. Of course, there are other ways "in" than my connection from my laptop to the mail server if someone wants to harvest data from plain text emails sent to me, but at least one potential avenue of access for a malicious security cracker has been shut down. Unfortunately, large corporations tend to give not two craps about how much we feel our privacy is being endangered by their low-rent security policies, so there's little we can do unless we find a competitor who handles things better. We complain, and they ignore.

lastchip
lastchip

Thanks for taking the time to give me that information. It's most appreciated.

Neon Samurai
Neon Samurai

In apache, you can check passwords in clear text or a basic encrypted hash. You sound like you've done the first if not the second. Users go in a .htusers and .htaccess tells the site to use a password and where .htusers is to read it from. I believe the second part your asking about is a url redirection. The site config watches for any specified string in the url and replaces it. I've seen it recommended for correcting spelling mistakes in address bars and such. I suspect this will also watch for "http:" and replace it with "https:". From the browser side, it looks like you hit the page and it defaults to https. I'm sure there are better ways to do it but that's where I'd start from with my Apache Phrasebook. We'll have to see how later articles confirm or replace my guess.

apotheon
apotheon

Yes, you have a pretty good grasp of the 10K foot view. I'll look into writing a couple articles on the subject some time in the next couple months.

Editor's Picks