Tip

SSO: Strong authentication in enterprise deployments

Enterprise single sign-on (SSO) provides end users with an improved user experience and helps IT staffs reduce the cost of managing passwords for many applications. Still, a nagging concern persists. If the single credential

    Requires Free Membership to View

is compromised, an attacker has free reign over all accessible resources. Does the ubiquitous simple password, which can be easily cracked, provide adequate authentication in an SSO world?

Before we answer that question, the point needs to be made that SSO is part of a larger identity management infrastructure. Every SSO initiative should be coupled with an analysis of the organization's authorization/access control model to make sure that sensitive resources are in fact protected. It's bad enough if an SSO credential is compromised, but if that compromised credential provides access to unauthorized (and sensitive) resources due to weak access control – it will be a bad day for the security management team.

Passwords have been the preferred authentication mechanism for many years. They are easy, portable and cost virtually nothing to deploy. Of course, for every convenience there are compromises. First, passwords are easily stolen and are subject to brute force dictionary attacks. If stronger passwords are required, users inevitably forget them more often – resulting in higher help desk costs. To offset those higher costs, reasonably priced self-service password reset products are available to streamline the process.

Whether passwords provide sufficient security has everything to do with what is being protected. Security is one huge risk/reward analysis, and security practitioners need to decide every day whether the potential risk is worth the cost of more stringent security. Of course, regulatory requirements have changed that a bit, in that the cost of a compromise is far greater than in the past. So security initiatives tend to be approved more often, but the analysis still needs to be done.

Many organizations opt to replace and/or supplement passwords with other authentication methods to ensure the SSO credential is sufficiently protected. One-time passwords, which anchor two-factor authentication, are very popular since support for technologies like RSA's SecurID is built into almost every applicable network access product, making integration minimal. Smart cards, which contain a digital certificate to prove identity, are also popular in Europe and many government environments.

On the negative side, issuing, managing and renewing tokens and smart cards is not cheap. There are also user experience and training complications, since a lost token can keep a key employee out of critical systems at crucial times. This does not make the security folks popular in the executive suite.

Despite their issues, look for smart cards to become more prevalent over the next two-three years. Bill Gates made it clear at RSA 2006 that Microsoft has anointed the smart card (via the acquisition of Alacris) as the cornerstone of the Vista OS authentication strategy. Whether we like it or not, in a great majority of cases where Microsoft pushes a technology – it becomes a factor.

The next option for authentication is biometrics. There has been a (mostly vendor) push for biometric technologies to replace something you have (cards and tokens), with something that uniquely identifies you like fingerprints or retina patterns. Of course, a limitation of biometrics is accuracy. A small percentage of people have no recognizable fingerprint, so a fingerprint scanner isn't going to be effective 100% of the time.

There are also emerging technologies, like BioPassword, that are interesting. These folks have an algorithm to determine the validity of a login attempt by how the user types in the password. I know it sounds a bit far fetched, but it works. I've used it. Of course, in order to gain any ground on the incumbent tokens and passwords, emerging technologies must be priced to move and be integrated with the prevalent applications and devices.

Ultimately the best authentication mechanism is all of the above. A new set of risk management techniques, which I call "contextual authentication," promises to request the proper level of authentication depending on what the user is trying to do. Think about the ramifications. Based on your own policies you can determine for which requests a simple password is good enough and for which you require a phone authentication, a series of life questions or one-time passwords. Or all of the above.

Contextual authentication does change the user experience a bit. You may require Level 1 authentication (simple password) to access the computer and network, while requiring Level 2 authentication (one-time password or smart card) to access human resources or financial data. For sensitive applications, you may add biometrics into the mix. In the strict sense, this is not truly SSO anymore, as it means exchanging a single credential for two or three, but the trade-off results in greatly enhanced security.

Inherently this makes a lot of sense. You would probably want your bank to request stronger levels of authentication if you were trying to transfer a million dollars, rather than check a balance, no? Why wouldn't you use this method internally as well? Similar to the three bears, this allows a "just right" level of authentication depending on what the user is trying to do.

About the author
Mike Rothman is President and Principal Analyst of Atlanta-based Security Incite, an information security analyst firm. Mike has a deep background as both an information security industry analyst and a direct participant. After spearheading META Group's initial information security research, Mike founded SHYM Technology, a pioneer in the PKI software market and then held senior positions at CipherTrust and TruSecure. Mike's perspectives from being on both sides of the fence are invaluable as companies determine effective strategies to grapple with the dynamic and ever-changing security threatscape.

This was first published in May 2006

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.