So it’s been really quiet on this blog for a while, but that doesn’t mean nothing was happening. I’ll be posting latest updates in the next little while.

One of the major developments is the work we’ve done with Greg Wilson of UofT, with his students, William Ho and Dmitri Vassiliev. Or, I should say, they have done the work with us.

William and Dmitri started to develop a Firefox extension that will allow the users to avoid taking sensitive JavaScript from SlashID, instead taking the code from the open source project. While on this initial stage not all JavaScript will be eliminated, the sensitive parts (password encryption/decryption) will be gone.

Also in the project are some anti-phishing features and shortcuts for more convenient logins.

The project is still ongoing, and the project blog is here. Also, there is a video describing the project.

Thanks a lot to these guys for the great work so far. I’ll keep updating the blog with the progress.

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.

The Founders and Funders event this past Monday was another terrific event hosted by David Crow and Jevon MacDonald. It really gave everyone a chance to engage with each other without the pressure of giving “the pitch”.

We are in the process of creating awareness of our technology, so this was an excellent venue for us. Everyone I spoke with was very receptive and understood our message and value proposition. Both from a user who has too many userID’s and passwords. The Web site owners I met with are also concerned about their abandonment rate.

We are scheduled to present in Waterloo on February 26th at StarupCamp Waterloo, so we hope to see you there.

We were very happy to see Mozilla’s recent announcement about the new Weave project. The goal of the project is to take various personalized data and push it “into the cloud” using client-side encryption. As things look right now, Weave will not be providing specific services such as calendar, but will provide the basic framework for implementing some of them. Judging from the use cases, the project for now seems to be focused on seamlessly transferring the browsing experience from one machine to another - such as bookmarks, browsing history and so on.

It’s nice to see more and more people taking the approach of pushing things into the cloud using client-side encryption. This is what SlashID is doing with identity management. Our hope is that the benefits of SlashID will become more obvious to more people as this approach proliferates.

One question I have to answer frequently - is SlashID a Single Point of Failure (SPOF)? For example, here we are said to “have a significant SPOF”.

SlashID is a “centralized” service (just because there is no other SlashID around), so looks like “centralized” automatically means “SPOF”. How come?

First of all, we can “fail” in two ways - our server can go down, or it can be broken into or otherwise compromised. If we are down, you cannot login using SlashID, but you are not locked out of all your online accounts. You just use a “forgotten password” option on a website, and you should be able to login with a new password they send to you. So, if SlashID server is down, it will cause inconvenience, but it will not lock you out of your internet access. It will also not be a significant business continuity risk for the Relying Party, since their customers are still logging in.

If our server is compromised (including our secret keys), the attacker cannot get access to any data until they successfully guess your password. The problem is that now they can do it “offline”. So your protection is as strong as your password is - that’s why we require strong passwords when you register. Without our server being compromised, nobody can even try to guess your password - they will have to come to us to check every attempt, and we won’t be very helpful when we see them hit our server hundreds of times…

So we are “centralized”, but not really a “SPOF” - our failures don’t lead to catastrophic consequences, just to minor inconvenience if our server goes down, and increased risk (as opposed to total failure) if our server is completely compromised. There are ways to reduce or even eliminate this risk by turning SlashID into multiple unaffiliated servers which split the secret keys between them. This is something we will happily do in the future if we see the demand.

Some people have wondered what the relationship is between SlashID and OAuth.

Well, just like OpenID has nothing to do with OAuth, neither does SlashID.

OAuth is a protocol that allows one service to get access to protected data on another service, if the user authorizes it to. In order to authorize the access, the user has to authenticate to that service first, then do the authorization. OAuth covers the authorization process, but leaves the authentication part open. This is where OpenID, SlashID or any other type of authentication comes in.

So, SlashID is not “just an implementation of OAuth“. Neither is it an alternative to OAuth. SlashID and OAuth can work together, and in fact they would fit quite well.

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

We attended StartupCamp last night, and it was amazing. Thank you Jevon and Jonas our hosts from Startup North, and to the sponsors for the beer and pizza!

One thing that I was most impressed with is the amount of interest the investment community has in the Toronto startups. Since we are new to this and maybe a bit naive, it sure gives you hope, and a chance to practice with your pitch.

We didn’t have a chance to present, but we did meet a lot of new people and signed up a few web sites that want to enable our technology. More on that later.

This event was a clear hit and I am sure there will be more to follow.

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.

We had a great time at the Toronto DemoCamp. The demo went well (read: it worked), and we got lots of questions and feedback.

You can watch the video of the SlashID demo in Hi Resolution (161 Meg) or Low Resolution (83 Megs) - or watch it on YouTube.

I think we managed to get our message across, and got some very interesting contacts and new opportunities. So a big thank-you to the organizers and everyone who showed up, that was a great event.