Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Can We Fix Federated Authentication?

CmdrTaco posted more than 3 years ago | from the yeah-good-luck-with-that dept.

Security 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)."

cancel ×

65 comments

Sorry! There are no comments related to the filter you selected.

Can we fix it? (0)

Anonymous Coward | more than 3 years ago | (#35651546)

No, it's fucked!

Re:Can we fix it? (1)

SmurfButcher Bob (313810) | more than 3 years ago | (#35653092)

Can't we just use Comodo?

Problem: There's too much potential money in it (4, Insightful)

dkleinsc (563838) | more than 3 years ago | (#35651626)

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:Problem: There's too much potential money in it (0)

Anonymous Coward | more than 3 years ago | (#35651884)

Don't forget the potential for government intervention, and the cost of lobbying to prevent such. Examples are AT&T and Standard Oil, and Microsoft almost fell victim to this at the turn of the century, but managed to convince the incoming Bush administration to stop action.

Re:Problem: There's too much potential money in it (1)

sumdumass (711423) | more than 3 years ago | (#35659304)

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 happened. The case was strong that MS was a monopoly and used that position to it's benefit. The case was weak that the consumers were harmed significantly in that process.

Re:Problem: There's too much potential money in it (1)

Anonymous Coward | more than 3 years ago | (#35652020)

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't trust the government to create my identity" problem by trusting an institution you can fire
It sidesteps the "I lost my secure toekn, now I odn't exist" problem
It solves the "I dno't want another piece of junk I have to carry" problem
It addresses the stolen identity token (credit card + zip code in the US) problem.

It still won't protect you against compromised POS terminals, but it'll help with almost every other problem. Granted, the banks are in bed with the government, but it does fix a lot of challenges.

Re:Problem: There's too much potential money in it (-1)

Anonymous Coward | more than 3 years ago | (#35652328)

Which begs the question, does everyone who goes online have a credit card, or even a bank account?

Do we really want to avoid self-signed certs? (1)

reiisi (1211052) | more than 3 years ago | (#35652350)

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.

Re:Do we really want to avoid self-signed certs? (0)

Anonymous Coward | more than 3 years ago | (#35654320)

I will never trust a self-signed cert. What are you certifying, exactly? They help with encryption only. The only good reason I can see to use any sort of secure online ID is for financial transactions, which is the reason we need some sort of federated ID. In this case, it is the bank that's certifying the account, so yes, they are more valid a certifier than you. As a response further down objected, and I mentioned, you do have to trust the bank. I already pointed out that weakness of this approach. The "not everyone has a bank card" is not financially relevant in the western world, and in the developing world, well, I'm not doing business with you if you don't have some sort of hard cert. Benjamins work in person but not over fiber. If websites that don't get money directly from you, then this will give them an option (as opposed to government mandate) to trust some or all of the bank's signing certs. It's not perfect, but it beats any other form of authentication that I've heard of, and it, most remarkably, allows the bank to only trust hardware they issue you, instead of trusting a cell phone.

Then how do you trust the roots? (1)

reiisi (1211052) | more than 3 years ago | (#35673606)

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.

Re:Problem: There's too much potential money in it (2)

skids (119237) | more than 3 years ago | (#35653080)

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 default is worth money, so it gives incentive to banking entities to want the job of being the point of contact to deal with lost phones. In order to qualify to be the primary credit card, that bank must meet several (eventually international) government regulations designed to prevent them from using that process in an anti-competitive fashion, and to protect the consumer. The only other player that needs to be involved are the phone companies themselves, who have the power to issue a new phone ID, and might also with permission contact the bank for the customer in order download creds into the new hardware (their reason for ponying up top meet regulations is phone/service sales) at which point the bank must arrange for the re-enable (under the new phone hardware ID) of all the credentials even those of their competitors (and if they don't, they lose the privilege of being a selectable primary card.)

Re:Problem: There's too much potential money in it (1)

TheLink (130905) | more than 3 years ago | (#35653694)

The problem with such fancy "secure" systems is when stuff goes wrong the Banks et all will claim stuff can't go wrong and it's the end-user's fault.

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:Problem: There's too much potential money in it (0)

Anonymous Coward | more than 3 years ago | (#35652354)

I would like to see PayPal take a stab at it. I mean most people already trust them with their credit card and banking info.

Re:Problem: There's too much potential money in it (0)

Anonymous Coward | more than 3 years ago | (#35652394)

I think you misunderstand the nature of federated identity. Federated identity involves establishing standards for the exchange of identity information, and a trust mechanism between identity providers and service providers. I'm using the parlance associated with SAML [wikipedia.org] , but similar considerations apply to other proposed federation strategies. Point is, the all-powerful middleman you describe does not exist in such schemes. That would be like saying I control the email universe because I run an email server. Identity providers are like email servers - they are legion. Some may be large, but there is no single grand central station such as you describe.

Re:Problem: There's too much potential money in it (1)

darkpixel2k (623900) | more than 3 years ago | (#35652672)

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:Problem: There's too much potential money in it (1)

presidenteloco (659168) | more than 3 years ago | (#35656048)

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:Problem: There's too much potential money in it (1)

styrotech (136124) | more than 3 years ago | (#35657980)

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 (0)

erroneus (253617) | more than 3 years ago | (#35651636)

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.

Re:Let's make a list of National ID successes (1)

erroneus (253617) | more than 3 years ago | (#35651764)

oops... I misread thinking this was about national IDs... still...

Re:Let's make a list of National ID successes (1)

circletimessquare (444983) | more than 3 years ago | (#35651890)

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:Let's make a list of National ID successes (1)

sjames (1099) | more than 3 years ago | (#35660566)

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:Let's make a list of National ID successes (0)

Anonymous Coward | more than 3 years ago | (#35651956)

You mean something like half of the countries in this list [wikimedia.org] ?

Re:Let's make a list of National ID successes (1)

rubycodez (864176) | more than 3 years ago | (#35652022)

thank you for the list of failures. The UK entry was especially funny.

Incentives aren't wrong, the program is. (3, Interesting)

garcia (6573) | more than 3 years ago | (#35651754)

From the article:

Federated authentication has mostly failed to work because the incentives were wrong Identity providers assumed no liability and were open to traceless coercion; relying parties gained little benefit and had to cope with increased complexity; users rightly feared single points of failure.

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:Incentives aren't wrong, the program is. (1)

thePowerOfGrayskull (905905) | more than 3 years ago | (#35651786)

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:Incentives aren't wrong, the program is. (3, Informative)

Anonymous Coward | more than 3 years ago | (#35651916)

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 decide whether or not to allow University Y members into a collaboration site. That's all that's involved at a basic level, simple recognition of identity. Decisions about access levels can be made after identity is somehow established.

Rules for access may be harder than establishing identity in some cases but identity needs to be established first - the easier, the better, even for folks with college degrees.

Re:Incentives aren't wrong, the program is. (3, Insightful)

Chemisor (97276) | more than 3 years ago | (#35651928)

> *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:Incentives aren't wrong, the program is. (2)

Attila Dimedici (1036002) | more than 3 years ago | (#35652086)

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, (1)

reiisi (1211052) | more than 3 years ago | (#35652636)

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.

More than one dimension to trust (1)

ron_ivi (607351) | more than 3 years ago | (#35654064)

> 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. (1)

reiisi (1211052) | more than 3 years ago | (#35673556)

Too bad everyone has to make some grand business plan out of the simplest stuff.

Re:Incentives aren't wrong, the program is. (0)

Anonymous Coward | more than 3 years ago | (#35652154)

For the majority of uses of identity on the internet, real world identity is irrelevant. You just need to prove that you're the same person who created the account in the first place. This does not require a third-party. For example, I can run my own OpenID server and it provides the same (very few) guarantees as a third-party server. 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.

Re:Incentives aren't wrong, the program is. (1)

dkf (304284) | more than 3 years ago | (#35653300)

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:Incentives aren't wrong, the program is. (1)

garcia (6573) | more than 3 years ago | (#35652156)

I think recent hacks supposedly out of Iran have proven that third parties aren't any more trustworthy than the end user.

Re:Incentives aren't wrong, the program is. (1)

melikamp (631205) | more than 3 years ago | (#35655508)

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 software security. No software will protect you from people who are already punching you (unless it's the software inside your laser-wielding guard-bot).

Re:Incentives aren't wrong, the program is. (1)

Dogers (446369) | more than 3 years ago | (#35657560)

So where do I get your key from?

Re:Incentives aren't wrong, the program is. (1)

melikamp (631205) | more than 3 years ago | (#35660484)

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 the person on the photo.

Re:Incentives aren't wrong, the program is. (1)

Rudolf (43885) | more than 3 years ago | (#35662308)

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:Incentives aren't wrong, the program is. (1)

Dogers (446369) | more than 3 years ago | (#35668500)

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:Incentives aren't wrong, the program is. (1)

melikamp (631205) | more than 3 years ago | (#35668704)

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 someone you trust, who invited me for a chat in the past. A bank in Australia may contact an agency it trusts in US and verify that a given PK corresponds to a physical person with a given name and a given photo. How is that worse than what we have now? With asymmetric authentication, it is entirely possible but never necessary to use a middle man.

Re:Incentives aren't wrong, the program is. (1)

Dogers (446369) | more than 3 years ago | (#35670914)

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:Incentives aren't wrong, the program is. (1)

Rysc (136391) | more than 3 years ago | (#35654710)

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 that I choose. Each site needs only to rely on authenticity and not identification. If the government wants to set up some kind of identification protocol which can be used to verify that a given Open ID identity corresponds to a given other identity (e.g., to a given citizen) then that's a reasonable service they can opt to provide. For most purposes the mere fact that the site can verify that the identity is authorized is more than sufficient.

Authentication matters, identification does not. As long as I can prove that I'm the same identity each time I don't need to prove who that is and that goes for financial transactions of all kinds.

Skimmed it (0)

Anonymous Coward | more than 3 years ago | (#35651854)

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.

Re:Skimmed it (1)

Attila Dimedici (1036002) | more than 3 years ago | (#35652184)

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 one of them becomes corrupted, I can use one or more of the others to prove who I am and get the one that is wrong corrected.

Obvious solution: (3, Insightful)

SethThresher (1958152) | more than 3 years ago | (#35651994)

Lets just use facebook connect and call it a day!

It's a bad idea... (2)

Chanc_Gorkon (94133) | more than 3 years ago | (#35652218)

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... (3, Informative)

jd (1658) | more than 3 years ago | (#35653922)

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:It's a bad idea... (1)

PybusJ (30549) | more than 3 years ago | (#35655080)

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:It's a bad idea... (1)

Bengie (1121981) | more than 3 years ago | (#35654362)

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 request a password reset about once per week on average to different sites.

Re:It's a bad idea... (0)

Anonymous Coward | more than 3 years ago | (#35658746)

For me it's not even just the number of sites. It's that for some sites I may not be back for a year, maybe more. It's stupid to have to manage an additional password for something like that.

Digital ID Certificates from Government (1)

nharmon (97591) | more than 3 years ago | (#35652340)

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:Digital ID Certificates from Government (2)

0123456 (636235) | more than 3 years ago | (#35652762)

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:Digital ID Certificates from Government (0)

Anonymous Coward | more than 3 years ago | (#35652780)

Agreed..... and get them from the bank for use as banking IDs, and from other places for use in other circumstances.

Re:Digital ID Certificates from Government (2)

mortonda (5175) | more than 3 years ago | (#35652966)

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:Digital ID Certificates from Government (2)

anegg (1390659) | more than 3 years ago | (#35653182)

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 under this ID, and so on. In other words, it would be a key aspect of putting together a surveillance state. I didn't think (then) that most people would go for it.

Things may have changed, now... if enough people in the US are fed up with having separate identities and credentials for each on-line service they use, either socially or for business, they might be willing to let the US federal government take on the role of proofing identity. US citizens already accept that role with the standard state-issued government ID (a driver's license) and the standard federally-issued ID (the passport) that is required for virtually all significant identity-proofing transactions. Would they accept it for electronic transactions as well?

Of course, the difference with the current system is that the records of using the identity-proofing service (showing a driver's license or passport) are only in the hands of the people to whom we prove our identity. Under an electronic system, unless it is designed to preclude centralized logging, the US federal government would have a record of every time the ID was used. Yikes?

Trust everyone (a little) or trust one (a lot)? (1)

anegg (1390659) | more than 3 years ago | (#35653052)

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?

What is identity? (3, Interesting)

anegg (1390659) | more than 3 years ago | (#35653388)

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 (1)

Anonymous Coward | more than 3 years ago | (#35653798)

Can Slashdot turn OpenID logins back on?

Federated auth == failure of epic proportions (1)

WaffleMonster (969671) | more than 3 years ago | (#35653878)

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.

Capabilities instead of usernames and passwords (0)

Anonymous Coward | more than 3 years ago | (#35654048)

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.

How about capabilities instead? (2)

ka9dgx (72702) | more than 3 years ago | (#35654288)

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:How about capabilities instead? (1)

presidenteloco (659168) | more than 3 years ago | (#35656120)

A version of SAML (or credible general-purpose alternative to it) that works easily with RESTful services might help things along.

Short answer? (0)

Anonymous Coward | more than 3 years ago | (#35656998)

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.

I have E-ID (1)

spectrokid (660550) | more than 3 years ago | (#35657694)

Live in Denmark and signed up for it. Government keeps both public and private key, I identify [nemid.nu] 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.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>