On Multi-factor Authentication

Luther Martin of Voltage Security posted a very interesting post on the future of multi-factor authentication. In it, he challenged commonly held beliefs on the subject. Specifically, he writes:

It’s often claimed that multi-factor authentication is inherently more secure than single-factor authentication, but if you look at the history of this claim,it actually came from a vendor that wanted to make their multi-factor authentication product sound better than competitors' products.

(I'm not sure if these are his thoughts or if he's saying that was the consensus at a recent X9 meeting.)

Martin goes on to suggest that using two authentication mechanisms of the same factor may be as secure as using two factors and lays out scheme A & B to discuss.

So here's my thoughts:

Wouldn't scheme A be more secure because you can't brute force it? Isn't that the whole point of having the second factor? All passwords can be brute-forced given enough time. Having the second factor removes that threat.

Of course, you could implement a strong password plus a kill switch after 10 bad tries, but that still relies on the user to implement safe password storage. And I generally think it's better to remove any responsibility from the end-user (especially if there's a convenience trade off).

Requiring users to carry/remember two username-password combinations for every system doesn't seem practical. Security will fail if users try to subvert it for the sake of convenience. And they will.

Usability needs to be a key consideration. A token/pin combination is a secure and easy-to-use way to beat the threat of brute-force attacks and poor password management. ...as is having a certificate installed on a particular PC and other second factor solutions.

Internet InSecurity

I stumbled across this today

and thought it was pretty cool idea. Use a 3-minute video to educate employees on the dangers lurking in their inbox and reduce your enterprise risk. Nice and simple. And free.

Then, this evening I saw this

IRS employees giving out usernames and passwords to someone who called them on the phone and didn't even attempt to identify themselves. Why worry about password hacking techniques when all you need to do is call up Jerry or Sally at the IRS and ask them to change their password so that you can use their account? Well, at least the IRS doesn't have any sensitive information in its systems. (pardon the sarcasm)

And I remembered this

People don't even bother to look for the security mechanism (SSL icon or the HTTPS in the URL) when it's present so they can conduct their Internet banking.

And I recalled the old adage

We made it foolproof and they produced better fools.

We really have to take users out of the equation and make the security mechanisms invisible. Or make it impossible for them to accomplish a task without taking proper precaution -- like maybe build a browser that doesn't accept any form input unless the site uses SSL with a trusted certificate so the user doesn't need to think about that stuff. Of course, even that won't stop the old phone-call-password-change gag.

It makes you wonder about all the work being done on the identity metasystem for a secure Internet. Putting users in charge of their own information sounds dangerous. Are Jerry and Sally going to take their secure infocard with SSN and credit card info and send it to any site that asks for it? After all, why create more than one card? - that sounds like work.

As a society, we seem to have a massive mental block related to digital security. Maybe we need public service announcements on TV and radio about digital identity theft and secure password management. I think it'll be another decade before the Internet security issue is really figured out for the masses. Unfortunately, it may take that long for general knowledge about computer security to infiltrate society and for the security technology to meet people half-way with making security transparent.

Some Identity and Password Reading

As Ash already mentioned, Jackson Shaw is now blogging. I remember Jackson from a time when MIIS was my tool of choice. He's been doing the identity thing for a while, so he might be worth a read.

Here's a few other useful articles I've recently come across:

• 9 Perfect Password Pointers - In case someone you know needs a reminder (you know, the person writing the password policies)


• Identity Management and Protection: A Key Differentiator? - Yeah, it's not just for CYA any more!


• Provisioning/User Management System Upgrades: Part Two Building Awareness And Building Approval - A little help making the business case is always appreciated.


• Most play poorly at the password game - Moral support for those who think passwords are painful to manage.

...I guess that's all I've got right now.

Password Solutions

One of the primary business drivers for Identity Management has always been password management. System users don't want to remember multiple passwords -- especially if the systems require password changes on different cycles and have varying policies for password length and structure. The frustration is more than understandable. And we've all seen the reports that state the cost associated to that frustration. Password-related Help Desk calls cost $x per call and x number of calls each year per each thousand users equals the enormous cost of managing passwords. I didn't even mention the security implications of having too many passwords.

What we haven't heard often is that there are a number of possible solutions to this problem. We may have heard each of these solutions individually, but usually from a single perspective. I believe that technology infrastructures are complex and dynamic. They're not one-size-fits-all. Every enterprise has a unique environment and somebody needs to (or at least ought to) put forth some actual thought about how to best approach any given environment. So, with that, here are four approaches to the problem of passwords. They are not mutually exclusive and depending on the size of an organization, it might make sense to look at more than one of these approaches.

1. Password Management (Reduced Sign On)
These solutions synchronize passwords across multiple systems. They enforce strong passwords that adhere to the policies of each of the connected systems and remember password histories so that people can't repeatedly use the same password. One of the nicest features of password management solutions is that they allow end-users to recover lost or forgotten passwords through some type of self-service mechanism. This cuts the helpdesk costs and leads to real ROI. System users are left with multiple user accounts which have a common password.

2. Centralized Authentication Infrastructure (Single Sign On)
These are the typical SSO solutions that leverage some type of access policy server. The SSO system identifies a user and determines whether or not to grant access to the requested resource. SSO vendors typically leverage LDAP to authenticate users against an enterprise LDAP directory. If an organization prefers to manage data in a relational database, the SSO system can send LDAP requests to a Virtual Directory which would then pass the request to a back-end database (or any other set of data stores). SSO solutions centralize authentication to a single account and enable management of permissions to access enterprise resources. On the back-end, these systems require access to an authoritative identity data store and therefore usually require either some form of identity data synchronization or a virtual directory implementation (as previously mentioned). One example of multiple back-end data sources is leveraging Active Directory for employees and an Oracle database for non-employees.

3. Single Authentication Source
In this scenario, an organization would forgo the expense and infrastructure of implementing an SSO environment, but would implement a single authentication source with varying authentication mechanisms and logic for each application. If there are a limited number of applications, the value of a true SSO implementation may not be fully realizable. Each application in this scenario would verify credentials against a Directory or Virtual Directory server. Just like in the SSO scenario, a Virtual Directory would enable lookups to one or more data sources on the back-end. This allows the organization to leverage a single set of credentials for authentication to multiple applications.

4. Enterprise Single Sign On (ESSO)
ESSO solutions reside on an enterprise network and manage user access to various resources. The user experience is pleasant because there is only a single point of authentication. Each application maintains its own set of credentials, but the ESSO solution maps user accounts for each system and performs the authentication process on behalf of the end user. Some things to consider are application password change policies and how access from external locations would be handled. The user still has multiple system accounts each with its own password, but the logon process is made transparent by the ESSO solution.

Federation solutions offer another way to handle authentication across multiple systems and may be able to provide an additional solution to password challenges. However, federation solutions are typically implemented for authentication across security domains whereas passwords are typically managed within a given security domain. User-centric identity solutions are another way to approach access across multiple security domains. Ultimately, organizations should consider the alternatives and implement solutions that will provide value within their own given environment based on their own specific requirements.

Security and Password Myths

Kaliya Hamlin pointed to an article about password security and what its author (Prof. Eugene Spafford) calls security myths. It's an interesting article, but I don't agree with the main point, which is that mandatory password changes do not increase security. He calls these policies folk wisdom and claims that best practices are "intended as a default policy for those who don’t have the necessary data or training to do a reasonable risk assessment". Well, I don't agree with that statement or Prof. Spafford's conclusion.

Best practices as I use the term describe an ideal state without knowledge of a given environment. Every environment has exceptions and special needs. Therefore, it's not always possible to implement best practices. But, they should serve as an ideal to work toward. Default policies, on the other hand, are often what's easiest to implement -- just ask any company that sells hardware for wireless home networking products. These products are usually shipped with default settings that make it easy to setup. Best practices, however, require that the installer configure encryption keys that prevent people in close proximity from accessing the network.

Let's move to the password change policies. While there are certainly (as Prof. Spafford writes) a number of password failure modes, these policies are in effect to minimize the effectiveness of one of those failure modes - cracking. We may only differ in our definitions of weak cracking. This article by Geodsoft discusses password cracking techniques. The takeaway is that with a strong password policy, a brute-force cracking attempt will take over two months at 6 characters and two years at 8 characters. It's certainly possible to improve that timeframe with heavy hardware infrfastructure, but I think the policy will serve it's purpose of reducing the threat. And that's ultimately the goal. We all know that nothing in IT is 100% secure, but we should probably implement as many practical policies and solutions as possible to reduce the potential threat.

Internal users, AD password synch and Virtual Directory

At MaXware, we have a product that hooks into Active Directory to capture password changes. Once the change is captured, we can synch passwords downstream to connected data stores (directory, SQL DB, etc.). Like other implementations of this type of solution, ours requires having a component installed on each AD DC to identify and pick up the password changes. Although it's not generally preferable to install software on Domain Controllers, it serves a specific purpose in this case and AD administrators have been known to give-in to their business counterparts to make it happen.

The underlying need is probably obvious - multiple apps each have associated passwords. And more passwords means more to remember, less likelihood of utilizing strong passwords and higher likelihood of non-secure password practices (written notes, etc.).

As we all know, another way to solve the problem is to implement Single Sign On or Reduced Sign On solutions that enable applications to leverage a common authentication mechanism (or at least a common auth store). These solutions are complicated to implement and costly. And you usually need to find a way to synch with AD anyway since corporate users typically change their passwords using Ctrl-Alt-Delete.

ADAM directories serve as one possible solution for some of this pain. You can implement an ADAM directory to serve as the application identity store or even as a central authentication store and pass authentication request credentials through to Active Directory. This means a single password stored in Active Directory that can serve the network environment as well as the apps that leverage ADAM as the Auth Store. If you centralize the store, you don't really NEED to centralize the authentication mechanism, which might be nice in some cases. In environments with a large amount of custom-developed applications, a centralized mechanism would probably provide significant value even if there's already a common authentication store.

Wouldn't it be nice, though, if you could do the same thing without needing to implement ADAM directories and without storing the AD password in two locations? What if a Virtual Directory could pass authentication requests to Active Directory the way that ADAM does? You could potentially use the Virtual Directory to expose only specific attributes to given applications, reduce the overhead of an additional directory infrastructure, eliminate the need to store the AD password in multiple locations (and the need to install agents on AD DCs) and still achieve authentication to multiple systems using a single set of credentials.

[UPDATED Mar. 8, 2006] - Shorty after posting this, I was informed that MaXware Virtual Directory (along with its competition) does, in fact, support passthrough authentication to AD. I guess I thought ADAM was doing more than a simple bind, which is not the case -- I think I learned that years ago and forgot it again. So, I removed the question on technical feasibility. I guess the question becomes why aren't more people talking about this? It seems like it would be an incredibly useful application of our product.

[UPDATED Mar. 18 2009] - I posted more information about ADAM passthrough authentication.