7 ms·

Building and implementing a Single Sign-On solution

67 points by raganwald 15y ago

tptacek 15y ago
The cookie doesn’t need to contain a lot of data, its value can contain the account id, a timestamp (to know when authentication happened and a trusted signature) and a signature. The signature is critical here since this cookie will allow users to be automatically logged in other sites. I’d recommend the HMAC or DSA encryptions to generate the signature. The DSA encryption, very much like the RSA encryption is an asymmetrical encryption relying on a public/private key. This approach offers more security than a shared secret like HMAC does. "Yes, definitely build custom crypto for your single signon system, especially if you think HMAC is an "encryption" but just "not as secure" as DSA because it's "shared secret"." SSO schemes are one of the primary reasons people build crypto for their web apps (they don't want the database dependency between the shared apps). These schemes usually fail calamitously, sometimes a year or two into production, when your app coughs up the ability for one person to log in as any other person without a password. If you have a real app with a real customer base or doing real revenue and feel the need to put something like this in the field, please ping me. I'm not going to try to charge you. I may try to talk you out of it, though. I will absolutely talk you out of using RSA or DSA.
- ovi256 15y ago
  Thanks for the expert feedback. From my very limited sec experience, I saw account_id in cookie, and identified that as a red flag. OTOH, I think a random token in the cookie, identifying a server-side session that stores the account id, would be a good approach, as it's the classical HTTP auth implementation. For example, what the Rails tutorial describes [1]. For SSO, the other apps can ping the cookie-originating app: "Hey, who is this browser with this cookie token" ? [1] http://ruby.railstutorial.org/ http://ruby.railstutorial.org/
  - tptacek 15y ago
    That's a fine approach, but developers push back on it because it requires all the apps in the SSO federation to be connected at all times. Most shops should just accept that requirement and get on with their lives, though.
  - route66 15y ago
    This is more or less the way SAML [1] works, at least in one of it's protocols. The authentication server redirects (after successful login) to the initiating service and supplies an assertion-token, often with limited validity. With that assertion token more data can be asked from the servers to the auth-server directly. No account_id's go over the wire, the cookie needs only to be valid on the authentication server. And you should really need it, it's not much fun to implement. 1 http://en.wikipedia.org/wiki/SAML_2.0#Artifact_Resolution_Protocol http://en.wikipedia.org/wiki/SAML_2.0#Artifact_Resolution_Pr...
- julianb 15y ago
  Any thoughts on Atlassian Crowd? http://www.atlassian.com/software/crowd/overview http://www.atlassian.com/software/crowd/overview
  - tptacek 15y ago
    I've never gotten a chance to look at it. Presumably someone has reviewed it; Atlassian's a decently big company. You could probably ask them. (Note also that if we had reviewed them, we probably wouldn't be able to talk about it here. But: we haven't.)
- mattetti 15y ago
  Thanks for correcting my abuse of language. I should have reviewed my post in detail. I did fix that now. That said, while I appreciate your perspective, I'm quite disappointed that you aren't offering any solutions besides asking people to contact you.
  - tptacek 15y ago
    "Abuse of language"? You suggested that HMAC was an alternative to DSA. That's not a semantic nit. Signatures, by the way, are not the same thing as message authentication codes. And like I said: nobody should be using RSA or DSA for SSO tokens. Offering solutions on how to implement a secure single signon scheme with RSA or DSA on Hacker News is like explaining how to perform an appendectomy in Youtube comments. Sorry, not interested in hurting people. I know I sound super snippy here, and I'm sorry about that, but this problem comes up a lot. We keep finding applications that get almost everything right; locked down database layer, bulletproof authorization, reliable output filtering to stop Javascript injection... and then they go build single signon, and 3 days after we see that we can turn a guest account into the sitewide admin. People would be a lot better off if they did not try to build this particular feature themselves. (We don't build SSO systems for people, in case you think this is a sales pitch.)
    - bascule 15y ago
      Can you please explain why using DSA to sign SSO tokens is a bad idea?
      - tptacek 15y ago
        Bignum cryptography is more dangerous than block cipher cryptography and (in secure systems) invariably depends on hash functions anyways (they're the worst of both worlds). The idea that public key algorithms are "more secure" than "shared-key" (symmetric, block cipher core) cryptography is exactly the opposite of true. Meanwhile, the utility of public-key cryptography in SSO systems is minimal. Public key is useful, and sometimes the only viable solution, when you have a potentially unbounded population of verifiers or signers. But that's never the case in SSO schemes, which have a bounded number of cryptographic participants (or, if they don't, are badly broken). Long story short: public key crypto is a last resort for systems that can't be deployed in any other way.
- euroclydon 15y ago
  Encryption is some funny stuff. I worked on a team that implemented SSO between an ASP.NET app and a PHP app. We used AES with a shared key and IV. That was it. We just shoved the encrypted user token and timestamp into a domain cookie. But I guess we should have also signed the encrypted value to know that we generated it? What's the process to break this scheme? 1) Know what type of value is being encrypted: email, username, tokenid 2) Gather several pairs of usernames/encrypted usernames 3) Use some brute force method to uncover the key and IV 4) generated fake cookies since you know the key/IV
  - tptacek 15y ago
    It's trivial to figure out what encryption scheme† is being used for a cookie or HTTP parameter as long as any portion of the plaintext being encrypted is influenced by something an attacker can control directly or indirectly. If you're not authenticating your ciphertext, you might as well not encrypt it; attackers can rewrite the plaintext, if not outright decrypt it (the adaptive chosen plaintext attacks on AES block modes all rely on messages not being authenticated). I'd enjoy talking more about the methods to break this stuff but am concerned that HN will read that comment as "well then we just need to stop those attacks and then we're safe". I have roughly 5 years of experience on HN to back that concern up. :) † (At least, with enough specificity to attack it.)
    - euroclydon 15y ago
      Thanks. I Googled Adaptive Chosen Plaintext Attacks, and it seems to me that the statement, "attackers can rewrite the plaintext" needs to be qualified with, "given liberal access to the encrypting mechanism", which I guess means free access to create new accounts in an SSO situation (or access to some other web-method that used the same encryption).
      - tptacek 15y ago
        "Chosen plaintext" means that the cipher can't tell if what it has decrypted was what the original authentic encryptor encrypted. "Adaptive" means that the attacker gets repeated attempts to break the same piece of ciphertext. The canonical example of an adaptive chosen plaintext attack is the AES CBC padding oracle, but there are multiple others.
bdunbar 15y ago
This might be the right place to ask but ... is there a reason people keep reinventing SSO? It's 2012. The first place I saw SSO was on a Banyan VINES network, in 1990. Years, I hasten to add, before NetWare figured it out. We've got it, still, in the enterprise. It's now Active Directory, but I can use my same credentials for login and auth on Windows clients, unix machines, two different web apps from as many external providers. Note, I have no idea how the web apps obtain my login credentials, save that the AD guy and the web guys did some black magic behind the scenes. Why do people keep re-inventing SSO, sometimes badly? No way to make a black box that Just Works?
- bmelton 15y ago
  What is the 'de facto' answer for environments where AD isn't present? I was going to say something about AD not supporting SAML, or federation, but it appears that my knowledge is dated. But in an enterprise where there are no Windows machines (to my knowledge,) much less Windows servers, what's the fill-in? *Edited the snark out.
  - JoachimSchipper 15y ago
    I think the standard UNIX-flavoured solution is LDAP+Kerberos, which is pretty much AD without the gratuitous incompatibility and useful extras.
  - bdunbar 15y ago
    Good question. I'm familiar with two 'unix' networks that stood apart from the windows networks in an enterprisey setting. - NIS+ - Scripts to copy a 'master' /etc/passwd to all other unix hosts. Keep the master under version control. But I've been here for over a decade. When I got here we were using vintella which hooks the unix hosts into AD.
  - kprobst 15y ago
    A lot of enterprises use SiteMinder (aka ChannelSecure), which used to be Netegrity's before they got bought out by CA. It supports both Apache and IIS, although I'm not 100% sure what the policy servers run on, it might be Windows. But I have seen LAMP apps that integrate with it, for example. It really is just an intercept-and-forward system that functions as a module on the web server and puts a few things on the HTTP headers to allow apps to handle authorization by themselves.
jondot 15y ago
You might also want to examine the OpenID way, in which case you can use for example, this https://github.com/jondot/passage https://github.com/jondot/passage, or this https://github.com/dbloete/masquerade https://github.com/dbloete/masquerade (depending on how complex the project you want to build on)
famoreira 15y ago
Would openID be a good option for a SSO solution? If so what would be the best way to implement a openID server using Ruby?
- etdebruin 15y ago
  Check out https://github.com/dbloete/masquerade https://github.com/dbloete/masquerade I haven't used it.

67 points by raganwald 15y ago

The cookie doesn’t need to contain a lot of data, its value can contain the account id, a timestamp (to know when authentication happened and a trusted signature) and a signature. The signature is critical here since this cookie will allow users to be automatically logged in other sites. I’d recommend the HMAC or DSA encryptions to generate the signature. The DSA encryption, very much like the RSA encryption is an asymmetrical encryption relying on a public/private key. This approach offers more security than a shared secret like HMAC does. "Yes, definitely build custom crypto for your single signon system, especially if you think HMAC is an "encryption" but just "not as secure" as DSA because it's "shared secret"." SSO schemes are one of the primary reasons people build crypto for their web apps (they don't want the database dependency between the shared apps). These schemes usually fail calamitously, sometimes a year or two into production, when your app coughs up the ability for one person to log in as any other person without a password. If you have a real app with a real customer base or doing real revenue and feel the need to put something like this in the field, please ping me. I'm not going to try to charge you. I may try to talk you out of it, though. I will absolutely talk you out of using RSA or DSA.

ovi256 15y ago
Thanks for the expert feedback. From my very limited sec experience, I saw account_id in cookie, and identified that as a red flag. OTOH, I think a random token in the cookie, identifying a server-side session that stores the account id, would be a good approach, as it's the classical HTTP auth implementation. For example, what the Rails tutorial describes [1]. For SSO, the other apps can ping the cookie-originating app: "Hey, who is this browser with this cookie token" ? [1] http://ruby.railstutorial.org/ http://ruby.railstutorial.org/
- tptacek 15y ago
  That's a fine approach, but developers push back on it because it requires all the apps in the SSO federation to be connected at all times. Most shops should just accept that requirement and get on with their lives, though.
- route66 15y ago
  This is more or less the way SAML [1] works, at least in one of it's protocols. The authentication server redirects (after successful login) to the initiating service and supplies an assertion-token, often with limited validity. With that assertion token more data can be asked from the servers to the auth-server directly. No account_id's go over the wire, the cookie needs only to be valid on the authentication server. And you should really need it, it's not much fun to implement. 1 http://en.wikipedia.org/wiki/SAML_2.0#Artifact_Resolution_Protocol http://en.wikipedia.org/wiki/SAML_2.0#Artifact_Resolution_Pr...
julianb 15y ago
Any thoughts on Atlassian Crowd? http://www.atlassian.com/software/crowd/overview http://www.atlassian.com/software/crowd/overview
- tptacek 15y ago
  I've never gotten a chance to look at it. Presumably someone has reviewed it; Atlassian's a decently big company. You could probably ask them. (Note also that if we had reviewed them, we probably wouldn't be able to talk about it here. But: we haven't.)
mattetti 15y ago
Thanks for correcting my abuse of language. I should have reviewed my post in detail. I did fix that now. That said, while I appreciate your perspective, I'm quite disappointed that you aren't offering any solutions besides asking people to contact you.
- tptacek 15y ago
  "Abuse of language"? You suggested that HMAC was an alternative to DSA. That's not a semantic nit. Signatures, by the way, are not the same thing as message authentication codes. And like I said: nobody should be using RSA or DSA for SSO tokens. Offering solutions on how to implement a secure single signon scheme with RSA or DSA on Hacker News is like explaining how to perform an appendectomy in Youtube comments. Sorry, not interested in hurting people. I know I sound super snippy here, and I'm sorry about that, but this problem comes up a lot. We keep finding applications that get almost everything right; locked down database layer, bulletproof authorization, reliable output filtering to stop Javascript injection... and then they go build single signon, and 3 days after we see that we can turn a guest account into the sitewide admin. People would be a lot better off if they did not try to build this particular feature themselves. (We don't build SSO systems for people, in case you think this is a sales pitch.)
  - bascule 15y ago
    Can you please explain why using DSA to sign SSO tokens is a bad idea?
    - tptacek 15y ago
      Bignum cryptography is more dangerous than block cipher cryptography and (in secure systems) invariably depends on hash functions anyways (they're the worst of both worlds). The idea that public key algorithms are "more secure" than "shared-key" (symmetric, block cipher core) cryptography is exactly the opposite of true. Meanwhile, the utility of public-key cryptography in SSO systems is minimal. Public key is useful, and sometimes the only viable solution, when you have a potentially unbounded population of verifiers or signers. But that's never the case in SSO schemes, which have a bounded number of cryptographic participants (or, if they don't, are badly broken). Long story short: public key crypto is a last resort for systems that can't be deployed in any other way.
euroclydon 15y ago
Encryption is some funny stuff. I worked on a team that implemented SSO between an ASP.NET app and a PHP app. We used AES with a shared key and IV. That was it. We just shoved the encrypted user token and timestamp into a domain cookie. But I guess we should have also signed the encrypted value to know that we generated it? What's the process to break this scheme? 1) Know what type of value is being encrypted: email, username, tokenid 2) Gather several pairs of usernames/encrypted usernames 3) Use some brute force method to uncover the key and IV 4) generated fake cookies since you know the key/IV
- tptacek 15y ago
  It's trivial to figure out what encryption scheme† is being used for a cookie or HTTP parameter as long as any portion of the plaintext being encrypted is influenced by something an attacker can control directly or indirectly. If you're not authenticating your ciphertext, you might as well not encrypt it; attackers can rewrite the plaintext, if not outright decrypt it (the adaptive chosen plaintext attacks on AES block modes all rely on messages not being authenticated). I'd enjoy talking more about the methods to break this stuff but am concerned that HN will read that comment as "well then we just need to stop those attacks and then we're safe". I have roughly 5 years of experience on HN to back that concern up. :) † (At least, with enough specificity to attack it.)
  - euroclydon 15y ago
    Thanks. I Googled Adaptive Chosen Plaintext Attacks, and it seems to me that the statement, "attackers can rewrite the plaintext" needs to be qualified with, "given liberal access to the encrypting mechanism", which I guess means free access to create new accounts in an SSO situation (or access to some other web-method that used the same encryption).
    - tptacek 15y ago
      "Chosen plaintext" means that the cipher can't tell if what it has decrypted was what the original authentic encryptor encrypted. "Adaptive" means that the attacker gets repeated attempts to break the same piece of ciphertext. The canonical example of an adaptive chosen plaintext attack is the AES CBC padding oracle, but there are multiple others.

bdunbar 15y ago

This might be the right place to ask but ... is there a reason people keep reinventing SSO? It's 2012. The first place I saw SSO was on a Banyan VINES network, in 1990. Years, I hasten to add, before NetWare figured it out. We've got it, still, in the enterprise. It's now Active Directory, but I can use my same credentials for login and auth on Windows clients, unix machines, two different web apps from as many external providers. Note, I have no idea how the web apps obtain my login credentials, save that the AD guy and the web guys did some black magic behind the scenes. Why do people keep re-inventing SSO, sometimes badly? No way to make a black box that Just Works?

bmelton 15y ago
What is the 'de facto' answer for environments where AD isn't present? I was going to say something about AD not supporting SAML, or federation, but it appears that my knowledge is dated. But in an enterprise where there are no Windows machines (to my knowledge,) much less Windows servers, what's the fill-in? *Edited the snark out.
- JoachimSchipper 15y ago
  I think the standard UNIX-flavoured solution is LDAP+Kerberos, which is pretty much AD without the gratuitous incompatibility and useful extras.
- bdunbar 15y ago
  Good question. I'm familiar with two 'unix' networks that stood apart from the windows networks in an enterprisey setting. - NIS+ - Scripts to copy a 'master' /etc/passwd to all other unix hosts. Keep the master under version control. But I've been here for over a decade. When I got here we were using vintella which hooks the unix hosts into AD.
- kprobst 15y ago
  A lot of enterprises use SiteMinder (aka ChannelSecure), which used to be Netegrity's before they got bought out by CA. It supports both Apache and IIS, although I'm not 100% sure what the policy servers run on, it might be Windows. But I have seen LAMP apps that integrate with it, for example. It really is just an intercept-and-forward system that functions as a module on the web server and puts a few things on the HTTP headers to allow apps to handle authorization by themselves.

jondot 15y ago

You might also want to examine the OpenID way, in which case you can use for example, this https://github.com/jondot/passage https://github.com/jondot/passage, or this https://github.com/dbloete/masquerade https://github.com/dbloete/masquerade (depending on how complex the project you want to build on)

famoreira 15y ago

Would openID be a good option for a SSO solution? If so what would be the best way to implement a openID server using Ruby?

etdebruin 15y ago
Check out https://github.com/dbloete/masquerade https://github.com/dbloete/masquerade I haven't used it.