doc_strange (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
doc_strange) wrote2004-06-14 08:25 am
doc_strange) wrote2004-06-14 08:25 am
SSO/RSO/USO/Oh-no.
The recurrent corporate drive to create a reduced, single, unified, etc. sign-on process is something I've been chewing on for a while. The continual rush back to passwords, to ONE password for everything, really blows me away. As an IT security professional, it strikes me as a serious backslide. I differ from many of my contemporaries in that I think even "good" passwords are (usually) a bad idea.
The only thing that's wrong with password authentication is that it uses passwords. -Me
When passwords are strong, they're hard to manage. When they're manageable, they are weak, predictable, guessable or crackable. When you make strong passwords manageable, you do one of three things: You tuck them all behind another password (e.g., password safes, certificate stores), you place them all someplace risky (e.g., wallet, keyboard tray, text file, Word doc., etc.), or you make a central authentication system of some sort that lets you use just one or a couple of passwords for everything.
I like to call that last item, "Single break-in" to emphasize the malefactor's point of view.
Let's try to define some terms:
Unified sign-on: Passwords are synchronized or authentication is centralized. Think RADIUS servers with passwords, MicroSoft domain or Active Directory authentication, Sun's NIS/NIS+, and the many password-synchronizing programs that don't require a central auth server (but require a system to coordinate your password all over the place).
Single sign-on: You log in to one device, and other items know you're logged in, because you send some special blob of data to them that proves it, and each device checks with either a central authentication system, or cryptographically validates the blob of data you send. You see this a lot with websites, using browser cookies or complex URLs to 'pass the hash,' with products like RSA Cleartrust, and with many Kerberos implementations.
Reduced sign-on: What most companies get when they try to do single sign-on. At best, systems that share common authentication are grouped by security level and purpose, so the user has a handful of authentication items that 'do it all' ranked by security. At worst, there isn't coordination; all systems that could be put on SSO are on one SSO or RSO system; the rest aren't, and bad stuff happens, like Internet-facing web interfaces take the same password as the corporate benefits and health insurance service.
Don't get me wrong. There are some benefits to be had other than 'cost savings' (which alleged value is rarely actually had in practice) and convenience. The mechanism behind single sign-on that lets the server know the user has already logged in can be more secure than the username/password mechanism the system used to use. Policy at the company may already be so broken-down that users were selecting horrible passwords all over, or leaving them in text files on their laptops, etc., so that reduction to just a few passwords may allow policy enforcement for better passwords, and stop users writing them down.
But the problem with passwords remains: From an authentication point of view, they stink. As an attorney, I think of authentication as an evidence problem: "Does what the user is providing meet the level of evidence (that we require) to 'prove' they are who they say they are." Passwords are weak as evidence: They can be stolen with no knowledge of the user, copied, intercepted, guessed. The stronger the password, and the better the mechanisms over which they travel, and the better compliance with good password policy, the better they are as evidence.
Nevertheless, on their own, passwords don't really rise above "preponderance of the evidence" (essentially, more likely than not) in terms of evidentiary value. In the effort to make them stronger, we combine them with other things, then. IP addresses, caller-ID, even digital certificates (which are used for most purposes as large passwords protected by small passwords), and just as with evidence in a trial, the more evidence that points to the same conclusion, the more likely we hold that conclusion to be. Yet, "more likely than not" on its own is not so bad: It's the standard of proof required in many kinds of civil suit, and it's the standard that (everything taken in the best light for the plaintiff or prosecutor) must be met before a case may go to trial.
So passwords -alone- are probably good enough for some purposes. Remember, however, that we are talking about RSO/SSO/USO systems: The selected authentication mechanism is going to be used for a lot, and probably some developer will accidentally extend the sign-on mechanism to a system that ought to get a higher level of authorization -- or allow authentication to it over the Internet without encryption at all.
Sensitive, business-critical, trade secret, and regulated information should probably receive something more along the lines of "clear and convincing evidence" -- something less 50/50 and more 95% -- and some items (authorizing transactions or events that will have great ramifications) may require a standard of proof all the way up to "beyond a reasonable doubt." We can achieve that higher level by using multiple factors that -- together -- rise to the level we need. So, if we know some password has 'strength' requirement, is regularly audited, and is never used outside the corporate building, even to access the company, we can have a higher level of trust in it. It could be used for more sensitive systems.
That is: The total content and circumstances of authentication must be taken into account in determining the trust level (the evidentiary value) of the authentication.
Ok, great. SO I combine passwords with other stuff, and ... I still have passwords. Lots of them, probably, because we don't want a password from a low-security system to also work on a really sensitive one. What else do we use, then? Biometrics? Ugh. Biometrics and where they are actually useful is a whole other essay. But think on it this way: If certificates are large passwords protected by small ones, biometrics are SMALL passwords we can never change. By the time we're done with the system that makes biometrics hard to fake, we've spent a ton. We've also probably made the equivalent of a 40-pound RSA token just to ensure the print/retina isn't spoofed digitally onto the wire through the user's laptop (you know, the laptop that gets a worm about every three months?). And ultimately, they're still static authentication blobs: passwords, with all the same issues. Bruce Schneier years back did a great talk on biometrics in which he wiggled his fingers and said something along the lines of "how to I change or revoke one of these? Amputation? I only have ten over the course of my lifetime." I'm guessing he didn't use retinas in the example because he didn't want to gross out the audience.
So what do we do? We combine with other security technologies that THEMSELVES embody several evidentiary items. Tokens that require PINs can be used to provide access to a secret (the token), knowledge of a secret (the PIN), and then used with the same extra factors we use with passwords. One great advantage of tokens: you can use them on both low and high security sites without lowering the evidentiary value of the authentication. Some tokens (PIN Pad, SafeWord Gold/Platinum, and others) let you type the PIN into the token, rather than send it to the server; even better.
I see the RSO/SSO/USO/Oh-no lifecycle thusly:
1) Users complain about having a ton of passwords with conflicting creation and change policies (which often ARE misguided)
2) Security admins crack down on users re-using passwords or using poorly constructed passwords
3) Users complain even more; help-desk calls go up, too
4) Management does a study, and finds that over 50% of help desk calls are about password issues
5) Management calls for SSO, arguing that it's an efficiency and cost issue
6) IT security calls for tokens
7) A vendor-affiliated (or vendor-owned) consulting firm does a study showing how much more token-based SSO/RSO will cost vs. plain password USO/SSO because of legacy system issues and per-seat costs for tokens
8) The consulting firm makes arguments about how much more "secure" passwords can be with central password policy enforcement
9) Someone says, "Isn't this just going back to Sun's YP/NIS?" but is quickly hauled out of the building
10) Millions are slated for analyst input, consultants, redundant hardware, software, licenses, and implementation
11) By the time the SSO system is up in prototype, management finds that critical legacy systems can't be integrated with it except at very high cost
12) Other authentication systems start coming in (again). If first time here, go back to 1, and start over. Otherwise, continue...
13) Eventually, wiser organizations make all new authentication based on one easy-to-use token authentication system (plain RSA keyfobs or SafeWord Silver tokens, for example).
How's YOUR authentication quagmire?
The only thing that's wrong with password authentication is that it uses passwords. -Me
When passwords are strong, they're hard to manage. When they're manageable, they are weak, predictable, guessable or crackable. When you make strong passwords manageable, you do one of three things: You tuck them all behind another password (e.g., password safes, certificate stores), you place them all someplace risky (e.g., wallet, keyboard tray, text file, Word doc., etc.), or you make a central authentication system of some sort that lets you use just one or a couple of passwords for everything.
I like to call that last item, "Single break-in" to emphasize the malefactor's point of view.
Let's try to define some terms:
Unified sign-on: Passwords are synchronized or authentication is centralized. Think RADIUS servers with passwords, MicroSoft domain or Active Directory authentication, Sun's NIS/NIS+, and the many password-synchronizing programs that don't require a central auth server (but require a system to coordinate your password all over the place).
Single sign-on: You log in to one device, and other items know you're logged in, because you send some special blob of data to them that proves it, and each device checks with either a central authentication system, or cryptographically validates the blob of data you send. You see this a lot with websites, using browser cookies or complex URLs to 'pass the hash,' with products like RSA Cleartrust, and with many Kerberos implementations.
Reduced sign-on: What most companies get when they try to do single sign-on. At best, systems that share common authentication are grouped by security level and purpose, so the user has a handful of authentication items that 'do it all' ranked by security. At worst, there isn't coordination; all systems that could be put on SSO are on one SSO or RSO system; the rest aren't, and bad stuff happens, like Internet-facing web interfaces take the same password as the corporate benefits and health insurance service.
Don't get me wrong. There are some benefits to be had other than 'cost savings' (which alleged value is rarely actually had in practice) and convenience. The mechanism behind single sign-on that lets the server know the user has already logged in can be more secure than the username/password mechanism the system used to use. Policy at the company may already be so broken-down that users were selecting horrible passwords all over, or leaving them in text files on their laptops, etc., so that reduction to just a few passwords may allow policy enforcement for better passwords, and stop users writing them down.
But the problem with passwords remains: From an authentication point of view, they stink. As an attorney, I think of authentication as an evidence problem: "Does what the user is providing meet the level of evidence (that we require) to 'prove' they are who they say they are." Passwords are weak as evidence: They can be stolen with no knowledge of the user, copied, intercepted, guessed. The stronger the password, and the better the mechanisms over which they travel, and the better compliance with good password policy, the better they are as evidence.
Nevertheless, on their own, passwords don't really rise above "preponderance of the evidence" (essentially, more likely than not) in terms of evidentiary value. In the effort to make them stronger, we combine them with other things, then. IP addresses, caller-ID, even digital certificates (which are used for most purposes as large passwords protected by small passwords), and just as with evidence in a trial, the more evidence that points to the same conclusion, the more likely we hold that conclusion to be. Yet, "more likely than not" on its own is not so bad: It's the standard of proof required in many kinds of civil suit, and it's the standard that (everything taken in the best light for the plaintiff or prosecutor) must be met before a case may go to trial.
So passwords -alone- are probably good enough for some purposes. Remember, however, that we are talking about RSO/SSO/USO systems: The selected authentication mechanism is going to be used for a lot, and probably some developer will accidentally extend the sign-on mechanism to a system that ought to get a higher level of authorization -- or allow authentication to it over the Internet without encryption at all.
Sensitive, business-critical, trade secret, and regulated information should probably receive something more along the lines of "clear and convincing evidence" -- something less 50/50 and more 95% -- and some items (authorizing transactions or events that will have great ramifications) may require a standard of proof all the way up to "beyond a reasonable doubt." We can achieve that higher level by using multiple factors that -- together -- rise to the level we need. So, if we know some password has 'strength' requirement, is regularly audited, and is never used outside the corporate building, even to access the company, we can have a higher level of trust in it. It could be used for more sensitive systems.
That is: The total content and circumstances of authentication must be taken into account in determining the trust level (the evidentiary value) of the authentication.
Ok, great. SO I combine passwords with other stuff, and ... I still have passwords. Lots of them, probably, because we don't want a password from a low-security system to also work on a really sensitive one. What else do we use, then? Biometrics? Ugh. Biometrics and where they are actually useful is a whole other essay. But think on it this way: If certificates are large passwords protected by small ones, biometrics are SMALL passwords we can never change. By the time we're done with the system that makes biometrics hard to fake, we've spent a ton. We've also probably made the equivalent of a 40-pound RSA token just to ensure the print/retina isn't spoofed digitally onto the wire through the user's laptop (you know, the laptop that gets a worm about every three months?). And ultimately, they're still static authentication blobs: passwords, with all the same issues. Bruce Schneier years back did a great talk on biometrics in which he wiggled his fingers and said something along the lines of "how to I change or revoke one of these? Amputation? I only have ten over the course of my lifetime." I'm guessing he didn't use retinas in the example because he didn't want to gross out the audience.
So what do we do? We combine with other security technologies that THEMSELVES embody several evidentiary items. Tokens that require PINs can be used to provide access to a secret (the token), knowledge of a secret (the PIN), and then used with the same extra factors we use with passwords. One great advantage of tokens: you can use them on both low and high security sites without lowering the evidentiary value of the authentication. Some tokens (PIN Pad, SafeWord Gold/Platinum, and others) let you type the PIN into the token, rather than send it to the server; even better.
I see the RSO/SSO/USO/Oh-no lifecycle thusly:
1) Users complain about having a ton of passwords with conflicting creation and change policies (which often ARE misguided)
2) Security admins crack down on users re-using passwords or using poorly constructed passwords
3) Users complain even more; help-desk calls go up, too
4) Management does a study, and finds that over 50% of help desk calls are about password issues
5) Management calls for SSO, arguing that it's an efficiency and cost issue
6) IT security calls for tokens
7) A vendor-affiliated (or vendor-owned) consulting firm does a study showing how much more token-based SSO/RSO will cost vs. plain password USO/SSO because of legacy system issues and per-seat costs for tokens
8) The consulting firm makes arguments about how much more "secure" passwords can be with central password policy enforcement
9) Someone says, "Isn't this just going back to Sun's YP/NIS?" but is quickly hauled out of the building
10) Millions are slated for analyst input, consultants, redundant hardware, software, licenses, and implementation
11) By the time the SSO system is up in prototype, management finds that critical legacy systems can't be integrated with it except at very high cost
12) Other authentication systems start coming in (again). If first time here, go back to 1, and start over. Otherwise, continue...
13) Eventually, wiser organizations make all new authentication based on one easy-to-use token authentication system (plain RSA keyfobs or SafeWord Silver tokens, for example).
How's YOUR authentication quagmire?