Slashdot Mirror
Can We Fix Federated Authentication?
Bruce Schneier writes in his blog of a "New paper by Ross Anderson: 'Can We Fix the Security Economics of Federated Authentication?': There has been much academic discussion of federated authentication, and quite some political maneuvering about 'e-ID.' The grand vision, which has been around for years in various forms but was recently articulated in the US National Strategy for Trustworthy Identities in Cyberspace (NSTIC)."
No, it's fucked!
The basic problem is that a lot of people look at the possibility of being the go-to Internet identity service as being a huge money raiser. There are big network effects - you need a critical mass of websites so that anyone who wanted to do anything online would have to sign up for your service, and a critical mass of users so that any website that wanted to be quick and convenient would have to sign up for your service.
But once that critical mass was achieved, that's when the big fun begins, because you now as the established middleman have 4 potential sources of revenue:
1. Fees from each website that wants to use your service to verify identity.
2. Fees from each user that wants to use your service to identify themselves.
3. The sale of user's personal data to advertisers. (In the "achieving critical mass" phase, of course, they'll put in a privacy policy that says that they won't do this, but once they have enough users to dominate they'll quietly change the policy.)
4. Advertising on the website that you use to sign up.
And because you're the tool everybody is using, every new user or website pretty much has to use your service or risk being out in the cold.
A lot of companies have tried to get themselves in this position: Microsoft took a stab at it, Facebook and Twitter are still pushing for it, etc etc.
I am officially gone from
1. ...
Yeah, can't think of any. I know there have been attempts by lots of countries out there and none of them worked out for whatever reasons. What makes the US government think they can be successful on the very large scale we are talking about? The [ab]use of the social security number was predicted accurately before the social security program was put into place and despite attempts at legislative remedies, it's still a big problem. Any such other program is likely to face similar problems as it is a system that trusts its data systems to tokens instead of people.
From the article:
No, it has mostly failed not because of lack of incentive but simply because *I* want to be the controller of my individual identity online--not some third-party or government sponsored gatekeeper.
We do NOT need this and I wish we'd stop wasting time, money, and effort on something that will always fail. Even if it is adopted it will have been an enormous waste being that those problems it's meant to solve will be circumvented by those who do not want it solved.
Found it interesting, but it became more a paper on how having everything (credit cards/licenses/discount cards/etc) on your phone would work out then really covering the idea of the difficulties of an all encompassing ID. Of course, if one device has all that crap and can do a dozen different things due to a dozen different apps on it, doesn't that make it an all in one ID?
Although...I suppose some of the problems that occur in making a phone a "mobile wallet," as he put it, do transfer over to having a single all-in-one ID. And he does flirt with the idea of the mobile device also being the all in one ID, going over the positives and negatives as well as some potential security features.
Also I may be kind of misreading it, but I think he's favoring the all-in-one mobile wallet because he thinks private companies would be able to revoke said mobile wallet with far more haste (due to potential lost profits from fraud) than the public sector. That's, uh, true I guess, but I'd rather not put my SSN or other things in the hands of a for-profit company due to potential shady dealings. Or what happens if one company effs up and revokes your phone's privileges completely, preventing you from using *any* of the phone based IDs? And if you'd need to individually call each company anyhow, there's no point to putting it all on one device other than making it easier to steal?
When you have a device that has a thousand different vital functions, when that device fails you lose a thousand different vital functions. But if you have a thousand different devices each doing a thousand different things, you have less potential for everything to fail in exchange for much less ease of use. Personally I prefer the second, but that's because I'm...sort of a Luddite. Sometimes things being a little bit harder is better in the end.
Lets just use facebook connect and call it a day!
The problem with these such systems is that people begin to trust them far before they should. I am NOT a fan of single signons for ANYTHING. Yeah it's a pain to know 4 different passwords, but if one of these federated providers is compromised, then EVERY company who uses them is ALSO compromised.
Gorkman
It would be nice if I could go down to the Secretary of State / DMV and obtain a digital ID certificate. I'd even pay a fee for this and it would cost the government very little to provide this service.
I mean, ultimately, the only person who knows an individual's identity is the individual him- or herself.
Thus, the only entity truly capable of certifying an identity is the self.
That's the first thing that's wrong with all of our current attempts at identity and authorization. Or, if you think about it, the closest we are to correct at this stage is the confirm-by-e-mail trick.
Universal login, federated authentication, whatever you want to call it, it's just plain wrong.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
By rules of logic, you can only trust second parties.
That means that third party identification is inherently not valid logic.
To put that in ordinary language:
I barely trust myself.
I can sort of trust people I know, only to the extent I know them.
Trust here does not mean I believe they will do what I think is right, it means I think I know how they will behave.
The kind of blanket trust where you believe someone will always do what you think is right is fool's trust. Not even God is always going to do what you think is right, because God (if he exists) is a lot smarter than you.
Governments are not God. Police are not God. Corporations are not God, no matter how much our bosses think they want us to think so.
No mortal person or entity can assume that level of trust.
There is no sense, absolutely no sense in which a third party can be a medium of transitive trust.
Yeah, that means that Verisign is one major scam. All those certificates in your browser are meaningless, except for the vendors, because you sort-of know the vendor.
Your identity at Google consists of your record of transactions at Google, and nowhere else. Likewise, Yahoo. Likewise Apple or Microsoft.
When Google bought youtube, they watered down the meaning of your identity a bit, but they can connect the records to somewhat counter the diluting effects. Iff the connection activities are pursued correctly. But they can't connect records owned by another organization because those records are established and kept in a different context.
I've got to go to bed, so the rant ends here, but we are definitely working at authentication backwards and upside down.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Do we trust no one by trusting everyone just a little, or do we trust just one?
Unless individuals can be counted upon to safely and securely hold on to the private half of a public key pair, any federated identity proofing service will have the ability to masquerade as any of the individuals for whom they prove identity, I think. (Please clarify my thinking if I'm wrong.)
If a federated identity proofing service can masquerade as me, I've got to trust that they (and all of their employees) won't do this, no matter what the enticement.
I take the risk, now, that my brokerage firm won't pretend to be me and make trades in my account. I take the risk, now, that my bank won't disburse money from my account and claim that I did it. I take the risk, now, that any other firm with whom I do business under the guise of an identity proofed by them that they won't enact transactions on my behalf and claim that I did it.
Am I willing to take those same risks, in a federated identity world, all in the hands of a single identity proofing service provider?
Authentication can be defined as the process of proving an identity. One question to ask is what identity is being proven? Does the concept of identity even have meaning outside of a relationship between two parties?
We like to believe that we each are ourselves, which is our sense of identity. But who are we, anyway? We could define our identity as being the child of our (presumably two) parents - but this just pushes the problem off one generation - what is the identity of our parents? This could be taken back as far as necessary to establish an identity chain that would make it unlikely to find conflicts. We can also define our identity as being the individual born in a certain location at a certain date/time, and we feel this is probably unique because it is unlikely that there were more than one individual born at the same date/time in the same location (assuming the location is localized enough). But are these identities really meaningful? Are they what is really necessary?
In most circumstances, its not who you are that is important, but your relationship with another party that matters. For example, my college didn't necessarily care who I was while I was in attendance there, but rather that the person who took all of the courses and exams, building up an academic record, was the same person to whom they granted a degree upon my satisfactory completion of a particular course of study. In some sense, the US IRS doesn't care who you are (the child of Julius and Ethel, for example) but rather that the single individual who made income from a set of income sources paid the taxes that they owe based on current tax law for that income. And the US Social Security system cares mostly that the individual who paid a certain amount on Social Security fees over their lifetime for income earned is the same person to whom they are cutting a Social Security check in retirement. And so on...
Is it really meaningful to seek a single ID and authentication of that ID for use with numerous parties, who are really only interested in establishing your relationship to a particular credit account, or taxpayer ID, or student it? What risks might be involved in constructing such a singularly important ID?
Can Slashdot turn OpenID logins back on?
In the jumble of protocols and methods being deployed we loose sight of what really matters in a secure system. "TRUST". Just follow the sources of trust in the system, how it is obtained and managed.. then you will easily be able to understand the *best case* security of the system.
The system of CAs we have today is broken beyond repair. The financial incentives just make things worse as time and value of circumventing the system steadily increases to infinity.
TFA is correct in saying Visa 3DS is a sad and dangerous idea.. I go to an online web site and they ask me not just for my credit card number but to enter my fricking account password... with no way for me to know where my password is going. Did I just give the web site access to my bank account? Do I have to worry about them logging in to my home banking portal and clearing my account? How do I know?
Federated authentication on the Internet is bad because credentials are really the only reasonable method we have to establish trust.
If you use federated auth you can't bind session encryption to authentication for web or other transactions without pushing trust out to the authentication provider. At this point you've essentially made the authentication provider the CA and solved zero problems of any kind.
As TFA mentioned all aggregation of trust does is paint a huge target various TLAs around the world and hackers alike will eventually flock to and have their way with.
The only solution I know of that stands a chance of working is to push the problem of establishing trust out to each site and let them choose the best way to do it... If I run a bank let me require people to come in to my bank show a photo id..etc to establish a password.
Once your password is established you don't need no fricking house of cards SSL CA infustructure or pay yearly fees to have your CSRs signed.
All you need is a secure authentication protocol such as TLS-SRP which will not only provide mutual authentication but also provide necessary keying to encrypt the session. Problem solved.
Instead of trying to get one password to rule them all, why not go with the approach that has worked for thousands of years? It's capability based security, but you're likely not heard that term used in the context before.
When you owe someone 20 bucks, you hand them a token that is worth $20, a single "Yuppy food coupon". (Jackson would rise from his grave and shoot fire and brimstone at the person who put is portrait on a BANK note, but I digress). The most you can lose is the amount handed over. It's a capability token. If you want to revoke the capability, you ask for it back before the transaction is complete. After the transaction, you can get a refund, and get a different, but equal, capability token.
The credit card model on the other hand has you handing your entire credit capability to the merchant. If you want to revoke it, you're out of luck in terms of a single transaction, you have to TRUST the merchant, and all of their employees, from that point forward. You also have to trust all of the other merchants and their staff as well, accumulating a large pool of people and computers, until the token expires or is revoked. Revoking the capability usually entails a few days of outage as well.
Any federated identity is going to involve a similar ever growing pool of people and machines you have to trust, with the subsequent amount of grief when the identity capability has to be revoked.
Isn't it better to have a single point of trust which can issue individually revocable capability tokens? If the phone is to be the control point for this, that's fine... it doesn't have to actually own the service, it just has to be an access panel for an honestly secure service hosted elsewhere.
We need to stop thinking in terms of identity when considering permissions, and start shifting to one of capabilities instead.
Gosh, I've rambled... I hope it makes sense.
> I can sort of trust people I know, only to the extent I know them.
I trust Google and Facebook to collect and mine all data that's given to them and provide a nice internet experience, but not to protect my money or anonymity.
I trust my bank to keep my money safer than I could keep it my self -- but not to watch which porn sites i visit.
I trust Tor to help protect my anonymity - but not to keep my money safe.
You can't have a single organization that I'd trust to do all three.
Instead of trying to get one identity to rule them all, why not go with the approach that has worked for thousands of years? It's capability based security, but you're likely not heard that term used in the context before.
In the past, if you owed someone $19.95, you would hand a $20 bill, and wait for change. In this type of transaction, the most you can lose is the amount you pay. In this case, an $20 bill is a capability token.
Sometimes you want to stop or reverse a transaction. To do this, you need to revoke a capability. With cash, you can simply get your money back. Once this is done, there are no trust issues after the fact. It's nice and simple.
The credit card model on the other hand has you handing your entire credit capability to the merchant. If you want to revoke it, you're out of luck in terms of a single transaction, you have to TRUST the merchant, and all of their employees, from that point forward to do the right thing. You also have to trust all of the other merchants and their staff as well, accumulating a large pool of people and computers, until the token expires or is revoked. Revoking the capability usually entails a few days of outage as well.
With computers and the internet, a username/password system really doesn't prove identity, but it is a bit more secure in that you can have many different capabilities instead of a single concentrated pool of mis-trust. (Assuming of course you don't use the same username - password pair in more than one place) Revoking an capability in this case involves different procedures for each and every one, there isn't much uniformity to the process.
OpenID was a good idea in that it let you get away from handing over everything, and got us started on the road to capabilities, but it doesn't go far enough in that direction.
Most other approaches to federated identity involve a similar ever growing pool of people and machines you have to trust, with the subsequent amount of grief when the identity capability has to be revoked. When viewed from the capabilities perspective, this isn't desirable.
Isn't it better to issue individually revocable capability tokens? There's no reason not to have the phone talk to the actual service that does the work. The private keys, etc... should never be carried around on one's person, nor stored in a system used for other things on the internet.
In summary:
We need to stop thinking in terms of identity when considering permissions, and start shifting to one of capabilities instead.
No. We can't solve it.
The problem with his proposed solution is that the entities he's proposing to have solve the problem because it's in their economic interest have always been the last to act to solve cyber-security issues because they fail to understand the space and want to pretend that they're living in the past. ATM pins are a sham. Credit card validation still does not exist--I've used the "verified by VISA" feature maybe one time. Banks know what nobody else seems to get: They're only loosing money, and they can pass that loss along in the form of higher fees. Done. Their risk is mitigated.
That's an entirely different risk profile than loosing my company's intellectual property or allowing a terrorist to enter the country on a fake identity.
Different risk profiles require different solutions. There will never be a single identify provider for that reason, nor should there be.
Why do we need single-sign-on anyway? Convenience isn't worth the risk of having all your credentials across the board blown at the same time.
Live in Denmark and signed up for it. Government keeps both public and private key, I identify myself with a one time pad. Electronic gizmos are promised for Really Soon Now. Use it for my bank account, contacting government and municipality, and signing emails (there is a plugin for thunderbird). It is more secure than a password as it adds "something you have", and I can use it on a library computer without too much worry, a keylogger won't hurt me, you need very fancy man-in-the-middle shit. Of course I have no illusions about using it for hiding from big brother. In the end it saves me from a lot of hassle as I can do Official Paperwork stuff like tax forms over the internetz. It also saves me a lot of stamps, as more and more people accept the digital signature.
10 ?"Hello World" life was simple then
http://news.cnet.com/8301-27080_3-20048831-245.html
"I can't imagine how things could get any worse!" (some guy) "That could just be failure of imaginatioÂn on your p
Too bad everyone has to make some grand business plan out of the simplest stuff.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Or has that changed?
I think the roots have to be self-signed. That's the way it was the last time I checked, and the time before that, as well.
The real solution is to for your bank to have its own browser, self-sign its certificates, and give you the public keys when you go in to get money or something. Nothing works over fiber at all until you've been there in person.
There's a bit more to it than that, but we shouldn't need one certificate to rule all our banks, even, much less one certificate to rule all certificates.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.