Somehow discussion about SlashID and OpenID security always ends up in these abstract debates around “wouldn’t you trust Verisign” and “can a breach on the Idnetity Provider side affect your account” etc. That’s not actually a discussion about security.

Security is about analyzing specific threats, risks and attacks. It is about accepting or mitigating those risks based on the value of assets and cost of their protection. These are objective things we can reason and have a constructive discussion about.

So here is a table that summarizes the differences between OpenID and SlashID based on specific threats. To indicate how probable (or “difficult”) a particular attack is I just used an (over-)simplified scale, explained below.

In the table above, “Identity Provider” does what it does because it’s hacked into, is under court order, has a malicious employee, or just for the fun of it.

My simplified difficulty scale is:

1. The attacker already has the data (No-op)
2. Easy (achievable by simple attacks on the network layer) and untraceable
3. Easy (achievable by simple attacks on the network layer), but with a risk of being caught
4. Equivalent to breaking weak key (<40 bits)
5. Equivalent to breaking medium key (up to 56 bits)
6. Equivalent to breaking any stronger key

With OpenID, the user authenticates to the OpenID Provider. After a successful login, the OpenID Provider will issue an assertion saying that the authentication was successful. Since nothing prevents the provider from issuing an assertion without the authentication actually taking place, we can say that he can impersonate the user anytime. Therefore, the difficulty is “1″.

SlashID/JavaScript is the current solution we have. Instead of sending your password to SlashID, we use JavaScript to decrypt your shared secrets, which are then sent to the website. Since you are getting JavaScript from our website, we could inject a Trojan code that will send us back your password without you noticing. But, if somebody inspects the JavaScript code or the network traffic, this will be detected. Therefore, the difficulty is “3″.

SlashID/Browser Plugin is the same service, but with a browser plugin (which we plan to create and release as Open Source). This will remove the need to take any JavaScript from our website. Since the code will be open and maintained by the Open Source community it will be impossible for us to inject any Trojan lines without anyone noticing. Therefore, we would need to crack your password directly to get access to your encrypted data. However, your password is enforced to be 40 bits strong, with 7 more bits added by using 128 hash iterations when turning your password into encryption key. Therefore, the difficulty is “5″.

And the strongest configuration, SlashID/Decentralized will enable key splitting between different unaffiliated services. No single organization will be able to even attempt to crack your password, so the attack becomes nearly impossible.

The upgrade from one of these modes to the next does not require changes on the Relying Party (the website) side.

That’s it! Now, how acceptable these risks are (in each situation) is really up to the Relying Parties, because, well, they rely on these things. Their decision will depend on the value of their assets and their “risk appetite”. We (SlashID) cannot affect their decisions, but we can offer our Identity Management service, as well as an upgrade path towards more secure solutions.

(Of course, in reality, as soon as you get to levels “5″ or “6″ on the difficulty scale, the attacker will switch to other, often non-technical means. For more details on how to reason about these things see Bruce Schneier’s work on Attack Trees).

Many people discuss HushMail these days, in light of the recent story. The data from the secure email service was leaked to the FBI, which used it to bust an illegal steroid ring.

Of course those people are all bad, and it’s good that they have been caught. But this brings back the old question about the security of HushMail and similar services.

So I’m writing about it because we’re running one such “similar service”. The common theme between SlashID, HushMail, and the rest of us is the same: we all provide the untrusted service, and we also provide the code needed to access this untrusted service. HushMail provides Java bytecode, while SlashID provides JavaScript.

When you take code from somebody and then run it on your computer, you are taking the word of the author of the code that it does what you think it does. In other words, we claim that your password never leaves your computer, and you have to either inspect the JavaScript by yourself or take our word for it. How secure is that compared to the “real” security, where you download and install your own client software?

Bruce Schneier wrote an essay about this back in 1999 (when HushMail first appeared), so these issues are pretty well known by now. This is straightforward that having your own client is better than trusting the “untrusted” provider to provide you the code.

So the obvious question is then, why bother? Why not use Yahoo/Gmail instead of HushMail? And why not use OpenID instead of SlashID? Those are trusted providers which have access to your sensitive data - but at least they are upfront about it. And they promise not to give your data to anyone.

This is a real question that I heard from quite a few security people while discussing SlashID, and it was posed as a serious objection to its usefulness. The argument went something like this: “If stealing user’s password is not “cryptographically hard”, then it’s essentially a “no-op”. If so, I’m just as good with OpenID as I am with SlashID or other assertion-based solution. Why bother developing the new scheme?”

To answer that, we first need to agree that generally, an untrusted service (hypothetical one - even if SlashID doesn’t qualify) is better than a trusted one - in fact, much better. This is simply because an untrusted service can’t harm me even if they want to, whereas a trusted one promises not to harm me, even though they could. I would always prefer lack of ability over a promise, because promises can be broken, while abilities cannot magically appear. I think this point is also well-understood today.

So back to the original question - if injecting a malicious statement into the JavaScript is a “no-op”, we can (just for a moment) call SlashID “trusted” - i.e. one that requires trust. Just like OpenID does. Now, what is the advantage of SlashID? Well, since “untrusted” is better than “trusted”, let’s see what it takes to convert OpenID to untrusted. To do that, Identity Providers have to stop issuing assertions. They also have to give up access to cleartext user data. In other words, they have to become SlashID, meaning total re-architecture of the standards, changing code on Relying Party side as well as Identity Provider.

Now, let’s see what it takes to make SlashID untrusted “again”. Very simple - write a browser plugin that does whatever SlashID does, release it under GPL and make it downloadable from somewhere else - not from our website. That’s it - we’re untrusted again. And this time it’s “for real” - no “no-ops” or other tricks. If FBI shows up and wants us to disclose some data, guess what, we’d love to help, but we have no control whatsoever besides shutting down these accounts (which by the way will not help much, since we are not a SPOF - but that’s a topic for a different post…). No changes to the protocol and no code changes on the Relying Party or the Identity Provider are required.

In other words, in SlashID case, there is a certain amount of trust embedded in the particular implementation of the technology, but not in the technology itself. So in essence, even if SlashID does not eliminate trust completely, it puts it into such form that it can be easily removed in the (hopefully, near) future.

To me, it’s a big deal - in fact not less important than to actually eliminate the trust. Think about how you handle garbage at home - most of your time and effort is spent to collect it in one place so it can be conveniently taken out in one simple operation later on. This is what we want to do to trust - to eliminate it eventually, but we have to do it one step at a time.