Hacker News Reader

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/

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.

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

Any thoughts on Atlassian Crowd?

http://www.atlassian.com/software/crowd/overview

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

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

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

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

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

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.

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

Can you please explain why using DSA to sign SSO tokens is a bad idea?

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.

The idea that public key algorithms are "more secure" than "shared-key" (symmetric, block cipher core) cryptography is exactly the opposite of true.

That seems backwards to me. How is having one key that can sign things be less secure than having multiple? If someone pwns a box with the shared key, they can forge credentials. If someone pwns a box with the public key, they can't. I would make sense to me that you'd want the important key that can be used to sign credentials in as few places as possible.

After fielding a custom-cryptography single signon system for your Ruby applications, you think your biggest concern is "how well will the system survive the loss of one of my app servers to an attacker"? Let me help you out with that: you won't survive the loss of one of your app servers. You're going to have to rebuild and rekey everything.

No, the biggest concern you have doing custom-cryptography for your Ruby apps is that the cryptography itself is going to hand attackers control of your app servers. Which, from experience, is somewhat likely. More likely if you haplessly use RSA or DSA.

Obviously you're going to rebuild compromised servers and change all the keys... as soon as you find out you've been hacked.

What about before then? You're advocating a scheme whereby if any verifier is compromised, the attacker can forge tokens. This isn't the case with a system that uses asymmetric crypto.

You're going to have to re-key because as soon as you got hacked the security of your SSO scheme is likely nil. When you find out about has nothing to do with anything.

In any case, no part of block cipher crypto requires every pair of participants to share the same key --- even in the unlikely even that you needed all-pairs keys (virtually all SSO systems have a star topology).

The idea that a system is going to resist forgery because it uses public key cryptography would be amusing if it wasn't so common. In reality, cryptography does not work the way _Applied Cryptography_ says it does; it works more like the way _Cryptography Engineering_ says it does. In other words: it conspires at all points and at all times to fuck you.

I'm seeing a lot of polemic and handwaving but missing substance, sorry.

What is the actual problem with RSA in this context, assuming OpenSSL is used correctly? What are the common pitfalls?

I'm definitely not providing all the substance, you're right.

I take it you're being sarcastic, but the negative comments you're receiving are I think because you departed from giving advice on implementation and strategy, and attempted to give a piece of cryptographic advice.

The only way anyone gets to imply that public key crypto is less secure, or more dangerous, without being challenged, is if a new attack is presented. Otherwise it's all innuendo and handwaving.

Most apps and sites may not derive any advantage from public key crypto, but you can't say that for sure until you see a site (or SSO multi-site) design.

I'm not being sarcastic. I'm simply not interested in going into more detail on this topic.

I don't think anyone who's opinion I care about on HN thinks I'm dealing in innuendo on crypto topics.

That didn't really answer my question, and you're changing the argument. You said, paraphrasing, "public key is less secure than shared key", which doesn't really make sense, for the reasons I already mentioned. Saying its all irrelevant because my app is already insecure is totally orthogonal to this sub-thread.

No, that's not all I said.