Isn't OAuth, OpenID, Facebook Connect, and others crazy from a security standpoint?

Question

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 ;)

Answer 1

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.

Answer 2

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.

Answer 3

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:-)

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 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.

Answer 8

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.

Answer 9

#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

Answer 10

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.