23

Using OpenID for authenticating users grows in popularity and, in fact, makes a webapp easier to use.

But what are the security considerations one should bear in mind when deciding whether to implement an OpenID or not?

Is it suitable for any kind of webapp? Or are there categories of web applications which should not use such a way of handling authentication of users?

Is it ok to use OpenID for e-commerce applications?

AviD
  • 72,138
  • 22
  • 136
  • 218
rem
  • 2,017
  • 2
  • 19
  • 27

4 Answers4

12

I think it makes sense to offer signup via OpenId, but not require it, even for ecommerce websites.
The reason for this, is that tech-savvy users (still the core userbase for openid) can decide whether to take that risk, or not.

The sites that I would not recommend using OpenId, are either highly sensitive sites, e.g. bank sites, or private/corporate systems where you want control of the users' identities, too (ala Enterprise-Centric Identity, as opposed to User-Centric Identity).

There is a clear advantage to using OpenId, since you dont have to manage users' identities, including passwords, resetting, security, etc, and accepting the risk that involves.

AviD
  • 72,138
  • 22
  • 136
  • 218
  • Thanks, AviD. +1. You said users can decide whether to take that risk, or not. Do you mean that using an OpenID can potentially be a threat for a particular account, but not for the entire webapp? – rem Nov 12 '10 at 08:59
  • 1
    Yes, absolutely - depending on your app's resources and data. One part of the issue is that you "lose" control of your users' identities, so you might be exposing your data - and if this is a risk for you, then you fall into the second category I outlined. However, typically a user will use his OpenId for several sites, some of lower security, which might potentially put his identity on the higher-security site at risk. (A question of trust boundaries and attack surface). BUT, if he wants to mix identity between secure- and not-so-much sites, that could be his choice. – AviD Nov 12 '10 at 09:08
7

Each OpenID provider has a trade-off of security features and drawbacks. For example:

Features

  • Google, Facebook, MyOpenID, and Verisign all offer varying degrees of two factor support. (Verisign being the most secure IMHO)

  • They all support Javascript free operation (for security paranoid users)

  • Privacy and enhanced anonymity with MyOpenID and LiveID (not many others though)

  • Password change policy

  • Signin Seal (Yahoo, ADFSv2 )

Flaws

  • Many sites don't offer the same HTTP header security as documented here. This means some sites are more vulnerable to MITM, FireSheep, token replays or Clickjacking than other sites.

  • There is really no consistency at all among the various sites.

And this is just the beginning. I have a more detailed post with many valuable hyperlinks here. There, I'm comparing all the security features of the major OpenID providers and requesting from the community any other features or IDP's we should consider.

If you discover an IDP with security features not listed, I'll encourage anyone to post there.

Is it suitable for any kind of webapp?

I would say that Verisign would be a trusted name for higher security scenarios, assuming the end user opted in for all the bells and whistles. I'm not a fan of the configuration of their HTTP headers (repeat link). Just make sure your relying party (website) protects itself from replayed cookies from the RP and from previous sessions.

If you're using Windows / IIS as a relying party, I can send more info your way to protect against the scenarios I mention in the previous paragraph.

Additional Research

Microsoft has a detailed whitepaper of OpenID security issues here. I emailed the authors and they released an analyzer at http://sso-analysis.org/ the analysis tool is available here: http://sso-analysis.org/aaas/brm-analyzer.html

Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536
1

I don't think it is good idea to use openid for e-commerce website, but it is okay to use for social networking websites and information websites.

Reasons are:

  • You don't know how secure is the provider.
    • -
Mohamed
  • 1,404
  • 1
  • 11
  • 14
  • 4
    not agree: you can limit the providers that can login. And usually payment data are not in the e-commerce site but in the payment buddy (paypal etc..) – Sammyrulez Nov 12 '10 at 07:44
  • By carefully choosing your trusted providers, you can guarantee that the credentials are at least as secure as someone who just provides a user name and password to you. – Mark Beadles Mar 20 '12 at 15:14
1

I wouldn't use OpenID for anything for the simple reason that I just don't know the inner workings of it well enough. In general though I would say this;

By outsourcing your access management to it you are setting yourself up for a fall should something happen with one of the main providers.

Lets say for example that google decides to start being evil and sells your user's passwords on to a third party, that third party gain access to your site and does stuff on the users behalf.

The user will not be pissed at Google, they will be pissed at you.

And whilst in this extreme situation you have laws behind you I don't know if you would have a case if your user information was leaked in other forms.

Toby
  • 709
  • 6
  • 8
  • I don't think that Google selling passwords is a realistic risk assumed by people using OpenID. You can choose which providers you want to trust. – Mark Beadles Mar 20 '12 at 15:16
  • 1
    @Toby - What a horrible reason not to use someting "I don't know anything about it" the solution is to learn the inner workings then make an inform decision. This entire answer is just plain wrong. Your google statement makes no bleeping sense. – Ramhound Mar 22 '12 at 18:03
  • All I am saying it don't use it without knowing - Of course you should learn different things, but you shouldn't run with a solution without knowing it enough to be able to support it. – Toby Mar 23 '12 at 13:15
  • I think Toby's point is: I don't trust a third party to manage something so personal as my identity. I mean, I have access to my data, the target service already have access to may data, why risk a third party to potentially be able to have access too? – MV. Jul 03 '12 at 22:35