Tag Info

Hot answers tagged

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

note: A lot of these questions on the WebID side are answered in the Foaf+ssl FAQ. BrowserID versus WebID: is the distinction real? BrowserId (detailed spec) is an experiment at Mozilla labs, is very new, not fully defined (exactly how the e-mail servers public key should be found is not specified for example) and not completely implemented (it requires ...


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


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

Claims are a method of providing information about a user, and roles are a description of a user by way of which roles they belong. Claims are generally more useful because they can contain arbitrary data -- including role membership information. E.g. whatever is useful for the given application. Claim Based identities are more useful, but tend to be ...


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


9

In your particular example, StackExchange uses OpenID. OpenID supports the idea of identity providers -- Yahoo is an Identity Provider, same as Google, MyOpenID, etc. To log in StackExchange asks you which provider you want to use, and then redirects you to that providers login page. Once you authenticate against the provider, the provider redirects you ...


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

The April 2009 "session fixation attack" is described here: http://oauth.net/advisories/2009-1/ and in more detail here: http://hueniverse.com/2009/04/explaining-the-oauth-session-fixation-attack/ Security means different things from different perspectives. As I keep repeating on this site, it all depends on your threat model. Application providers have a ...


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

As @Jeff Ferland said, you need to trust the key from the remote party. This is exactly why Shibboleth federations are designed for, for example. If you look at a typical Shibboleth SP configuration example, it will regularly pull a metadata file that will pull the certificates of the IdPs that are part of the federation. You need to verify that you trust ...


6

The signature should validate against a key. You should have a corresponding key for any entity that you are exchanging data with. Unauthorized entities will not have keys, and the keyspace of any widely-accepted good cryptography protocol will make brute-forcing impossible. From the wording of your question, I think you may wish to read up on the concept ...


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


5

This is a great question. However, there are quite a few differences between ACS v2 and ADFS v2 from a risk perspective. ACS does not have an IdP, therefore it does not do any authentication, whereas ADFS does. As far as I understand it, ACS does not attempt to prevent token replays. It leaves that up to the IdP providing the original token, and the RP. ...


5

Regarding the identity token - it can take on several forms. In one particular case (which I know OpenID supports) the token is effectively a set of URL parameters. They provide a number of things, including: Uniquely identifying who you are (e.g. your OpenID/URL) A signature. This is a cryptographic hash, created from the identity information above and a ...


5

Experience shows that if a site like this is on the public Internet and gets popular enough, it becomes a big target and has a high likelihood of disastrous compromise. Note well the responses in this extensive discussion (about a somewhat different goal): How should I ethically approach user password storage for later plaintext retrieval? - Stack ...


5

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


5

As @SteveS said, RBAC is an authorization model whereas claims are a way of providing information about a user. It generalizes the notion of a role. In the past identity servers would simply provide applications the username and the list of roles/groups. Claims generalize this such that any user attribute can be passed on to the consuming application. The ...


4

Based on the first answer of this link : This cookie is encrypted and signed with the DPAPI key that is associated with the IIS application pool. For your information : DPAPI provides an essential data protection capability that ensures the confidentiality of protected data while allowing recovery of the underlying data in the event of lost or ...


4

Unlike the resource owner credentials, tokens can be issued with a restricted scope and limited lifetime, and revoked independently. from http://tools.ietf.org/html/rfc5849 I guess the RFC has also example, but I did browse it entirely. The oauth site also feature some code, maybe it can help you, http://oauth.net/code/


4

Here's the conventional wisdom that I've always heard about client-side certs: Client-side certificates are not well-supported by current browsers. The UI is not readily comprehensible to ordinary users. Consequently, it's not really a viable option for the masses.


4

Security, Privacy and Usability Requirements for Federated Identity by Michael Hackett and Kirstie Hawkey provides a comparison between WebID and Mozilla Persona, which at the time was still referred to as BrowserID. The main differences that were noted (in Table 1) are: Persona keys are short lived, and should be protected with a password. WebID keys are ...


3

It's a good to have option for the end-users, although the protocol does not mandate this possibility. Imagine the following scenario: The end-user starts to use an application that wants to access his google account data. So the end-user is redirected to google to approve the request. Once he approves the request, google issues access token to the third ...


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


3

SAML P is not SAML protocol but SAML Passive, so I prefer you go for this link http://www.netframeworkdev.com/claims-based-access-platform-cba-codenamed-geneva/protocol-transition-from-saml-20-passive-to-wsfederation-passive-70715.shtml


3

WSTrust is a standard which is specifies how to encrypt/decrypt/sign SOAP messages and how to bind security tokens to a SOAP message. SAML tokens are an example of a security token that could be bound to a SOAP message. The SAML protocol provides a standard way to acquire, release and renew SAML tokens using SSL to protect communications and the XmlDsig ...


3

From my testing I have only found one reason to use a Service Identity as opposed to a real IDP, and that is with OAuth Delegation. When an OAuth Delegate-e authenticates with the ACS, it requires a redirect URL after the ACS returns. This property is stored within the Service Identity and is only visible by the API and not visible by code. Considering ...



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