Tag Info

Hot answers tagged

49

This isn't a vulnerability of/in OAuth 2.0 at all. The issue has been wildly overblown and misstated by CNET and the original finder. Here it is in a nutshell: If your web site (example.com) implements an open redirect endpoint - that is, implements a URL that will redirect the browser to any URL given in the URL parameters - AND your redirect copies URL ...


28

I like the idea, but I too have many questions left open. Please do not see this as any form of bashing, because I wrote it trying to apply my authentication experience to this new scheme. I am concerned about (in no particular order) : Unauthorized use of the private key Rich client support (Outlook, Notes, etc.) Using from multiple computers Private ...


21

Short answer. Yes, blocking requests with an off-site Referer: header might have some security benefits, but I do not recommend that you implement it. The usability costs are significant and outweigh any security benefits. I feel that, as security professionals, our job is not just to recommend defenses that people should implement -- it is also to ...


20

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


18

OpenID is a protocol for authentication while OAuth is for authorization. Authentication is about making sure that the guy you are talking to is indeed who he claims to be. Authorization is about deciding what that guy should be allowed to do. In OpenID, authentication is delegated: server A wants to authenticate user U, but U's credentials (e.g. U's name ...


15

The proposed restrictions are harmful. These restrictions are overkill. They are bad for usability. As a result, I think they will harm users' security more than they help. Usability is where it's at. In my opinion, right now the #1 most important factor affecting password security is usability: the extent to which users use the mechanism in a way that ...


15

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


12

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


12

Stack exchange also has a detailed comparison of BrowserId and WebID. As argued there BrowserId is very close to WebID (a W3C Incubator Group at the W3C). Here are some points that need to be made in defence of both protocols usually as they are very different from how public key cryptography is usually done. Unauthorized script use of key. Agree that ...


11

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


11

As others have stated, this is not a new idea. Eran Hammer (one of the creators of the Oauth 1.0 spec, who resigned from the Oauth 2.0 committe) wrote a good synopsis of the vulnerability, almost 3 years ago. His description didn't get a fancy logo or any sensational media coverage. http://hueniverse.com/2011/06/21/oauth-2-0-redirection-uri-validation/


10

In general, there are several security issues with OpenID, but also many different scenarios for its use. So depending the threat model you may or may not want to rely on it, and users may or may not want to use it for authentication. As you note, possible exposure of your credentials is a problem, e.g. if you choose an OpenID provider that authenticates ...


10

PCI DSS v2, Requirement 7: "Implement Strong Access Control Measures" is the pertinent section. This section details access control primarily for non-consumers that will be accessing cardholder data for business purposes, though there are a couple requirements that seem applicable to consumers as well as non-consumers: 8.1 Assign all users a unique ID ...


10

OAuth and OpenID don't send your password to the sites you use OAuth/OpenID providers to login with, so no. Not unless the attack is performed on the OAuth/OpenID provider and provider's servers are vulnerable to CVE-2014-0160 (The Heartbleed Bug). It is however possible, of course provided that sites you're logging into using OAuth/OpenID providers are ...


10

Here is a Youtube video the original finder put together leading you through the vulnerability: https://www.youtube.com/watch?v=HUE8VbbwUms. OpenId and OAuth both provide a field that allows a third-party site to specify a redirect when authentication has completed and is successful. For instance, you go to Good Reads, they want you to login with your ...


9

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.


9

I haven't found a way to comment on the accepted answer, so I'm submitting a response to those six points as a new answer. Sorry. 1. Unauthorized use of the private key In the case of the Javascript BrowserID implementation, the private key is stored in local storage under the login.persona.org domain. So a rogue script would have to be hosted on that ...


8

If you authenticate to another website with Google's OpenID system, it will tell them that the person authenticating is in control that particular GMail address. Unless they get in-line between you and another site, they can't perform a MITM attack. They can only effectively take advantage of your credentials if they pretend to be your identity provider and ...


8

When you use a google OpenID to sign in to a site (which is thus an OpenID "relying party" or RP), the RP requests various forms of information, and gets it if you agree to provide it. Google tells you what they asked for. So yes, the RP can get contact info, with your permission. But the design of OpenID is intended to protect the most important stuff - ...


8

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


7

From having conducted many an IT audit over the last ten years or so, I would say my biggest worry would be gaining assurance that this third party authentication mechanism works as it should. An auditor who puts their neck on the line and green-lights this is in a very sticky position if something happens at the facebook/twitter end of things (they are ...


6

The question is very broad and it is hard to guess what you are actually asking. You can find the specification at http://openid.net/developers/specs/ Kerberos is typically used in a controlled environment. In that environment there are known and trusted Kerberos servers ("key distribution center"). The Kerberos server authenticates the service provider to ...


6

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


6

The question specifically notes a requirement for "tight integration with 3rd party sites". So all the arguments about how unimportant SE accounts are is besides the point. Also note that no one is forcing anyone to use this particular OpenID service. There are many to choose from. Differentiation on the basis of good security seems like a good idea for ...


6

One disadvantage of BrowserID in its current form compared to some of the alternatives is that anything beyond the core functionality is difficult: further discovery of information requires other protocols such as WebFinger, whereas e.g. an OpenID URL can provide links. For instance, it is difficult to get a display name or profile picture from BrowserID ...


6

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


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


5

The 8 unique characters is a bit on the excessive side.. Just checked and there are fewer than 1500 words in English dictionaries, with 8 or more letters that are all unique, so what you are also doing is not accepting dictionary words. Not that this is a bad idea, but you could say just that 'dictionary words are not allowed'. Of course this will frustrate ...


5

It all depends on context My baseline advice is: Do as Google does Chances are that if they can compromise Google's OpenId security, they won't bother with you. Anything more secure than that needs to be backed up by a very strong added value proposition: We want to be more secure than Google because ____________________ It is more valuable for our ...



Only top voted, non community-wiki answers of a minimum length are eligible