16

OpenID allows you to use your e.g. Google/Facebook/Microsoft account to log into a third party website. It can be used to log into Stack Exchange.

Why is this considered an acceptable practice, while password reuse is not? Does it not amount to the same thing if the OpenID account is compromised, in that the attacker will be able to access more than one of the users accounts?

Additionally, given that an email account is often the skeleton key for all other online accounts (in that the reset password link will send you an email to reset the password), is it not also dangerous to condition the users to enter their e.g. Gmail password on other webpages, too?

Jens Erat
  • 23,446
  • 12
  • 72
  • 96
JonnyWizz
  • 1,971
  • 1
  • 14
  • 34
  • But with some vulnerability in so called `oauth redirect` on the client website will lead to leakage of confidential data. This has nothing to do with openID provider, but a vulnerability in client. Also called covert redirect – haseeb Nov 13 '15 at 03:33
  • Similar: [If using a different password for every application is considered good practice, why is using a directory so widespread?](http://security.stackexchange.com/q/85790/8340) – SilverlightFox Nov 20 '15 at 13:48

2 Answers2

12

The point of OpenId or other similar mechanisms is that it allows you to select a single, highly trustworthy organisation to hold your credentials. There is an assumption that they are in some way more secure than the average site. For example:

  • They should offer 2 factor authentication
  • They should have good, proactive account misuse monitoring
  • They should be ISO27001 certified
  • Etc.

If you re-use your password, then your accounts across all the sites where you re-use are only as secure as the weakest site. Any compromise of any site would mean all your accounts are at risk.

So, partly it is a simple probability - the more places you keep your credentials, the more likely they are to be stolen.

And partly it is about quality- you should select an OpenId provider that you trust highly.

On the point about entering email credentials into other sites, the idea with OAuth etc. is that you don't do that - the site that you log into redirects your browser to your ID providers site and you enter the credentials there. Admittedly, this is somewhat subtle and many users might not realise what is happening, but that is the principle.

Mike Goodwin
  • 2,151
  • 1
  • 11
  • 13
  • My point about entering your email credentials into another site, is that if the average user is used to entering their Google login details when registering for a site, they may not notice if a malicious site does not redirect them, but instead captures their Google login details. – JonnyWizz Nov 12 '15 at 15:19
  • 1
    Yes, I take your point. It is a certianly a weakness, but on balance, it is probably better than password re-use :o| – Mike Goodwin Nov 12 '15 at 15:26
  • 3
    if you need to reset your compromised password, you have to remember all the places you used it - with OpenID, you need only change it in one place – schroeder Nov 12 '15 at 17:56
  • @schroeder if you follow good practice, any compromised password should be used on one site only. Or are you saying that OpenID is a sort of online password manager? – JonnyWizz Nov 12 '15 at 21:33
  • @JonnyWizz The question was about reused passwords .... which would mean that a compromised password would be used on multiple accounts ... – schroeder Nov 12 '15 at 22:05
  • 1
    @JonnyWizz it is the security problem for openID if one password is compromised . Attacker can figure out where this openID is used and can access all. But since email address can be used for password reset on normal combo, this has practically little effect – haseeb Nov 13 '15 at 03:18
  • 2
    @schroeder, maybe I wanted to rephrase it like this, if password reuse is considered insecure, why isn't OpenID considered insecure too. Surely usiong a unique password and a password manager is better than both password reuse and OpenID? – JonnyWizz Nov 13 '15 at 07:09
10

TL;DR: You're not using a passphrase multiple times with OpenID, but have other parties (like Stack Exchange) trust your identity provider (like Google) to be carefully authenticating you. The passphrase (or any other authentication schema like two factor authentication, certificates and so on) only is revealed to the identity provider.

Identity Certifications in the Real World

Similar methods are often used for opening bank accounts, signing up for phone contracts or other actions requiring verification of your identity. If you don't want to go in person to that company, often you can have your identity verified through a notary, post office or bank agency, which will verify your passport (this is like presenting your passphrase to Google), and then hand you (or pass it immediately to the third party requesting authentication) a certificate confirming they checked your identity, but without attaching a copy of your passport.

OpenID

The idea of OpenID (and similar single sign on technologies) is that you don't enter a passphrase at the target site at all. For example, if you want to log into your Stack Exchange account using Google, Stack Exchange never gets hold of your passphrase, but you get redirected to Google instead, which will authenticate you (possibly you're already logged in to Google, so you might simply be asked whether you want to be authenticated for Stack Exchange and be sent back there).

Stack Exchange does not get hold of your passphrase at any time, it wouldn't even realize when you change your Google passphrase. Instead, Google sents a kind of certificate to Stack Exchange, handing over some identity information, which might just be some numeric identifier, but could also be enriched with additional information like your mail address.

There is a great image describing the workflow on Wikipedia:

OpenID vs. Pseudo-Authentication using OAuth

"OpenIDvs.Pseudo-AuthenticationusingOAuth" by Saqibali - Own work. Licensed under CC0 via Commons.

OAuth

OAuth does thing a little bit different by not passing certificates, but a kind of access key. To simulate OpenID behavior through OAuth, the identity provider would provide a simple service that can be used for only authentication. If the key "fits", the user successfully authenticated.

Security

The whole scenario is secure, given a few security precautions.

  • You shouldn't give your passphrase to a fake authentication provider looking similar to your real one (for example, a fake Google page for phising attacks). This is like providing your passport to some fake notary, that will make a copy and do bad things with it. This can be mitigated through careful verification of the site URI (password managers and automatic passphrase lookup per URI are very helpful with this!) and using additional security measures like two factor authentication.

  • The certificate can only be used for a given time, and is only valid per site. For example, a fake Stack Exchange web site might get hold of a certificate. But as this is only valid for the "fake Stack Exchange", the attacker will not be able to use it to authenticate against the real Stack Exchange or other websites.

    The actual implementation of this differs between all of the single sign on technologies, but they all implement a similar method to bind certificates to third parties.

Jens Erat
  • 23,446
  • 12
  • 72
  • 96