Part of my job these days is convincing people to get out of the password business and start “Federating”; that is to say, outsource the login mechanics to an “Identity Provider” (IDP) like Facebook or Google or Microsoft or Twitter (and there are lots more). I’ve given the sales pitch quite a few times now; here it is.
Scenario · You’re putting up a new app and need to sign in users, so you use whatever’s popular with the package you’re using: On Rails, typically Devise, on NodeJS Drywall or Passport, on PHP Usercake, and so on.
These things will take care of storing and checking usernames and passwords for you. But storing and checking passwords is a bad thing to do.
Why? · There are too many passwords. When someone rolls up to your app for the first time and you ask him or her to pick a password, here are some typical reactions:
She says “Oh, not another damn password” and closes the browser tab. Kiss a customer goodbye. This is a very common reaction and if you’re Mr Yet-another-password, it’s happening to you right now.
Oh, and if she’s on a mobile device, the chances that she’ll be willing to put up with Password Pain are dramatically reduced.
He picks a short, simple, easy-to-remember password, thereby making life easier for the bad guys.
She uses a complex high-quality password, and doesn’t have to actually pick it because it’s the same one she uses on all the sites she visits, including dog-grooming tips and money management. Thereby making life easier for the bad guys.
He types some random gibberish into the password field and doesn’t bother to remember it; the site will keep the session active for a few days, and when it asks him to log in again, he’ll hit “Forgot password” and get a password-reset email. Beats trying to remember. (This is the best outcome so far).
She uses a password manager like 1Password or LastPass or KeePass. It works pretty well for her — well, maybe a little awkward on mobile devices. But she’s had no luck at all getting her nontechnical friends and family to use it.
Which is to say, by playing the yet-another-password game, you’re decreasing the security of the whole Internet. You’re peeing in the swimming pool. It’s bad for your business, and Google’s business, and for the people using the Internet. So stop doing it.
That should be enough.
Not Convinced? · You still think you might want to do the password thing... so, you better make sure people pick good passwords. For an example, type “password rules” into Google and up comes Intel Password Rules, from which I could quote but let’s just screenshot instead.
When you impose something like this on human beings, you’re being mean to them. Which is not only evil, and bad for business, it just doesn’t work. So stop doing it.
Still Not Convinced? · Maybe these will help.
· · ·
· · ·
· · ·
Are you smarter than those guys; the BBC, DropBox, LinkedIn, and so on? Are you sure? This could be you, very easily. The bad guys are out there, and they are probing your defenses every day. So once again: Get out of the password business, start federating, and don’t let this be you.
It’s That Easy? · Um, well, no. There are issues around federation: business, technology, and policy. I’ll write some follow-ups about them. The cost and effort is non-zero. But it’s something you’re going to have to do anyhow, so you might as well get started.
Comment feed for ongoing:
From: Pedro Oblamar (Aug 01 2013, at 03:12)
I disagree.
As a website user, I think all of these inconveniences are outweighed by the benefits of not centralising and outsourcing your identity, both of which make me very uncomfortable.
When I see a 'sign in with facebook', 'sign in with google' button I *never* click on it, even if I have accounts with those sites. I am never sure what the implications of signing in through a third party are: will this website show up on my facebook 'profile'? Will my presence on this website link to my facebook account?
I realise I could set up my own identity provider, or set up a new one per website, but that seems like too much trouble.
I am not posting this under my real name ;)
[link]
From: Dave Pawson (Aug 01 2013, at 04:26)
Equally when a site asks 'give me your Google/FB/twitter name/pwd' I close the tab
No way I'm handing over passwords to a third party for them to lose / use.
[link]
From: Antonio (Aug 01 2013, at 05:22)
Say I'm sold and want to implement federated Google + Twitter + Facebook login on my (for example, Python) app. What would be the way to go? Do you recommend using the specific OAuth2 libraries provided by each party, or are there any tools/service I can trust out there that make my life easier?
[link]
From: Dewald Reynecke (Aug 01 2013, at 05:51)
That is all good and well in concept, but I don't trust Facebook/Google as far as I can throw them – I simply do not want to outsource my identity to an advertising company.
We need a nerd-friendly alternative. I think OpenID is/was on the right path but it's not implemented widely. It's a chicken-egg problem I suppose.
[link]
From: Gavin B (Aug 01 2013, at 05:52)
Federate using FB,G+,Tw ?
Guess what they all bow to the USA/NSA -
And I thought you were smart Tim.
[link]
From: Jesus Cea (Aug 01 2013, at 06:10)
Guys, check out Mozilla's Persona effort.
[link]
From: brejoc (Aug 01 2013, at 06:19)
Right after Prism and Tempora this is a very bold statement. And don't tell me you've got nothing to hide. This is an easy way to compromise my perfectly safe web service by giving user credentials to secret services. And it's not just about espionage on individuals, but also industrial espionage.
[link]
From: Martin (Aug 01 2013, at 06:34)
I listen to a nice talk about Mozilla Persona, http://www.mozilla.org/en-US/persona/. The best argument for it is then "Which federation you should use?" and the privacy argument: FB and Google tracks the hell out of you.
What do you think about Persona?
[link]
From: Ed (Aug 01 2013, at 07:00)
I share many of the other commenters concerns. It's not clear to me what the implications of using federated authentication are. When I sign in with google or facebook, how much of what I'm doing on site-x is visible to the auth provider? I have a hunch this can all be setup so the authentication and only the authentication is outsourced, but few people really understand. It's confused further by the few times I've actually used federated sign in it was to grant some add-on service access to my data.
A post that clarified all this to me would be eagerly read.
[link]
From: John Cowan (Aug 01 2013, at 07:12)
I belong to class 3, although I use a different complex password for my bank. However, my default password is not difficult enough for some sites, though it involves two unusual proper names and a digit. On a site where I need to change my password every n days, I vary the digit; when I need to add a punctuation mark, I put it at the end and use an unshifted one. In these cases I use an awkward command-line tool that I wrote myself, protected by its extreme obscurity.
All of this is trivial. Real irritants: Sites for which my password is too *long*. Sites which accept a long password but truncate it when I type it in, making login impossible. Sites which let me log in through Google but then want me to create a password anyhow.
Pedro: Google, at least, will tell you what facts it is sharing with the other site. The site can ask for anything from basic name and email information right up to the ability to manipulate your whole Google+ world, and you can say yes or no. (Unfortunately, there is no way to allow only certain features it asks for and not others.)
Dave: In particular, Google never shares your actual password.
Gavin et al.: The fact is that if the Agency (any Agency) wants to learn anything about you, they can and will. Even if they don't want to learn about *you*, they can and will as a matter of automatic sweep-up efforts.
For secrecy, 18th-century advice is still best. Meet face-to-face with someone you know well in an open field where you can see anyone coming near you a quarter of a mile away. Preferably just after dawn: most folks aren't up that late. Since the invention of the laser microphone, all buildings (with windows, at least) are compromised.
And as for securing your computer, the best approach is to disconnect all wires, shut off all wireless devices, drop the thing down a dry well, and fill the well with concrete. In a day or two, your computer will be fully secure.
[link]
From: Chris Carter (Aug 01 2013, at 08:19)
When you use a 3rd party IDP like that you are giving them information about the behavior of your users - which they are free to sell to anyone, even your competitors. Using 3rd party IDPs is not always in your best interest.
And 3rd party IDPs also do not solve the basic problem of using the same login/password combination at multiple sites.
[link]
From: g (Aug 01 2013, at 08:30)
Just to add my voice to the chorus saying that I don't trust Facebook, Google, etc., enough to tell them more than I have to about where I go on the web. Almost every time I see something telling me I need to use Facebook or Google or Twitter or something to use it, the result is immediate tab closure.
My own choice is to put up with the inconvenience of using a password manager. Which, yes, has its own problems.
Perhaps one day there will be a solution that actually works. But telling Google or Facebook even more about my life than they know already is not that solution.
[link]
From: Daniel Serodio (Aug 01 2013, at 08:58)
If your job is convincing people to trust Google, the NSA has made your job much more difficult.
[link]
From: John Roth (Aug 01 2013, at 09:40)
I'm with the guys who just don't trust Google, Facebook, etc with my identity. In fact, I tend not to trust anyone - for a site to get me to sign up, regardless of the method, it has to offer me something beyond simple curiosity value, and that's a pretty high bar.
[link]
From: Charles (Aug 01 2013, at 09:50)
I have to agree with the others here, when I'm asked to sign in to something, and my only option is to use a federated log in, I close the tab. This is not just a tech person thing. My friends and family do the same thing. People are tired of having their trust abused.
I think Mozilla's Persona is a better approach to this problem.
[link]
From: Ed Davies (Aug 01 2013, at 11:50)
People must be able to use any identity provider they like - including an identity provider they run themselves which could be on a home server, the device they're actually using or wherever else they think is a good place to keep the keys.
[link]
From: Peter (Aug 01 2013, at 12:44)
I liked InfoCard. I'm still sad that MS killed it, and sad for Kim Cameron. Why should google et al. be identity providers? Why share more properties than are actually required for a transaction? InfoCard mirrored how identity is used in the real world, and I thought that was a feature.
[link]
From: David Magda (Aug 01 2013, at 15:44)
<em>Are you smarter than those guys; the BBC, DropBox, LinkedIn, and so on?</em>
Just a reminder that Google got hacked as well:
http://en.wikipedia.org/wiki/Operation_Aurora
I think that your e-mail and your financial institutions need to be highly protected. All other online accounts are generally irrelevant IMHO.
P.S. None of the banks I use have my e-mail address.
[link]
From: Petr T. (Aug 01 2013, at 23:57)
Using separate usernames and passwords for different websites is MUCH better for your privacy. Just use a tool that helps you manage them, like LastPass.
[link]
From: Gavin B (Aug 02 2013, at 00:44)
BTW there is one site I still trust on the Internet:
the Guardian Newspaper site:
http://www.theguardian.com/uk
[link]
From: Jashan (Aug 02 2013, at 05:11)
In general, I'd agree ... unfortunately, there's another major problem with federating: Users tend to forget which of the gazillion available services they have registered at your site with. And then they're too lazy to try all the possibilities. And then they're gone.
[link]
From: MJ (Aug 02 2013, at 05:59)
There is no really a good argument on behalf of federation in the Whys any other that user might be scared and leave you're site when she need to give yet another password. How many that really is depends on what kind of an site or service you have. Other Whys are weak because when user select password for the common federation provider they can make the same mistakes as with your own password management like use simple ones, too short or too long, those that are too hard to remember or too easy to figure out, save the only one password to everywhere in a note at the wallet, use same password for different federation providers etc.
That federation provides single password to everywhere is not really a good way to marketing of making Internet more secure because that makes it more important to make that single one secured much better. Usually it is better to have a different password for your most private things like banking and for those web sites where you can post funny pictures of funny animals.
[link]
From: Daniel (Aug 02 2013, at 06:57)
what if Google/Facebook/etc. get hacked? Then the bad guy has all the login info for every site I used them to login to. Seems to be just as much of a security hole, as using the same password for every site, maybe even more since now the bad guys only need to concentrate on a small set of sites to get all my info.
[link]
From: NH (Aug 02 2013, at 07:02)
I also never use the Google/Facebook login when given the option. I use a password manager to auto generate random passwords and save them, which, while being a bit less handy, makes me feel better at least, knowing that there isn't one single site/password that, upon being compromised, gains you access to everything.
[link]
From: Michael (Aug 02 2013, at 07:03)
This is definately horrible advice. I know that when I had a Facebook account, I used them as an authentication provider for some sites but when I deleted my facebook account, I also lost access to those sites.
I think it's great for a site to offer authenticating with a another provider as an alternative to it's own authentication mechanism, but If I can only authenticate with a third party, then the site loses me as a customer. I just use a unique password and a password manager for every site.
The only time I might use it is when the site is something closely is when the site I'm logging into has a close relationship with the site I'm using to authenticate with. For example I would use twitter to authenticate to some other site that provides some enhancement to twitter or would otherwise be useless without twitter anyway.
[link]
From: Ludger Sylbaris (Aug 02 2013, at 12:52)
I hate federation. I don't want/need/trust Facebook, Google, Twitter, or anyone else to know who I'm doing business with.
If a site's only choice for login is federation, I close the window and look for another provider.
We don't have a big privacy disaster with federation - yet. It's only a matter of time before one of the big providers discloses which users are interacting with outside sites, or starts selling/showing ads for competitors ("Still using Derpbox? SpudgerOak is 50% cheaper and 33% faster!") or otherwise violates the trust of the users or the external sites.
And if I were running an online site/business, would I want it to go down if a third party's services were down? Or would I want my relationship with my users/customers held hostage because the authentication site decided that the service isn't self-supporting, and needs to generate revenue? I don't think so.
[link]
From: hawkse (Aug 02 2013, at 15:56)
Me too!
Requirement to log in using my G+, Twitter, FB or other - to the site in question - unrelated account results in immediate tab closure.
Why on earth would I want to do such a thing?
I use different passwords on all sites I use, sometimes the same username, but mostly not. I also try to use different email addresses for different purposes so as to spread the risks a bit.
As for password complexity, it varies, but I tend to like using really long phrases (20+ characters).
Only issue I've had using this approach is remembering seldom used passwords across devices.
OTOH, this blog post discussed building a website/service and focused on getting NON technical users as secure as possible with minimum effort. In that context, there's probably some good advice here.
[link]
From: Fazal Majid (Aug 03 2013, at 10:55)
I use a human-computable hash function of the site's domain to generate a site-specific password. The way forward is an InfoCard-style public key based auth, where the master key is controlled by the user. There is no such thing as a trustworthy third-party for authentication.
I certainly don't trust Google or FB. My primary browser is programmed to block any of their cookies. That was even before the Snowden revelations - I distrust Google/FB et al far more than the US Government. The latter is not really interested in me as long as I pay my taxes and follow the law. Google is primarily interested in pimping me out to advertisers.
[link]
From: TJS (Aug 03 2013, at 12:12)
Federation causes bigger problems. It concentrates weakness; Crack one site and you own the whole web.
It also concentrates power in the hands of a few companies that will gleefully track your every action and association.
If a site asks me to log in with Facebook, Google etc ... immediate tab close.
[link]
From: Ed Davies (Aug 03 2013, at 16:30)
Why do so many of the commenters here assume that only a very short list of big identity providers would be supported? They seem to be so fixated with these organizations that they've forgotten that this is the web. I consider this to be a significant problem.
[link]
From: michael (Aug 03 2013, at 16:44)
So you say just because some sites get security wrong, don't try. Instead rely on some other company that can't get it right either... like google or even worse, facebook.
Either help spread the word on how to get secure site code written, or promote a real solution like Persona by mozilla.
[link]
From: Smith (Aug 05 2013, at 05:03)
Please abdicate your web/app security to one of the big guys. It makes it so much easier for us hackers to hack once, own everywhere.
[link]
From: Matt (Aug 05 2013, at 09:01)
Log in with PayPal anyone?
[link]
From: Daniel Serodio (Aug 05 2013, at 13:32)
Also, Google stores SHA-1 hashed passwords. SHA-1 isn't remotely safe at when anyone can rent a GPU cluster/cloud for password cracking.
Google should use SHA-512 at least, but ideally, bcrypt or PBKDF2 which were actually designed for secure password hashing.
[link]
From: Jim Bob (Aug 05 2013, at 17:53)
Here's a burning question:
On a federated set up, how hard is it to have multiple federated IDs for each application account at example.com account, so that one federated ID provider, or maybe one of several federated IDs provided by the same federated ID provider can be revoked without making the account inaccessible to the average user?
[link]
From: Gavin B. (Aug 06 2013, at 06:23)
Furthermore ...
The single-click Google account login for Android apps is a little too convenient for hackers, according to Tripwire's Craig Young, who has demonstrated a flaw in the authentication method.
http://www.theregister.co.uk/2013/08/06/android_oneclick_authentication_open_to_hacking/
[link]
From: Michael Schwartz (Aug 06 2013, at 09:35)
For federation to work, it needs to be easier for web developers. Asking developers to implement OpenID Connect is not the answer for everyone, although with better high level libraries, this will hopefully become easier. A great tool for developers would be to use an Apache plugin to protect their application. This is the reason Gluu started a crowdtilt campaign to fund "UMA and OpenID Connect Plugins for Apache" (gluu.co/uma-apache)
Also, I agree that not all domains will want to relay on external authentication service providers. While everyone knows passwords suck... responsible for 80% of Internet security breaches... the answer is sometimes just "better authentication." The OX open source access management platform lets you use open source software to launch your own IDP that implements the OpenID Connect standard--the same protocol being adopted by Google. So don't knock federated login just because you want to hold your own secrets... make sure you align with the standards so web developers won't have to learn your (probably insecure) proprietary authn API.
Also, take a look at UMA if you want to go beyond authentication, and use OAuth2 for authorization!
[link]
From: TMcGill (Aug 07 2013, at 12:28)
Disagree. Nevermind the huge issue of letting a few companies (or really, anybody other than yourself) own every account you have everywhere and the privacy or data/access loss problems that generates (e.g., what happens when your single password holder goes out of business?).
Regardless, your initial thesis is about what makes the web less secure, and here is the answer to that question: encouraging users to get used to practices such as "type in your yahoo/google/facebook password on this [non-yahoo/google/facebook] page and every other page that asks for it." Federated password schemes are the wrong path altogether, because they train the user to fall for phishing attacks. Even an experienced user will, every once in a while, fail to notice that the ID provider's URL is incorrect. It only takes one such failure and your entire online identity everywhere (since you've tied them all to a single provider) is compromised.
There is only one long-term solution, and it is password managers becoming usable and mainstream. For now, these are slightly bulky (though improving) software solutions, but eventually there's no reason they can't (for instance) become little keychain devices (or part of your phone) that you wave near a computer and unlock to approve just one specific credential request.
[link]
From: Michael Schwartz (Aug 19 2013, at 13:51)
Password managers are fine... its certainly a good idea to use a password manager than to have 1000 yellow sticky notes! But the idea that password managers could be used in lieu of federated authentication is just silly. In fact, we don't want every website to use Google for authentication... (or at least I don't...) We just want every domain to use the same authentication / authorization PROTOCOL. What's the sense of every domain on the Internet having a different API for authn? Without a common infrastructure for authentication and authorization, the Internet will become increasingly insecure (if you even thought that was possible!) Standards to enable a decentralized system for authentication and authorization should be welcomed by the Internet. Anyone can send me email.... anyone can navigate to http://www.gluu.org... why can't anyone authenticate me at gluu.org? If this were possible, we could build trust between domains. Federated authn and authz promises a coral reef for a whole ecosystem of providers and solutions that would prevent 80% of the security breaches that occur today, due to bad passwords (even if they are securely stored in your password vault).
[link]