Can We Fix Federated Authentication? 65
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)."
Re: (Score:2)
Can't we just use Comodo?
Good one! Mod parent up, funny. (Score:1)
Problem: There's too much potential money in it (Score:5, Insightful)
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.
Re: (Score:2)
It really had nothing to do with any incoming or outgoing administration. The case against Microsoft simply wasn't that "negative" on what wasn't already settled.
Being a monopoly in and of itself isn't illegal or bad. It just requires extra regulation to monitor the the company for what is considered bad. There was a hard time showing that the actual consumers were hurt by MS being a monopoly or using it's monopoly position. Even today, that hurt is largely theoretical speculation of damages. That's what ha
Re: (Score:1)
There's a simple solution ... ditch the concept of an online identity, have an online identity for your credit card instead. Use chip+pin and card readers, and use that to log in to your bank or whatnot. That way, you've got an identity that's been validated by some trusted (as much as banks are) authority, you've got competition -- several banks, and you've got a card that people carry anyway.
This solves a few problems and sidesteps others
It avoids the self-signed certificate problem
it sidesteps the "I don
Do we really want to avoid self-signed certs? (Score:2)
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.
Then how do you trust the roots? (Score:2)
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
Re: (Score:3)
This is close to what TFA argues for.
He envisions an automated system where you hand over ability to use your various credentials to that hardware, which has its own serial number, which can be revoked to disable its access to all the credentials.
Basically his proposal is that hardware in a mobile phone responsible for keeping all your various credit cards (and other cards) safe be administered by the issuer of the "primary credit card" which is the one you use for default purchases. Being chosen as the de
Re: (Score:2)
In my experience, stuff can and will go wrong, even when it's not the user's fault.
It's just like the "ID theft" stuff. It's often not the user's fault that the Banks screw up and trust the wrong person. But the nowadays the Banks try to make the user pay it. That's why they call it "ID Theft" and not "bank fraud".
Re: (Score:2)
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.)
Keep authentication and related data in the hands of the user. Use one password everywhere. Make it changeable everywhere by changing it in one place. If a website gets hacked, no one gets your authentication info--guaranteed.
gpgAuth [gpgauth.org]
Re: (Score:2)
There needs to be national (and un for that matter) legislation stating clearly that the person owns their identification information,
and all control of how it gets released, with the exception that a few government-issued pieces of id are co-owned by the person
and the government.
Technical details can follow.
Re: (Score:2)
Ummm... isn't the point of federated authentication to avoid having one provider in charge?
I'm not really sure how your comment relates to the topic - let alone how it got +5 insightful.
Let's make a list of National ID successes (Score:1)
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
Re: (Score:2)
oops... I misread thinking this was about national IDs... still...
Re: (Score:2)
of course, you haven't made a list of the benefits, just the abuses
of course there will be abuses. but no id at all is worse than an id, with the accompanying benefits and abuses
so you are going to have to make peace with the id, because its not going away, sorry
Re: (Score:2)
Not necessarily. Imagine the bureaucratic nightmare if there is a screw-up with your ID in a world where everyone else has one. Or worse, your ID gets mixed up with someone else's and that person is less than honorable. At least now where there's a mis-mash of IDs, you have some chance of having something convincing enough to get on with your life while you straiten out the rest.
Re: (Score:2)
Incentives aren't wrong, the program is. (Score:4, Interesting)
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.
Re: (Score:2)
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.
That's why it failed for you, me, and the relatively small subset of thinking individuals who feel the same way. For most others, I think TFA's description is more accurate -- if they were ever aware of the possibility at all.
Re: (Score:3, Informative)
The above seems to be a misunderstanding of what online identity is - just a practical way to verify a user on systems that need some verification. When universities collaborate on research projects, online identity becomes a practical problem. Each institution would like to be able to accept the identities verified by other collaborating institutions. They're agreeing to trust one another, essentially. That's where federated IDs come in.
If College X recognizes the HPSD-12 ID of University Y, it can dec
Re:Incentives aren't wrong, the program is. (Score:4, Insightful)
> *I* want to be the controller of my individual identity online
The whole reason for needing an e-ID is that I do not trust *you* to identify yourself. A third party we both trust is required, or you'll just pretend to be whomever you want and I'll be left holding the bag.
Re: (Score:3)
A third party we both trust is required,...
And therein lies the crux of the problem, who is this third party that we can both trust? There are third parties that I trust in some circumstances, but none that I trust as mediators between me and everyone else. Every potential third party has interests that will put them in conflict with my interests at some point. At that point they become untrustworthy.
Actually, (Score:2)
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 y
More than one dimension to trust (Score:2)
> 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.
Nicely put. (Score:2)
Too bad everyone has to make some grand business plan out of the simplest stuff.
Re: (Score:2)
My own server should actually be more trusted because there are no third-parties in control who may have reason (bribes, malice, government warrants, etc.) to impersonate me.
But I have no idea how competently you're administering the server that provides that identity warranty. For all I know, it's been rooted by some scum from backwater Nigeria without you being aware of this. The large providers are at least more likely to try to not get hosed that way; their incentives definitely don't include getting hacked by ordinary criminals as a goal...
Re: (Score:2)
I think recent hacks supposedly out of Iran have proven that third parties aren't any more trustworthy than the end user.
Re: (Score:2)
A third party we both trust is required, or you'll just pretend to be whomever you want and I'll be left holding the bag.
I don't understand. What is wrong with asymmetric authentication? Once you matched me to my public key, you can treat every transaction with me as if I was in the room. I am so confident, in fact, in my ability to protect my identity, that I am willing to assume full damages in case my identity gets compromised. I can do that because the only realistic way to steal my identity is to punch my nose until I disclose my passphrase. And this is not a weakness of asymmetric authentication, but the limit of softwa
Re: (Score:2)
So where do I get your key from?
Re: (Score:2)
From me. Like when I show up. Give me a problematic example.
Suppose I want to open a bank account. I don't know of a way to do it without showing up in person. So I show up in person, with a photo ID, with cash or a check from my employer, and leave my PK. No one can authorize transactions but the physical person who opened the account.
Suppose I want to ID myself to DMV. I have to show up for everything there. So I show up, have my picture taken, and leave my PK. The owner of the key is guaranteed to be
Re: (Score:2)
Suppose I want to open a bank account. I don't know of a way to do it without showing up in person.
I've opened several bank accounts by mail. It's never been a problem.
Re: (Score:2)
Okay, how about Site X that you visit and enjoy (say, Slashdot? Youtube? Whatever!) implements authenticated comments only. How do they get your key to prove you're you? What about if you bought something from Asia/Europe/America - another country/region to yours - which requires it?
It's not just physical places that have this problem :)
Re: (Score:2)
I upload my public key when I register an account on /. When I post a comment, /. sends me a challenge, and I authenticate myself by solving it.
Say, you are a service provider who wants to authenticate me. If all you want is to make sure that I am the person who initiated the relationship, like in the example above, then there are no problems. If you want to authenticate me as a physical person, I have to show up SOMEWHERE. You could invite me for a chat yourself. Or you could get my public key from someo
Re: (Score:2)
So what's to stop me registering your name/username on a site you don't already use, creating a key and uploading that? It's authenticating a person, but that person's not necessarily you.
With you on the banking example, but if they're asking an agency they trust, how is that any different to a third party/middle man?
Re: (Score:2)
I'm very confused by all this. Are we talking about "Federated authentication" or "universal third-party login"? If we're talking about universal third-party login then what you say makes sense: we're arguing about who the third party is. If we're talking about federated authentication then what you say makes no sense.
OpenID or something like it is absolutely what we need. We need a system whereby I trust one or more providers who provide each one or more identities that I configure to one or more sites tha
Re: (Score:2)
When you have a device that has a thousand different vital functions, when that device fails you lose a thousand different vital functions.
This is ultimately the problem with some centralized ID system. What happens when something goes wrong with that system? In particular, what happens when that system says that some particular individual does not exist? Or that person A is not person A? How do you fix it, when there is not multiple other ID systems that you can appeal to for verification of who you are? Currently in the U.S., there are multiple ways I can authenticate my ID (although we could use a few more online authentication methods), if
Obvious solution: (Score:3, Insightful)
It's a bad idea... (Score:3)
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.
Re:It's a bad idea... (Score:4, Informative)
I'll agree with the excessive trust. Mind you, banks persuaded the plebians out there than a 4-digit PIN was secure, so I'm not terribly enthused as to their understanding of the issues.
I'm not, however, convinced of the risks. If that were wholly true, Kerberos V would not be a leading sign-on mechanism for security-conscious organizations. (Once you are assigned a kerberos ticket, you are authenticated on all machines that talk to the same Kerberos network.)
Nor would SASL2 be as significant as it is. Shibboleth (which uses SASL2 as the underlying mechanism) wouldn't be a fairly mainstream tool on Internet 2 - well, as far as you can call anything mainstream on Internet 2...!
The DoD uses a form of federated authentication in the form of smart cards that contain client-side digital certificates that act as authentication tokens on behalf of the users.
Clearly there are situations where federated authentication works and works well (most of the time).
Re: (Score:2)
I think you'll find that Shibboleth is an implementation of SAML [wikipedia.org] rather than SASL [ietf.org].
But in general I agree. I don't have 4 passwords to use on the internet, I have dozens (and have had to create two more just today). Whilst I wouldn't want all my online activity behind just one identity, any single sign-on systems that help me keep it below 100 are appreciated.
Re: (Score:2)
With a central point of trust comes a central point of weakness. Can't get around that.
But then again, trying to manage 30+ passwords is a pain. Instead of a secure password, the pain to having to login to sites reduces me to having a simple password, and not changing it.
Many times I find myself posting on a site for a few weeks, then I stop for a few years. I come back to the site, but I can't remember my username/password. Luckily I still use the same email, so I have to have my password reset.
I have to r
Digital ID Certificates from Government (Score:2)
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.
Re: (Score:3)
It would be nice if I could go down to the Secretary of State / DMV and obtain a digital ID certificate.
Until the government cancelled your ID or required it for everything you do online.
We really, really don't need government-mandated 'Internet passports'.
Re: (Score:3)
I wonder why it couldn't follow the same type of structure as a notary public... The level of trust and accountability is already in place there, and crypto allows for easier revocation than paper, so it seems like it would be an easy way to organize.
Re: (Score:3)
I studied this problem while working for a major US federal agency that would have found it very useful to have a trustable electronic ID for every US citizen a few years ago. When I studied it, I pointed out possible risks that the public might perceive in this scheme. These included the idea that the US federal government could easily link all federal records for an individual together using such an ID, the US federal government could require all transactions with the US federal government to be made un
Trust everyone (a little) or trust one (a lot)? (Score:2)
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,
What is identity? (Score:4, Interesting)
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?
Let me answer your question with a question (Score:1)
Can Slashdot turn OpenID logins back on?
Federated auth == failure of epic proportions (Score:1)
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 a
How about capabilities instead? (Score:3)
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.
Re: (Score:2)
A version of SAML (or credible general-purpose alternative to it) that works easily with RESTful services might help things along.
I have E-ID (Score:2)