TSC Trusted Advisors’ Blog

Password Authentication Takes Another Poke In the Eye

On January 4th as reported on DarkReading and DataBreaches, Lincoln National Corporation notified the New Hampshire Attorney General’s Office of a major security breach affecting 1.2 million people. In addition to the internal cost of investigating the breach and bringing in an external forensics team; in addition to planning and executing remediation activities; in addition to the brand impact and loss of trust in the marketplace, Lincoln National had to cut checks for identity and credit monitoring services for all affected users.

So, was it the theft of vast swathes of personal data? Was it a parade of credit card numbers marching off into the distance? Was it, the now so old school, three men wearing ski masks scurrying out the rear entrance carrying bags with “Loot” written on them?

No. It was that some of their system users were caught sharing passwords. This is a classic “cautionary tale” ( as your grandmother might have said) about how users making poor choices about security issues can impact a corporation in a real way.

So how can you defend against password sharing? Assuming that you already have a policy that prohibits it, I think there are three vectors to consider:

• Training and education
• Making non-compliance difficult
• Monitoring and detection

Clearly, people have to be trained to know that they shouldn’t share passwords. But there are several problems that make this ineffective as the main defense. First, most people don’t care and so will forget. Many users will just not understand or even make the mental connection between what they were told was unacceptable and their subsequent errant behavior. Second (and my favorite), is the common case where people know that it is not allowed but do it anyway in the belief that they are saving the company from itself by ignoring policies that obstruct efficient business operations. You can try either carrot- or stick-based initiatives, but ultimately anything that absolutely depends on users making smart choices is doomed to failure.

So make non-compliance hard. The most obvious solution here is multifactor authentication (MFA). If logging in requires a password and a physical token of some sort (OTP or PKI certificate for example) or some other second factor that cannot be as easily shared as a password, then you are starting to protect people from their own poor judgment. Though I am generally skeptical of the value of password lifetime limits, this is one case where they do help. If the password must be changed every month, then sharing it with others can start to become a burden as the improperly credentialed users need to find out what the new value is from the original owner repeatedly.

Monitoring and detection can be hard to do. It is possible to describe scenario details that a system could use to distinguish valid use cases from people with shared passwords, but they are complex, difficult to implement and subject to many false positives. If a user logs in from two IP addresses within a short time window, that could be a bad thing — but it might also mean they moved from their desk to a conference room with their laptop and switched to using a WWAN link. Geolocation helps…until people go on a business trip. This begins to feel more like an exercise in fraud detection with the consequent vagueness and probabilistic results that you get in that field.

Another concern here is when you want to protect passwords to systems that you do not actually manage. For example, financial services companies often form partnerships and supplier relationships that entail their staff logging into an upstream provider’s system. If the people who want to enforce a password policy do not have direct command and control over the systems in question, it seriously impacts their ability to implement MFA or monitoring solutions.

Bottom Line: Authentication Proxy

So really, the ideal solution is some form of authentication proxy. Allow the user to authenticate locally where you have control and then assert their identity to the remote relying system. This means not letting the user know the password to the remote system. Once they have logged in to your satisfaction locally, the system enters a password into the remote system on their behalf. If the technology components used are mature enough, they may support SAML assertions or such-like to do this gracefully.

This approach gives you the control to enforce MFA and monitoring locally and to leverage that value on remote systems. Then you can just outlaw all passwords that are not managed by such a system and perhaps even watch for those at the perimeter in some cases.