Dear Vendor: Keep My Information Secure

Dear vendor:

If you’re reading this, we have done business together, either directly or indirectly. You might be a retail website from which I purchase products or services. You could be a social media empire on which I share blog posts, life events, and photos of my meals. You may be a physician’s office I visited 15 years ago. You might even be a vendor of a vendor (or a vendor of a vendor of a vendor) with whom I have no direct association, but you still store and process some of my sensitive data. There may or may not be an exchange of money involved in our business relationship – but even if there isn’t, this letter is still intended for you. We may not know each other’s names, but you are a vendor of mine, and I am a client of yours. As such, this letter is meant for you.

First of all, thank you for the service you provide. Since we have been (or may potentially be) doing some sort of business together, I assume that you have a service that is of use to me, either directly or indirectly. We have an understanding of terms, which is most likely defined in the EULA or TOS document you drafted. However, your terms of service don’t fully address my expectations with respect to security. I expect you to keep my information secure, above all else. I’ve spent my career working with data-enabled applications, and through the course of that career I’ve come up with a few simple things I look for in every vendor with whom I share my data. I use these criteria to help me choose (or continue to use) my vendors, so please consider these requests carefully.

With that said, here are a few requests I have of you, as my vendor, to help secure my sensitive data in your care.

Provide a secure means for registration and login.

This one is at the top of the list for two reasons. First, this is the most egregious security issue on the list. Registration and login web pages almost always involve a password that the user types in, and applications that do not protect the data transfer with a secure (HTTPS) page are transmitting the credentials in plain text. Anyone with visibility to that web traffic – which includes others on the same physical or wireless network, as well as any other network through which the request travels – can easily capture those credentials using simple network tools that are free and readily available. Second, this is the most easily solved problem on the list. Securing an existing registration or login page rarely requires extensive changes to the web application or architecture, and can be done at a relatively small cost.

It’s difficult to believe that this is even an issue anymore. But it does still happen, and not just on the fringes of the Web. In fact, earlier this month, ARS Technica reported that Match.com, a dating website claiming tens of millions of members, was using an insecure login page on its website (though it appears that this security hole may have been closed since that article was published). This type of vulnerability would have been unacceptable in the mid-1990s, when the Internet was still evolving. The fact that some vendors still don’t use secure pages for registration and login twenty years later is simply unacceptable.

Don’t ever email my password to me.

Email is generally not a secure means of transmitting information. There are numerous opportunities for email messages to be compromised during transmission and storage. This is especially true with webmail services, where convenience, not security, is the primary focus. If you email my password to me and the path along which the email travels contains any insecure segment, you’ve now transmitted my password to anyone who might be watching. I’ve seen this password mailing issue take on a couple of different forms:

• Emailing the credentials immediately upon signup (Thanks for registering! Here’s your user name and password, as a reminder.)
• When using the “Forgot your password?” functionality, my current password is emailed to me
• The password reset feature emails me a new, temporary password

Any scenario in which you email me a password, even a temporary one, creates an unnecessary security risk in which someone could capture that login information and impersonate me. Instead, skip the part where you email me my credentials upon registration (since I’ve already stored them in my password management software anyway), and use a smarter password reset system in which you email me a single-use link – which expires minutes after it is sent – to allow me to reset my password securely on your website.

Let me create a long and complex password.

This is a limitation I frequently encounter, and it’s one of my biggest pet peeves when it comes to security. While a user name/password credential system is a really crappy way to do authentication on the web, unfortunately it’s the best option we have right now. As such, you should be doing everything you can to let me keep my password secure. There are two ways to make passwords more difficult to crack: length and complexity.

When your system disallows a long and/or complex password, I instantly get a bad feeling about using you as a vendor. Limiting password length or complexity reeks of laziness. In so doing, you’re telling me that your security measures aren’t sophisticated enough to handle a well-designed password, which makes me question how much effort you put into the back-end security processes I can’t see. If you can’t effectively process special characters in my password, what other shortcuts are you taking in securing my data?

Enable two-factor authentication.

This extra measure of security is growing in popularity, but is still not implemented nearly enough. In two-factor authentication, a password alone does not allow me to log in. This scheme requires a secondary vehicle, typically a cell phone, to authenticate my identity when I log in. When I log in using two-factor authentication, I use my password plus a one-time code you send me via text message. After logging in using those credentials, I can mark this as a trusted machine (assuming it’s my private computer and not a shared device) so that I can simply log in using my password on that same machine until the authentication cookie expires.

I’ll admit: two-factor authentication is a tiny bit of a pain for the consumer, and it’s even more taxing on you as a vendor. However, for critical or sensitive services such as email, website DNS, banking, etc., two-factor authentication should be the rule and not the exception. To their credit, institutions such as Facebook, Twitter, Google, Dropbox, Microsoft, and many banks (even small ones) are getting on board with this. But there are still some of you vendors that don’t yet support two-factor authentication. Increasingly, I’m using this as one of the main decision points as to whether I’ll choose you as a vendor.

Secure my sensitive information in your database.

The often-repeated mantra of information security professionals is that data is only as secure as its weakest link. If you employ all of the steps above but store the data in an insecure manner, you haven’t accomplished much. The retailer T.J. Maxx learned a very expensive lesson about this a few years back, when their insecure storage of credit card numbers led to one of the largest breaches in history, with an estimated 94 million accounts compromised. Almost every database system has one or more mechanisms for securing or masking data, including encryption and hashing. Unlike the other requests I’ve made of you herein, I’m going to have to trust you on this; I don’t have visibility into your back-end security, and mostly likely you’re not going to fully disclose to me the exact details of the security measures you use (and for good reason). But I do expect that you are taking necessary precautions to store my data at rest as well as in transit.

If you make a mistake with my data, fess up.

If you somehow foul up (or even worse, simply skip over) the implementation of any of the above and my data is exposed, I expect you to come clean immediately. You don’t have to tell me everything you know in the heat of the battle, but I expect you share with me the following pieces of information as soon as possible:

• Whether my information was compromised
• A high-level analysis of what failed (subject to change, of course, as more facts become available)
• What you’re doing right now to address it

Once the dust has settled, I’m going to have many more question as to the details of the root cause analysis, and the fixes to avoid the same issue in the future. If my information has been directly affected, I’m going to want to know how you plan to fix it to make sure I’m not impacted in the future.

If you want a template of how to respond to a data breach crisis, read this post (one of many with a similar theme) about Buffer’s response when their systems were compromised back in 2013. Although my account was not one of the ones compromised in this breach, I was a Buffer user when the breach occurred. The transparency shown by Buffer CEO Joel Gascoigne during this crisis gave me the information I needed both in the short and long term, and today I remain a happy and confident Buffer client.

In closing… just keep my information secure

This, above all else, is what I expect of you. The six security requests above are not the only steps you need to take, obviously. The surface area you must protect is far broader than what I describe above, and involves back end processes including securing data backups, restricting access to sensitive data at rest, and proper security auditing, among many others. The measures above are only the most visible components (to me as the consumer, at least) of what I expect to be a complex and comprehensive security infrastructure.

I realize that these requests do not bind you to comply. All of the above would take time, planning, and money to implement, and you’re going to do extensive cost-benefit analyses of these items before implementing any of them. As a data professional and a consumer, I strongly you to get on board with these necessary security measures. It’s the right thing to do. Being reckless with the sensitive data of others will give you a bad reputation and a potential exposure of liability. But more importantly: It could cost you my business.