Hot answers tagged openid
23
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 ...
18
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 ...
14
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 ...
13
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 ...
12
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 ...
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 ...
9
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 ...
9
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 ...
9
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 ...
9
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 ...
7
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 ...
7
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 ...
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
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 ...
6
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 - ...
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
One more protocol to add to the list: WebID : http://webid.info/
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.
I'm hoping the ...
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 ...
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 ...
5
Complex passwords are often enforced by an organization's IT department to ensure that the user accounts of employees aren't externally compromised. They're also enforced in situations where a user is trusted to have access that could be damaging in the wrong hands.
In this case, neither situation applies. Stack Exchange doesn't store any private data, and ...
5
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 ...
5
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 ...
5
The risk here is the online persona itself and what would result in social engineering attacks. Let's say that you use google as the openid authenticator and have linked it to the stack exchange sites along with a collection of other sites. Prior to this, you may have used the same username and everything else across all sites but it was all a loose ...
4
I love how we are having this debate still in 2011. I wonder in another 10 years whether we will still be discussing the most appropriate password policy.
I agree with @Kyle-Cronin that the right way to approach this is to examine the risk:
What is the value? For standard users just the Stack Exchange (SE) account is of low-moderate value. It is not a a ...
4
One approach is to use "capability URLs", where the URL contains a secret token. Knowledge of the token is all that is needed to access the resource.
To learn more about this approach, read about web-keys and the web-calculus. (One person mentioned the risk of secret tokens leaking through the Referer: header; see the web-keys paper for a method to ...
4
ASP.NET out of the box can handle cookieless session handling. As such, any mechanism that uses ASP.NET sessions can work cookie-less. The Windows Identity Foundation coupled with ADFS v2 will work cookieless, but every time you return back to the STS, you will need to reauthenticate so you don't get SSO.
WIF will work with MVC.
I cannot speak to any ...
4
For more extensive information on BrowserId/Persona, I eventually found what Daniel contributed to the related Q&A on BrowserId/Persona and WebID. (I tried to convince him to post here, but he suggested I do so.)
Security, Privacy and Usability Requirements for Federated Identity by Michael Hackett and Kirstie Hawkey provides a comparison between ...
3
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 ...
3
The right answer will clearly depend on your application.
For example, you've listed:
Option for "difficult" sign in process to improve security (Verisign), also see this related question
Using a provider like this would be a terrible choice for a site with low login security requirements and a strong desire for low barriers to entry in order to gain ...
Only top voted, non community-wiki answers of a minimum length are eligible
