Hot answers tagged

42

Why doesn't the system admin just create a user account for each user on each server, so that the users can use their username and password to access whatever resources they wish to access? Imagine you have 50 users and 50 servers. For the sake of simplicity, suppose that all 50 users are supposed to have access to all 50 servers, they all have the same ...


27

Simply put, that would be an administrative nightmare. Kerberos allows administrators to have any number of employees use the same credentials to log into resources throughout their domain. Let's say that this didn't exist in a simple network. User enters password to unlock their computer. User wants to map a network drive. They must now need to re-enter ...


22

The idea with a good single sign on is that there are fewer places for your credentials to be compromised. There are three reasons to use different passwords, first, because each unique place that stores your password (hopefully hashed) is another place it could get compromised. Second, because if your password is compromised, any other account using it ...


19

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


12

The point of OpenId or other similar mechanisms is that it allows you to select a single, highly trustworthy organisation to hold your credentials. There is an assumption that they are in some way more secure than the average site. For example: They should offer 2 factor authentication They should have good, proactive account misuse monitoring They should ...


12

Kerberos isn't there as a convenience, it's an enhanced security measure. Convenience is a secondary benefit. A great explanation is Designing an Authentication System: A Dialog in Four Scenes Basically, instead of just passing a magic token around (ie. your password), you obtain a "ticket", which is signed by a trusted source of truth (ie. Kerberos KDC, ...


11

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.


10

It is possible using cookies. Cookies are nothing but small pieces of data (name-value pairs) that is stored in your browser by the web application you are communicating with. Every cookie has a domain associated with it and a cookie belonging to example.com can not be accessed by abc.com. It is important to note that whenever browser makes an HTTP request ...


10

TL;DR: You're not using a passphrase multiple times with OpenID, but have other parties (like Stack Exchange) trust your identity provider (like Google) to be carefully authenticating you. The passphrase (or any other authentication schema like two factor authentication, certificates and so on) only is revealed to the identity provider. Identity ...


10

TL;DR: Self-signed certificates are fine, and even recommended at least in some contexts. Use long validity times to avoid key rollover problems, and if RSA, use at least 2048-bit keys. SAML 2.0 includes the certificate that should be used for signature validation and as an encryption recipient as a part of the SAML metadata (technically, within the ...


8

To prevent lateral escalation. The administrative complexity of password management can be reduced by using a centralised password database, such as LDAP. However, doing so creates the risk of lateral escalation. If an attacker takes control of one server, they can remain silently present, sniffing passwords. These passwords can then be used to compromise ...


7

The metadata file doesn't have any sensitive information in it. It provides information that the SP can use to trust an assertion coming from [IdP] (so no one else can claim to be [IdP]). The typical information it contains are: SSO URL, issuer name, and the certificate containing the PKI "public" key. All of these are pretty much public anyway (as any user ...


7

The more passwords the user has, the harder they get to manage. They will forget their passwords more frequently, which means they will need to contact a helpdesk or an automated system to reset it. Such password reset procedures are often vulnerable to all kinds of different attacks. Helpdesk personnel can be tricked through social engineering and the ...


6

OAuth is flexible, and sometimes the OAuth flow is modified for application specific needs. The most common two flows are 2-legged and 3-legged, which if these flows are implemented correctly, then they are generally accepted as secure. The proposed CORS AJAX implementation of the OAuth flow violates two security requirements of RFC-6749 - OAuth 2.0 ...


6

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


6

This is one of those places usability and security cause radically different answers. From a usability standpoint I have observed the following arguments: When I logout on Site a I only logout form here and I can keep on using the other locations I am still logged into. When I press logout on Site a I actually only get redirected to Site b (the portal) ...


6

It seems to me this OpenID Connect scheme should do it. Note though that I'm not a security expert, so don't use it without further confirmation. User is unlogged to a.com, b.com, sso.com. User goes to a.com, clicks "Login". Redirect to sso.com, with return URL on a.com as param. User provides valid credentials. sso.com accepts them, redirects to a.com with ...


6

Encrypting the SAML assertion is optional. Whether or not it's encrypted, you still have privacy through the transport layer security. Scenarios where encrypting the SAML assertion should be considered include: the SAML assertion contains particularly sensitive user information; SAML SSO is occurring in a sensitive environment. Your understanding regarding ...


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


5

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


5

You are right in suspicion that storing all passwords in unencrypted notepad file is a bad idea. Good news is, systems you seek exist and they are called password managers. Password managers store passwords in secure way. They make you remember only login and a master password that gives you access to all the rest. For your case I'd recommend KeePass. It'...


4

Configure the ADFS login page to authenticate using windows authentication. Then the user should be automatically redirected back to the destination page without actually having to do anything. http://blogs.technet.com/b/abizerh/archive/2013/04/11/more-information-about-sso-experience-when-authenticating-via-adfs.aspx


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

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

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


4

It will pick off the low hanging fruit, but in general, it is not hard to spoof a header. I would say that if it has caused issues in the past, it is more than likely not worth the risk to your business apps.


4

Short answer: no. Long answer: it depends. Referer is a header sent and controlled by the client. You cannot trust any data coming unchecked from the client. As others pointed out, it can be easily manipulated. It can contain anything the attacker wants, so don't rely on it. If your URL contain any crypto token(http://site.com/x.php?op=1&token=-random-...


4

I have seen systems that filter by a list of allowed IP addresses first, so in order to even attempt to use an authentication method you have to be coming from a specified IP address or range. This is similar to what you are describing. But in general, authorization refers to deciding what an authenticated user can do, and so logically comes after the ...


4

A quick use of a search engine points me as the first hit to stackoverflow: Are Oauth2 client apps required to have SSL connection? which cites the OAuth 2.0 specification which can be summarized with: ... the authorization server MUST require the use of TLS ... The redirection endpoint SHOULD require the use of TLS ... Access token credentials MUST only ...


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