As security incidents go, this was pretty minor. We’re talking about a handful of customers out of perhaps hundreds of thousands who clicked on the wrong link in an email. And yet it illustrates how even a seemingly insignificant attack can reverberate. The company’s brand suffered because there were erroneous reports that the company itself had been breached. And a relatively simple action could help keep my company, and our customers, from meeting a similar fate.
That simple action is to beef up our authentication requirements by increasing password complexity and enforcing multifactor authentication. With this plan in mind, I created a presentation for the executive staff and even consulted with a number of key strategic customers to obtain approval.
With our customers, as with our employees, I strive to make security invisible and convenient. For example, endpoint security should work in the background, invisible to the end user and not affecting performance. But sometimes security concerns come to the fore and you have to take steps that might seem onerous to users. Even then, though, you do what you can to make the adjustment as easy as possible.
The first part of this plan is to increase the minimum length of passwords, heighten their complexity and prevent the use of a few common and easily guessable passwords, such as “password” and “qwerty.” The minimum password length is increasing from six characters to nine. That makes a huge difference. Nowadays, run-of-the-mill CPU power in a consumer PC is sufficient to crack a six-character, complex password in less than 15 minutes. With nine characters of reasonable complexity (no dictionary words, for example), the time needed increases to more than a year. To ensure more complexity in passwords, we will require that they include upper and lowercase letters, numbers and special characters.
The more powerful change is our stance regarding multifactor authentication. It’s already an option for our customers, but they typically disable it, perceiving it to be an inconvenience. We’ve attempted to battle this perception with various marketing campaigns, to no avail. Now, though, it will be required.
Well, some exceptions will probably have to be made. What generally happens with multifactor authentication is that a one-time code is sent as a text message to a mobile phone. That won’t be workable for some customers, who might, for example, work in a secure facility that prohibits the use of mobile devices. For everyone else, we will make the requirement as easy to cope with as possible. Users will be able to click on a “trust this device” button and won’t have to enter a code again on that device for 90 days.
Now, you might wonder why I would bother with enforcing stronger passwords when I am also planning on getting tough on multifactor authentication. One reason is that it benefits our customers: It is fairly common for users to employ the same passwords for other accounts. If they do reuse the password they create to access their account with us (which I definitely don’t recommend, by the way), at least they will be reusing a relatively strong password. Another reason is that multifactor authentication is not an option for API access, so it seems wise to require a password that is strong enough to be a decent compensating control.
The new requirements will affect more than 300,000 users. We will deploy in phases, reaching our goal of 100% compliance in 90 days. Aggressive, yes, but given the current threat landscape and the ramifications of the compromise of just one of our customer’s credentials, I feel it’s a necessary step for the future of our product.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.
Click here for more security articles.