Tag Info

Hot answers tagged

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


11

The way that single sign-on has been implemented for the Stack Exchange Network is very interesting. It makes use of HTML 5 Local Storage. Depending on the browser support that you require you maybe able to use a similar method. You can check out the stackoverflow blog post Global Network Auto Login for more details.


7

Sure it's possible. What you want to do is called Federation. How you set it up really depends on the applications and platforms you run though. There are a variety of protocols out there that can do what you want; e.g. SAML, WS-Federation, OpenAuth (to a degree), etc. The applications need to be able to support the federation protocols though. In theory ...


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

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

Two views: Corporate: Whether you have control over all the machines, or at least the central auth server, you're better off with SSO. One place to hire employees, one place to terminate them, one set of credentials they have to worry about. Individual server compromises shouldn't leak credentials. Users are less likely to get annoyed, forget passwords, ...


5

Better or worse is relative to the usage of the protocol. SAML has it's place and SWT/JWT/et al have their place. The SAML spec is pretty much set in stone, whereas SWT/JWT are really in their infancy and keep changing. SAML has lots of knobs which makes it fairly complex and that's the enemy of good security, but everyone pretty much implements it the same ...


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

Two good protocols for this are OAuth (http://en.wikipedia.org/wiki/OAuth) and SAML. You can run your own "identity provider" site, using OpenID or other authentication approaches.


5

You don't have to use an external service for OpenId. You could host an OpenId server internally and use it for your SSO. This would allow you to leverage open source code and all the work that has gone into making OpenId secure. PS: OpenId can be used to have a unique identity used by many sites but you still have to "manually" login on each domain.


5

OAuth and OpenID have different purposes. OpenID revolves around the concept of proving "who you are" and hence is useful in the scenarios where you use one login to log in to multiple sites. However, OpenID doesn't talk about authorization for taking certain actions or accessing certain data of Site1 while you're on Site2. For example, you're on FaceBook ...


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

No, CAS is just an Authentication Service, but you can surely impose Authorization using the mechanism, which is the base of doing authentication for your CAS. Say, if you are using LDAP to authenticate the Accounts for CAS. Then, for the requirement like yours..... You can create UserGroups in LDAP and assign respective User IDs to their groups. Now, at ...


4

First of all: CAS - http://www.jasig.org/cas : Central Authentication Service project, more commonly referred to as CAS. CAS is an authentication system originally created by Yale University to provide a trusted way for an application to authenticate a user. CAS became a Jasig project in December 2004. Second: no, I don't think it can do ...


4

To some extent, what you suggest exists: it is called X.509 certificates. The main problems with signed tokens are: Control latency: once a token has been signed, it cannot be promptly canceled; you have to wait for expiration of the token. Or you implement an online revocation check (which is called OCSP in the case of X.509 certificates), which brings ...


4

Using something like oauth would probably be easier and safer. The main issue with it is that you can't use the user password for user level encryption, but if that isn't needed by the site the user isn't logging in to directly, then you are fine. You have the basic idea right, in that you want the one server to be responsible for the login and the other ...


4

For SAML 2.0 identity providers that support it you can pass ForceAuthn="true" as an attribute for the AuthnRequest. This will tell the IdP to not use any previous security context when authenticating the user.


3

If I'm understanding your example correctly, it sounds like you are talking about applying something like Kerberos to SSO. As long as the service provider knows how to trust the ticket granting authentication server, then yes, it should be secure. As to why it is not done that way, I think it may be to provide greater control of information and keep it ...


3

It seems like it is probably equivalent to a throwaway account, although with less work involved. Another similar service that creates a disposable openid is at http://openid.anonymity.com/ Other services like myopenid.com allow you to create multiple aliases for a single account. Liquidid.net allows you to create multiple anonymous email aliases. I guess ...


3

The short answer is No, it is not CAS's job to do Authorization, it is supposed to only to Authentication. That said, there are many ways to use CAS in an Authentication/Authorization scenario. I am working on such a custom solution right now myself. I believe there are ways to do some spring security wizardry to get around to it, but the way I have it ...


3

If you're relying on the email address to verify the original user's identity, whether for login or password reset, then a compromise of the email account means a compromise of the website's account. Therefore, I don't see any elevated security risk in this login scheme. In fact, this is essentially like using a third party authentication service. Think, ...


3

From security standpoint, there's not much difference between JWT and SAML token specs; it mostly boils down to supported signing and encryption algorithms (JWT is more limited in this regard; see http://tools.ietf.org/html/draft-jones-json-web-token-10#appendix-A). For this use case, in the end they both just provide claims (with all the necessary baggage, ...


3

It actually can be a cookie, because it needn't be associated with the service provider at all, only the identity provider. All either of the two service providers are going to do is make the authentication request to the identity provider, so the process for an unauthenticated user is going to be the same for sp.example1.com as it is for sp.example2.com. ...


3

The MAC is the right tool here, and HMAC/SHA-256 is fine. Using a 5-second tolerance might be a bit optimistic: You have to make sure that both servers have accurate clocks; use NTP. Also, make sure that you use a well-defined representation, i.e. something in UTC (otherwise, you'll run into trouble with Daylight Saving Time). The "5-second delay" must be ...


2

I understand that OAuth (which is the protocol that OpenID implements) is a direct descendant of Kerberos. Have a look at this discussion for a pointer to the spec.


2

Imho the biggest concern with SSO is the sheer impact of a password breach, simply by factoring up all possible service accesses. Otoh the younger history has shown that password reuse is more the rule than the exception. And SSO can also be used to enforce e.g. stricter password policies (use one password, but use it in a secure manner) or even enrich it ...


2

Perhaps ADFSv2 (A free download for Windows 2008R2) will help you with the common domain cookie. Here is an excerpt of the web.config located in C:\inetpub\adfs\ls that you will need to configure to achieve the desired effect. <!-- Common domain cookie. A common domain cookie stores a list of recently visited Claims Providers (also called ...


2

I do not think that it will be a good idea to hide the identity of Service provider(SP) from the Identity Provider (IdP- a trusted third party). The IdP is providing authentication as a service to SPs that integrate with it. This comes under federated identity management which is entirely dependent on establishing trust relationships between different ...



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