SSO/RSO/USO/Oh-no.
Jun. 14th, 2004 08:25 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
doc_strangeThe 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?
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2004-06-14 09:57 am (UTC)This was sent to me in a plaintext document.
From a pop3 account.
accessed thru webmail.
Sent from the telco to an outside contractor first. To their outside email address. On an email account that didn't belong to the people you contracted to change the passwords.
Which was sent to another person at the company I'm contracting for first, not me.
The password list consisted of root and user passwords for the systems. They followed a simple pattern: names of fish.
Access to the nodes is thru telnet.
Luckily, there is a secureid system in place which generally blocks everything from the outside; to use the telnet system, you have to authorize to the secureid. Of course there do seem to be some spots where you don't have to do this.
So you may be wondering why I was changing the passwords. Well, issue #1: because the person who was assigned to do it had been taking 3 weeks to do it, and people needed the passwords to be consistent. The method used was, um, not just inefficient but... well basically it was bare bones misunderstanding of the entire security and password system. Printing out the passwords, changing them for one machine at a time, ugh ugh ugh. So anyway, 20 minutes for the majority of boxen, one system which uses a stupid java front end that cannot change passwords any other way took 1 1/2 hours.
#2. The systems weren't designed to do integrated RADIUS authentication. The customer wants RADIUS authentication for everything, so, the sales group said 'ok! until we have that integrated, we'll change them for you.' This was a case of 5 million dollars blinding the obvious - this will cost us way more than 5 million in litigation if something gets whacked. But. Boat, rock...
(no subject)
Date: 2004-06-14 12:03 pm (UTC)I feel for you, man.
(no subject)
Date: 2004-06-16 04:55 am (UTC)(no subject)
Date: 2004-06-16 08:55 am (UTC)On tokens, yes I agree - it would be far better if the Belgian token were open. I'd say more, but I guess it's just a given that one really frowns on any system that cannot be revealed since the 'secret' is in the wrong place: where it can't be changed readily. So anything else I could add would be like the preface to "intro to crypto 101."
(no subject)
Date: 2004-06-16 05:39 am (UTC)For one thing, I thought, it would prevent Paypal scam pages from being effective. Then I realised that no, it wouldn't really - it would just make the scam pages more complicated. They'd just have to be man-in-the-middling rather than simple trawling for passwords to use later. Is there any plausible way to keep men in the middle out of such things, that wouldn't be knackered by NAT? I suppose one could have the token-application software aggressively require verified certificates for the source before allowing the challenge data to be signed. (With big red letters; "NO MATTER WHAT THE WEBSITE TELLS YOU, DO NOT ACCEPT THIS CERTIFICATE UNLESS YOU ARE REALLY REALLY SURE" unless the certificate is signed by a trusted root.)
(no subject)
Date: 2004-06-16 08:42 am (UTC)They are about $200 each, but there is *no* per-seat cost on the software side (and it's a full scale LDAP + RADIUS server), which makes them close to the price of RSA tokens in small scale. I would guess they do the usual "buy a lot, get a discount" routine. I've met their CEO (who seemed to my limited crypto-sapience to be extremely knowledgeable) who told me that these things were first developed to resist active attack; the convenience/utility was almost an afterthought. Think "resistant to lighting up selective data paths with a linear accelerator" and you get the original idea. To the commercial sector, that stuff is mostly goobledie-hype. Now, it's merely a hardened off-host cryptographic processor with locked datastore, which is cool.
They architect it around a cert store, signed (verified in the fob) Java applets, and creating a verified datapath while on untrusted hosts. You can set your server-side so they won't accept traffic except pathed through the fob (since it can use ordinary RSA client certs, that's pretty easy). I'd say it's definitely an 'early' version of the tech you talk about -- much in need of improvement in speed and implementation.
MITM and untrusted host use is without a doubt one of the toughest issues IS security faces. Great, the user authenticated with handstands, faceprint, footprint, voiceprint, and the host is now using a cert derived from that and the biochip embedded in the user's eyeball... and it can still inject keystrokes once the session is up. I already use a Palm for offline SNK, S/KEY, password safe, and the like. The next step would be to turn IT into the inline crypto engine and portable keyboard, rendering the 'untrusted host' little more than a screen and ethernet card. Got VC? [grin]