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?

Improve this question
11
  • 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
    Commented Jun 25, 2014 at 14:19
  • 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
    Commented Jun 25, 2014 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
    Commented Jun 25, 2014 at 17:35
  • 3
    Please define "valid". Without a definition of what you mean by "valid", the question is impossible to answer.
    – D.W.
    Commented Jun 25, 2014 at 22:12
  • 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
    Commented Jun 26, 2014 at 13:20

4 Answers 4

Reset to default
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.

Improve this answer
1
  • 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
    Commented Jun 26, 2014 at 13:08
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.
Improve this answer
3
  • 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
    Commented Jun 26, 2014 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
    Commented Jun 26, 2014 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
    Commented Jun 26, 2014 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.

Improve this answer
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
    Commented Jun 25, 2014 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?

Improve this answer
3
  • 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
    Commented Jun 25, 2014 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
    Commented Jun 25, 2014 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
    Commented Jun 25, 2014 at 17:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .