8

This question is mainly aimed at OpenID Connect, when it is fully realized.

I understand the aversion to signing in with a social networking site, but from what I understand about OIDC, its supposed to finally allow developers to simply implement OIDC once and have it work with every provider.

Once this happens and people have the option to sign in with a non-social-network, and see the options like Symantec and realize that 'oh, this Identity thing isn't just about sharing my email contacts and friends list with the entire planet', I believe that much of the distrust will evaporate.

So ignoring the hesitation to oauth with a social network, and moving onto the question:

Is BYOID as the only way to authenticate, and thus completely outsourcing authentication, a valid security practice?

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
Andrew Hoffman
  • 1,987
  • 14
  • 17
  • With OpenID anyone could create their own ID provider, which I thought was a good feature. I'm not sure this is the case with OpenID Connect (which is built on top of OAuth). Do you know whether it's limited to a certain set of large providers? – paj28 Jun 25 '14 at 14:19
  • From what I understand it will continue to be the case that anyone can be a provider. The provider discovery by email address feature will be what finally opens it up to all the smaller providers. Right now OpenID as the only auth option isn't valid because those things are hard to remember. – Andrew Hoffman Jun 25 '14 at 14:28
  • I think this is UX question, not security one. – Agent_L Jun 25 '14 at 17:16
  • 2
    The biggest pitfall I see is that you can't treat data provided by the identity provider as trusted. In particular if it hands you an email address, you can't assume it has been verified. – CodesInChaos Jun 25 '14 at 17:19
  • 1
    The US Government believes so - OMB doesn't want the US government to issue any username/passwords. All authentication should be done through PIV or third party providers. – MCW Jun 25 '14 at 17:35
  • @CodesInChaos why would you assume that? Attribute providers should provide an attribute practice statement that would clarify how they verified the data. Check into Kantara or Trust Framework Systems. – MCW Jun 25 '14 at 17:35
  • 3
    Please define "valid". Without a definition of what *you* mean by "valid", the question is impossible to answer. – D.W. Jun 25 '14 at 22:12
  • @MarkC.Wallace But you can only trust the provider if they're on a white-list, no matter what their statement says. – CodesInChaos Jun 26 '14 at 08:18
  • @CodesInChaos ?? What white list?? – MCW Jun 26 '14 at 10:58
  • @MarkC.Wallace Mallory logs into your system using `evil.com/mallory` as identity. `evil.com`, acting as attribute provider, then claims that it validated mallory's email address as `obama@whitehouse.gov`. You obviously can't trust that claim. The only way to avoid that problem that I know is creating a whitelist for attribute providers. – CodesInChaos Jun 26 '14 at 11:34
  • 1
    @CodesInChaos I believe that BYOID puts the onus for security on the person creating the account. If you want to be your own provider and trust yourself to do a good enough job, then that is on you. Can a provider be untrustworthy? Yes. But in BYOID that isn't my responsibility to protect you from yourself. It might be a good idea to hold a blacklist of known untrustworthy providers such as evil.com. Btw, from what I understand, the discovery for whitehouse.gov will go to whitehouse.gov, not evil.com. – Andrew Hoffman Jun 26 '14 at 13:20

4 Answers4

6

Yes this is a reasonable approach.

It is not a zero risk approach. If a user does not already have an OpenID Connect account, or they do not understand the concept, the sign up process becomes more difficult and you risk losing that user. Because you are doing something that is non-standard you will get some smart alec users who pester your support guys with pedantic complaints. And if there is some future compromise, perhaps a flaw in the OpenID Connect protocol, you may look foolish compared to the sites that never pursued this approach.

But on balance I believe this is a good thing to do. Most users will already have an account with one of the major provides and will be happy to use that, just as I happily use my Google account to log in to stack exchange. A smaller number of users will have an account with a minor provider, who they've chosen because they like their privacy policy. And some will even run their own OpenID Connect server. I believe this covers everyone's needs, so there is no need to provide a fallback to user name + password authentication.

Edit - rereading my post I realise I have made two assumptions:

  • That OpenID Connect becomes a widely-used, defacto standard. If it doesn't then you certainly need to provide alternatives.
  • That your site is not highly sensitive. If it is then you should probably be using multi-factor authentication.
paj28
  • 32,736
  • 8
  • 92
  • 130
  • Re "That your site is not highly sensitive ...", is the protocol provide enough flexibility that a trustworthy provider could wrap an arbitrary other OpenID provider and bundle an orthogonal auth channel with it, or are any two OpenID providers equally susceptible to replay/MITM? – Mike Samuel Jun 26 '14 at 11:28
  • @MikeSamuel - you certainly can have an OpenID provider that enforces multi-factor and the existence of less-secure OpenID providers doesn't diminish that. This could theoretically be used to have a single banking multi-factor device that can be used across multiple banks. Whether that would fly in practice is another matter. I expect sites that are sensitive enough to need multi-factor will be reluctant to outsource their authentication. – paj28 Jun 26 '14 at 12:24
  • Yeah. I was just thinking, I already trust my cell-provider to deliver short-lived secrets to my phone, and I already trust the author of my password-manager to keep those confidential, so there might be some benefits to being able to compose a site-sharded OID provider maintained by the password manager and an unsharded TFA OID provider maintained by my cell-provider. – Mike Samuel Jun 26 '14 at 12:40
5

No, I don't believe it is, though I am focusing on usability purposes more than security purposes which is perhaps not what you're referring to with this question due to where you posted it, but it is important to consider.

There are people, such as myself, that do not use any third party authentication service. To have these as the only login options would be to completely deny me entry to your website, which I may have otherwise been interested in. As it is, only the large social networking sites like Facebook and maybe Google have enough traction that you can be reasonably sure most interested visitors would have an account with them. But you should always provide a fallback option for those who are interested but don't have/don't wish to use any third party service, otherwise you are needlessly denying interested participants.

R W
  • 59
  • 1
  • Yeah this is a big one, but I think a large part of it is due to Facebook and Google+. If a website is looking to make money off of you, say by selling products, this might be very valid, I'd be hurting myself by not providing you an auth service myself. But then, many websites that sell stuff don't have great security anyways. So BYOID would probably be in your best interest. But finally, if I offer a website that is to make no money off of you, and you want an account, putting the onus on you to secure your own account doesn't really hurt me. – Andrew Hoffman Jun 25 '14 at 18:04
4

It would largely depend on your use-case. For instance I think it is acceptable for websites like Plug DJ or Stackexchange to implement OpenID. Often they don't offer any other form of authentication, but I find that acceptable. There will be a number of users which will not like it as it's again another way for social media to gather even more statistics, but that's not really a security issue.

From the perspective of a sensitive application, it's currently not feasable or acceptable for several reasons. Foremost perception and second of all the requirement for two-factor authentication (which I'm not sure is currently available).

Also your application's security controls for passwords (e.g. password policies) are completely depandable on the implementation of the OpenID provider. If the OpenID providers make a mistake and passwords are leaked, who will be held accountable if fraud happens on your application?

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
  • That's a good point. I don't know that OpenID enforces compliance standards. Banks and money management sites like Paypal would probably never consider it. However, what if you're a small mom and pop online store? Odds are the various providers are more secure than you will ever be, and many of them support multifactor (google, verisign, etc). – Andrew Hoffman Jun 25 '14 at 14:48
  • 1) Your answer is a bit confusing since sometimes "you" refers to the end user (e.g. "your OpenID provider") and sometimes to the website using these credentials. 2) The security properties aren't much different from emails. The the email provider can leak passwords and compromise of the email account propagates to the relying application via password reset. – CodesInChaos Jun 25 '14 at 17:22
  • @CodesInChaos updated. Then again most sensitive applications allow for a form of two factor authentication. Also looking more towards banking applications, I don't know any which require you to just use a password which can easily reset by email. – Lucas Kauffman Jun 25 '14 at 17:29
2

Instead of focusing on the OIDC implementation, I want to address the more general question of:

Is BYOID as the only way to authenticate, and thus completely outsourcing authentication, a valid security practice?

Public Keys are a form of outsourced authentication. We trust 3rd party verification of the validity of a certificate and allow access to resources as a result. In that light, it does not seem unreasonable. By tying the external validation to what could amount to be 'crowd-sourced verification' (i.e. social networks), you can have some level of confirmation that the person is the person you expect them to be.

It is true that the implementation has some significant hurdles, but the concept is well accepted in other forms.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • Excellent point! Its a little bit different in that the RP chooses the cert, but the principle is the same in that both parties are trusting a 3rd. – Andrew Hoffman Jun 26 '14 at 13:08