There is one thing that puzzles me when people talk about the business of Identity Management. It goes along the lines of “The idea is great and really needed (I myself manage X passwords), but there is no viable business model behind it!”

For example, in the recent (Feb 15th) Crypto-Gram Bruce Schneier writes:

Cryptographer Stefan Brands has a new company, Credentica, that allows people to disclose personal information while maintaining privacy and minimizing the threat of identity theft. … I know Stefan; he’s good. The cryptography behind this system is almost certainly impeccable. I like systems like this, and I want them to succeed. I just don’t see a viable business model. I’d like to be proven wrong.

See also a post by Marco Casassa Mont wondering what the business model might be.

And of course there are numerous emails that we receive here at SlashID - “it’s neat and looks very useful, but how are you going to make money?”

Do you see anything strange, or is it just me? How can something that is useful and needed have no business model? Business is about providing value and charging something in return. If you have a system that provides value (i.e. people may find it useful) you can ask for something back - like money or anything else.

In most cases, that “anything else” is just people’s personal data. Ever seen a cardboard box saying “drop your business card and win a free iPod”? This is how it can work with trusted Identity Providers. You pay with your privacy, if you are so inclined. This implicit “payment” can be used sometimes to describe a service as “free”. Well, if it’s not anonymous it’s not really free.

And this is where I think the root of the problem is. Internet is full of “free” services to the users - getting the payment implicitly through access to millions of records of personal data and possibilities of marketing, data mining and advertising revenue. Everybody does that, and it became a norm. And the key phrase - “User’s Don’t Pay!” - is now deeply rooted in the mind of anyone trying to make money online.

I think something is broken with it. If you ask me, I’d much rather pay a small sum of money (say, a buck a month) for the service that I need, than pay with my privacy.

Then it gets worse - websites are not only asking for your personal data, but also for your passwords on other sites - to import your contacts or show all your accounts on one screen, thank you very much. Some people already cry foul, and hopefully their voice is being heard. (Some would claim that OAuth solves this problem - but it only hides the passwords. You are still asked to authorize a third party website to access your sensitive data).

Unfortunately, we cannot count on the users to say “no” to services who have access to disproportionate amount of personal data - after all, people didn’t say “no” to mortgages with attractive interest rates… Besides a few security geeks, people don’t care. And this is why the common theme for now is “User’s Don’t Pay” - period.

Well, the recent subprime abuse was promptly followed by a subprime crisis. Do we need a trust and privacy crisis to follow the current trust and privacy abuse for people to learn to value their privacy? Time will tell.

Meanwhile, we are playing with fire.

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.