We’re pushing the notion that sites should do “Federated Identity”; that those “Sign in with Facebook/Google/Twitter/whoever” badges you see everywhere are A Good Thing. And indeed they are. But it’s exposing a subtle problem.
Background · I spend a lot of time talking to people who are (in the jargon) “RPs”, where the initials stand for “Relying Party” and mean someone who relies on an Identity Provider (“IDP” in the jargon) to take care of login/logout.
It’s increasingly easy to set up Federated Login with an IDP, and as OpenID Connect stabilizes, there’ll be room for a real standards-based RP/IDP ecosystem. OpenID Connect is easy to implement for an RP; I know this because I’ve done it.
So What’s the Problem? · One thing I hear over and over, when I’m talking to RPs, is “How do I force re-authentication?” A bit of background is in order. The way being an RP works is that you do a browser redirect over to the IDP, in effect asking “Is this the person they say they are?” If you do this with Facebook or Google or whoever, and if the person is already logged in via that browser, most times the IDP will just come back and say “Yep, they’re authenticated” without pestering the user.
But some RPs want to make the IDP re-authenticate, that is to say make the person at the browser type in a password and maybe do the 2-factor thing too. Because they’re about to do something really meaningful, involving money or privacy or whatever. For example, I was recently talking to some people from a well-known newspaper that wanted to force re-auth when their journalists accessed the internal publishing system from outside the firewall.
Why Is That a Problem? · Well, one of the key advantages Federated Identity is cutting down the number of times people have to type in passwords. There are a bunch of good reasons for this:
Every time it happens, that’s another chance for password theft.
We don’t want to get people into the habit of typing IDP passwords in here and there; that habit is a great big red target sign saying “Phish me!”
Typing passwords all the time is a painful user experience, particularly on mobile devices.
The easiest way to reduce that pain is to use a short, simple, password, probably the same one you’re using everywhere including on your easily-hacked kid’s-Little-League site.
So yeah, I suppose the RP might be (slightly) increasing the security locally by forcing re-auth in some situation or another. But they’re globally reducing the security of the whole password ecosystem.
What To Do? · Well, an IDP can just say “No, you can’t do that.” But that doesn’t really make me happy either. If you’re providing a service, and someone using it says “I want to do X”, and you find yourself about to say “But you shouldn’t want to do X” for any value of X, you should be nervous.
And then there’s the elephant in the room: Policy and Regulation. Quite possibly it’s not the people running the RP system, it’s the lawyers saying “Let’s be safe and make them re-authenticate.” Because how could it be wrong to be more careful?
And worse, maybe it’s the lawyers saying “The law says we have to force re-authentication.” Because when your lawyer says that, the argument is usually pretty well over.
When I hear about this happening, more than once the law in question has been HIPAA. But it’s not alone. It’s really easy to pass a law forcing people to prove who they are when they undertake certain transactions. Because how could it be wrong to be more careful?
Arrgh.
Contributions
Comment feed for ongoing:
From: John Cowan (Mar 06 2013, at 14:44)
I note that despite Google's comprehensive internal single-signon system, you are still forced to sign on a second time when you get near anything payroll- or HR-related. That's a Good Thing, despite the extra password exposure. He who has my device is not necessarily me.
[link]
From: Ivan Sagalaev (Mar 06 2013, at 15:08)
A few years ago I spent a fair amount of time explaining to an online store that "they can't do that and shouldn't want to". Didn't work very well :-)
Now I think there's one solution IDPs could offer for RPs: implement additional security (snakeoil) on their side. This would keep the lawyers happy and it doesn't make an IDP look completely useless. But importantly it would shift the responsibility for being stupid from and IDP to an RP. Then it's for the users to vote with their feet and favour those RPs who don't make them do this dance.
[link]
From: Bud Gibson (Mar 06 2013, at 15:11)
You sort of wonder if you couldn't tie the authentication request to some sort of encrypted challenge/response on a personal device. That would be less insecure than passwords. Device authority could be revoked if lost or stolen.
The whole point here is trying to come up with a challenge/response that is lower risk than passwords and likely more convenient. Just a fast thought.
[link]
From: Boyd Stephen Smith Jr. (Mar 06 2013, at 15:14)
This is just wrong:
'If you’re providing a service, and someone using it says “I want to do X”, and you find yourself about to say “But you shouldn’t want to do X” for any value of X, you should be nervous.'
Time and time again customers/consumers, both individuals and groups, have shown that they usually don't know what they want and often they ask for things they don't want.
Yes, you shouldn't be completely dismissive, but that doesn't mean every request is implemented, even in a refined form. You *should* engage, but often the solution is something entirely different.
[link]
From: Anonymous Coward (Mar 06 2013, at 15:21)
The downside to signing in with Facebook (Twitter, etc.) is that it connects two accounts that I don't want connected: I don't trust Facebook (or Twitter) with the information that I have an account on some other site. Will it show up in my Facebook feed? "AC just signed up for Joe's Sleazy Porn Site! Click here to sign up too!"
[link]
From: Z (Mar 06 2013, at 16:28)
Denying re-auth may make the system more secure from random outside attackers, but it opens up a big security hole to anyone who has access to your computer. Your friend posting something funny on your Facebook wall. Your kid unknowingly buys $1000 of in-game bling from a "free" game. Your sketchy college roommate buys stuff online under your name. The first isn't a big deal, but the last certainly is. If you don't give sites a way to prevent headaches like that, they're not going to switch away from their own authentication, and then we're really not getting anywhere.
[link]
From: Brian Sniffen (Mar 06 2013, at 18:28)
Sounds like what many of these RPs really want is a chance to force a ceremonial interaction. They don't care about a password, as such, so much as that some auth token was involved. They'd probably be just as happy with a separate knowledge based reauth system, and much happier with a one time password---especially since that could involve transactional authentication as well. Google's in a great position with its ubiquitous authenticators to offer RPs a choice of reauth scenarios: OTP, OTP plus retype price, OTP plus order number, but never the long-lasting password.
[link]
From: Chris Adams (Mar 07 2013, at 05:52)
Having worked with a similar system (CAS) I think re-auth is less tragic because it's still compatible with “Only enter your password on pages with the SSL lock and this name” training. Not great but a big win versus where we're at now.
The real win, however, would appear to be allowing it only for two-factor codes, which would both reduce the capture / fishing risk and provide additional impetus to adopt a significant improvement rather than subsidizing large organizations’ mispolicies. Having worked in an environment where RSA tokens were ubiquitous this is usually a surprisingly big win: not only do you avoid a host of password issues but a 6-digit code is much easier to enter, particularly on mobile devices, which takes most of the sting out of entering it any time you do something sensitive.
[link]
From: Stephen Bounds (Mar 07 2013, at 12:44)
I can see both sides here. Personally I like the idea that rather than forcing re-authentication *pre*-change, users are assured that they will be notified *post* any changes.
This has the same net effect since the lack of any notifications gives users confidence that they have, in fact, not had any unauthorised activity.
And for more sensitive transactions, just take the banks approach of authorising by sending a code via text message to your phone. Going outside the ecosystem altogether...
[link]
From: James Manger (Mar 12 2013, at 16:17)
A good solution would be for an RP to be able to indicate to the IdP how important a specific sign-in is. The IdP can then judge whether or not to, say, re-prompt for a password. the IdP can consider the RP’s input as well as user preferences and the IdPs own info (eg how recently it authenticated this user).
Indicating importance on a scale from -100 to 100 should work well. -100 means its unimportant (eg will only be used to say "Hi Tim" at the top of a page) so an IdP should avoid hassling the user if possible. +100 means absolutely crucial (eg authorizing release of nuclear weapons) so the IdP should re-authenticate the user (or even reject the request if the IdP is not suitable for that level of importance). 0 is the default.
RPs, IdPs, and users (and courts?) should be able to holistically converge on suitable importance levels for typical use cases and appropriate IdP responses -- and this can drift over time as technology and threats change.
[link]
From: Corneil du Plessis (Mar 31 2013, at 03:30)
The specs should probably allow for multiple levels of authorization and when the RP requests a high level the provider will know to ask for password again or some other factor like hardware token or One Time Password. The RP should should provide a summary of the action so that the user knows the reason for the extra auth.
Each provider will have specific mechanism to deal with requested auth level.
I would suggest a low, medium and high.
Low will be like current with no reauth. Medium may require a re-auth within specific time and high could invoke hardware token or OTP.
[link]