53

I work with APIs all the time and I work with web developers who insist that OAuth, OpenID, etc are far superior than a home-brew method. Every site seems to be using these as well now for ease of use to the user, but also for security. I hear it every day almost that it's more secure, but I find that extremely hard to believe for a few reasons:

  1. If a hacker somehow gets your password to one site, he know has access to the majority of the sites you visit now.

  2. It makes phishing 10x easier. With so many people using the same logins and doing it over, and over again people are less likely to actually read everything and check the URL up top.

Could you list of more reasons why it's unsafe or could you explain to me why it is more safe? I don't see why you would put up with the hassle of integrating one of these when it seems like a user would be fine entering in 3 fields (username, password, email) instead of clicking service logo to login (Twitter, Google, FB etc), entering in their username/password, clicking submit, clicking approve.

==Update==

To expand on my question as per request.

To my two points above, #1, doesn't matter how the hacker gets it. I'm not sure how to expand upon it exactly. You could brute force it, guess it, use the forgot password and do a dictionary attack on common questions, etc. But however you do it my point is, 1 password to access 1000 servers is far less safe than 1000 passwords to access 1000 different sites. I can personally guess a few of my friends' and family's passwords and ill have access to all kinds of accounts. I wouldn't even have to look for them. As i browse the web ill just be logged in... If i was a hacker, many of these passwords are very easy to crack. Some of my friend's passwords are, pepsi, tina(then birth year), 123456, and other stupid ones. My favorite though is tomcruisesucks LOL.

For #2 point, to expand further, I might go to http://wired.com, http://klout.com, http://twitter.com, http://thenextweb.com and they all have a Twitter login. I trust the sites (for the most part) so, honestly, I don't check the URL of the popup window that comes up to login anymore and I assume most do not. That popup window could have been easily hacked by a hacker getting on one of their servers, or an evil employee, or just a fake app site that a bot is sending to people over twitter that multiple people then login to this fake app, but using the Twitter login.

People are so used to seeing the same login pages they don't look anymore. If this thread gets popular enough I can easily do a super simple test on Twitter or FB by sending everyone a link to a fake app, have a popup window that looks like Twitter or FB and they'll login. I guarantee it. If i make the login screen go to, lets say, http://bankofamerica.com or http://paypal.com they'll ask themselves why am i here, why do they need this info, etc. The same sites used to login over and over again is extremely bad in practice.

That's my expanded discussion point ;)

Scott Pack
  • 15,167
  • 5
  • 61
  • 91
Oscar Godson
  • 631
  • 5
  • 5
  • Have you sniffed the different authentication schemes? What does it look like on the wire? Do we know the protocol? What gets past to and from server, sort of thing. – Marcin May 22 '11 at 17:34
  • 4
    @marcin - openid and oauth are very open and relatively well-vetted standards, with specs, wikipedia pages etc. YMMV with Facebook Connect.... – nealmcb May 24 '11 at 19:25
  • 1
    It is hard to answer this question because there are a lot of different aspects. First, you don't clarify exactly what alternative you have in mind to oauth. What is our application? Second, facebook connect is presumably proprietary, and thus in a very different league from oauth and openid. And third, your comment about phishing issues from use of links on people's facebook walls is a whole different topic. I suggest editing out the facebook connect and facebook link parts here and asking separate questions about those if you like. – nealmcb May 24 '11 at 19:32
  • @nealmcb Why wouldnt you use a homebrew method, or simply check for cookies. I.E. user logs into service, then he has API access. this could easily be done with an iframe or a form POST. All of the services whether open source or not have the same flaws and thats what im saying. they are all connecting all your accounts under one password. Again, for your 3rd point, thats _exactly_ the same for Ouath, or really, ANY site, but its worse when large sites hold your password because people dont check the URL. I think you're missing my 2 numbered points... – Oscar Godson May 24 '11 at 20:31
  • Most people don't read comments, so it would help if you could edit in a specific attack scenario into the question. What asset are you protecting, from what threats, etc. See the faq. Then we can discuss it in the answers. – nealmcb May 24 '11 at 21:23
  • Done! I expanded on the two points – Oscar Godson May 24 '11 at 21:44
  • Thanks. I must say that it is still unclear what your question is - what problem you're trying to solve, from what perspective. Are you deciding whether to use these technologies in an app of your own? Whether to use an openid or a custom login for a particular site? Can we expect to agree on which answer is right? We should be able to - see the faq and note that this site isn't for "discussions". – nealmcb May 24 '11 at 22:07
  • Im a long time user (almost 2 years) of StackOverflow, I know the rules :) and yes, there will be a right answer. In a short, one sentence question, Are these auth methods actually safer than having your own login system. Other people below seem to understand so im not sure how to expand :\ The "right" answer is an explanation of either yes its safer and why or no its not and why that I like/understand/most verbose answer. – Oscar Godson May 24 '11 at 22:15
  • 1
    Google supports u2f, which makes phishing 1000x harder. – Neil McGuigan May 27 '16 at 02:39

10 Answers10

23

I guess there is no really good solution for everday websites (e. g. not high profile sites such as banks for which users accept and economic allows a two factor authentication). One can only pick a solution which as little negative impact as possible.

Unfortunately people are not good at remembering a huge number of passwords. This results in either them reusing the same password on different services or writing them down (on paper or a password manager). Yes, there is the advice to create a password system including the site name.

But people are lazy. Password reuse is worse than a central account because it means that a vulnerability in any applications reveals the password.

In the Stendhal game most of the account hacks are done by family members. I guess that is special for games. The next group is random guessing of usernames/passwords. But there is a small number of hack attempts that are based on getting access to the email account. While we do not allow automatic password reset using email, many website do. Twitter's upper management was hacked exploiting an expired Hotmail email account and reused passwords.

So if you consider to allow password reset via email, there is little additional risk in delegating the authentication process to the big companies. All of them have measure in place to make it more difficult for attackers (recovery via mobile phone messages in case of suspicious activity, login history, warnings about login attempts from other counties, etc). It is a lot of work to implement those in your own site.

On a personal note, I would have preferred the Account Manager approach (specification) over trusting one of those companies. Plus, it does not have the phishing problem. Unfortunately the project does not seem to make any progress.

In the end we decided for Stendhal to support both OpenID and local accounts and let the users decide.

Hendrik Brummermann
  • 27,118
  • 6
  • 79
  • 121
17

From a security perspective, having a tried and tested mechanism is almost always better than rolling your own. Implementation errors are one of the most common ways a good security concept gets broken.

From a usability perspective I slightly prefer oauth, it is just easy to use, so for your end users that is a huge benefit. An average non-technical user is put off by overt security so minimising the intrusion of security functionality is a win for sites with large numbers of users.

The phishing risk isn't really any greater - people don't pay any attention to the source of emails anyway:-)

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
  • Thats true about email phishing except most email providers (Yahoo, Live, Gmail, etc) don't let phishing sites get through. My concern is more like those links on FB or Twitter from your friends saying "check out this link" – Oscar Godson May 22 '11 at 23:12
17

The benefits of systems like OAuth are:

  • there are fewer databases in the world storing a user's login credentials. Considering a service like Twitter, this means that your username and password is known only to Twitter and not to Favstar, Amazon, LinkedIn, New York Times and all of the other applications that build on top of the service.
  • as @Rory says, the system is in wide use and has been tested and (hopefully) secured to an appropriate extent.

Both of these benefits address your point 1: OK so all of these services use the same password, but they have to anyway because they all need to use your Twitter account, so it's best to ensure that these "universal" credentials aren't stored in a variety of places with a variety of protection measures.

The principle drawback is no different from the drawback affecting all login UI: anyone can make a login UI that looks like that and use it to gain your credentials.

  • **1st** point is true if you use the same exact password and username, but having different passwords on 1000 different servers is safer than 1 password on 1000 servers, no? **2nd** Yes, anyone can make a login, but there is a _huge_ difference between seeing a FB login page / button half a dozen times a day to a one off login for a random site. If i was on site1.com and it had a login page for site2.com, itd be strange. If site1.com had a login page to facebook most users wouldnt even think about it. Thats what im mean. – Oscar Godson May 24 '11 at 20:37
  • 1
    @Oscar: in the situations where OAuth is useful, you can't have 1000 different passwords. "so all of these services use the same password, but they have to anyway because they all need to use your Twitter account" –  May 25 '11 at 08:37
  • 2
    @Oscar sadly most people have exactly the same password/username for mutipul sites, because their lazy and/or don't care and/or the pain caused by the delay in thinking of new passwords/remembering which one goes with which site/forgetting and having to have your password reset is greater than the perceived pain of having a Mallory gain access to their account. –  Jun 13 '11 at 19:12
16

Without a specific scenario and threat model in mind it is hard to answer your question.

But one clear win is the classic OAuth use case. It turns out users are amazingly willing to give one web site their password for another web site, e.g. their Google password to a social networking site like Shelfari. And as Kalsey notes, they were sometimes horribly surprised at what Shelfari did with that password, and since Shelfari could totally impersonate them, Google couldn't easily stop the abuse.

Now, with OAuth, an app like Shelfari would only get partial access via an API to the user's contact database, and Shelfari would use an API key that Google could easily revoke.

In the real world, users are very likely to reuse passwords on multiple sites, so your attack in #1 has a chance of working lots of places as it is. In fact we can hope that users will use a better password for their important OpenID site, or use 2-factor authn, or whatever.

As for #2, the point with OpenID logins is that it becomes unusual to run across a site which thinks you're not logged in, when you note that you are logged in in your other web sites. On the other hand, it is already simple without OpenID or OAuth to make a site look like twitter, and link to the site and hope to convince folks to log in to it and grab their passwords. If folks are always logged in to Twitter (e.g. for other sites via OAuth or OpenID) then they are likely to ask why they aren't already logged in.

nealmcb
  • 20,544
  • 6
  • 69
  • 116
11

Wrote this about federated ID.

Basically you are talking about the centralized risk problem or keys to the kingdom. This also applies to password managers, but securing a small number of identity and authentication systems is a lot easier and more effective than having hundreds of weak passwords (or the same weak password a hundred times). Open-ID providers like Google now offer two factor authentication; if you do not like a soft token on your phone, Yubikey USB hardware tokens are also supported by many Open-ID providers. Control and auditing is also greatly improved; do you know every application where you have used a password? Me neither. Yet many Open-ID providers have all the sites where you have granted access to that identity, revoking access is a one click process

From a business perspective using something like Facebook oAuth will provide access to all that social data, analytics and increased chances of going viral. Add that it is faster and cheaper than paying a programmer to develop an authentication function using some form of federated auth seems like a no brainer to me.

Rakkhi
  • 5,783
  • 1
  • 23
  • 47
10

I use Google for my OpenID account. Almost all websites that do not use OpenID let me reset the password via email, so if someone got the password to my gmail account, I would be screwed anyway.

Kim
  • 241
  • 2
  • 8
  • This is true, however, Google is harder to hack and they block brute force and stuff. I trust Google far more, then lets say, Klout.com or something. But yeah, i get what you're sayin :) – Oscar Godson May 22 '11 at 23:09
7

Having 1 password stored in 1000 servers is less secure than 1 password stored in 1 server which authenticates 999 servers is less secure than 1000 password for 1000 servers.

However the latter is impractical, people aren't capable of remembering 1000 password for 1000 servers, the only way they do that is to use password managers. And where does password manager stands?

Having 1 password stored using 1-way encryption in 1000 servers is less secure than 1 master password for a password manager which stores 1000 passwords in cleartext or 2-way encryption for 1000 servers is less secure than 1 password stored in 1-way encryption in 1 server which authenticates 999 servers is less secure than 1000 password stored using 1-way encryption in 1000 servers.

Therefore OAuth/OpenID can be more secure and convenient and practical. Using 1000 password without a password manager is impractical, and using password manager is less secure since those passwords would need to be stored in plain text or using 2-way encryption.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
  • Agree, "1000 password for 1000 servers" is the ideal world; it usually is "1 password stored in 1000 servers". If that password is compromised you have to change the password in 1000 servers (and remember that you have an account there). – ndrix May 26 '16 at 23:44
5

One way OAuth and OpenID improves security is that it makes you have to type your password less often. Linking a new account to OAuth/OpenID is just me being redirected to the identity provider, and since I'm already logged in to the identity provider all the time, it simply gives a Yes/No prompt instead of a password prompt. No password travels throughout this exchange.

This makes you more self-aware if you're actually getting prompted for password instead of just passing through.

So #2 is not really an issue.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
4

#2 is absolutely true but not primarily a problem of federal id, only that it is even more critical in this case.

You have similar problems with all login forms embedded in (actually) untrusted content, especially because the used authentication is the most insecure(secret is simply transmitted by the browser, and if you're lucky the server puts SSL underneath for your convenience..).

You need two things to fix this and most other phishing attacks:

  • secure interface for user authentication, e.g. dropdown dialog from url bar, and NOT part of server content.

  • natively implemented authentication protocol (not by server content, like JavaScript) that will not disclose the secret to a potentially malicious server (e.g., SRP)

BTW, I implemented SRP for NSS several years ago and others even implemented GUI extensions. Unless Smartcards become ubiquitous, this is the way to go: http://trustedhttp.org/wiki/TLS-SRP_in_NSS

pepe
  • 3,536
  • 14
  • 14
0

Humans always want to transfer their responsibilities from their shoulders(Not everyone). Security is a great responsibility and most businesses want to focus on the core business and give their customers best of their product rather than worrying about the security.

Single point of failure is definitely something to worry from a security perspective but people want to trust in big companies because of the fact that they got huge money and with money comes good security engineers(not exactly but Yeah!). Good engineers means good security practices. Further they are not gonna show their back to people(hopefully!).

Phishing is definitely a huge issue and security community has been working on this issue for quite sometime now. As @Rakkhi mentioned, recent solutions like Yubikey, Fido U2F to solve the phishing issue might help tighten the security.

The only thing we could hope for is a new design shift where people don't have to choose their passwords and enter them while being able to authenticate them securely.

Vicky
  • 1