Why in browser single sign on matters ?

As those days , it happens that we visit frequently the topic of in browser single sign on , we think interesting to clarify why we see value in such technology. The two main benefits that single sign on can deliver are :

• Help maintaining diversity of the web ecosystem
• Ease securing web applications

Maintaining biodiversity in the web ecosystem :

The lake of easy registration/sign on accross the large number of applications that are currently being maintained on the web , renders difficult the emergence of second movers.

Introducing GateKeeper , in browser single sign on extension

We think interesting to share with the community a development on which the KerPass engineers are currently working. The shot above shows the GUI part (xul widget) of the extension that shows in the browser at time an authentication request has been received. The extension allows relying website to require end user to authenticate at authentication portails that the relying site trusts for this purpose. GateKeeper is the much needed missing part for in browser single sign on to happen reliably on the web.

Universal security token , pictures …

Some pictures of the coming soon mobile universal security token together with related user stories. For our fellow mobile application developers , during development we try to test on real devices as early as possible and we use for this a low end device. This allow being more efficient in adressing real world issues , as simulators are generally not matching well real device performances.
Phone display photographing is a pain , fortunatly we found a helpfull girl who knows …

First start :

As the token requires network access , we first check that the device connection has been correctly parametrized. We found good inspiration by looking to Opera mini for this. If only mobile operators were trying to help here by documenting clearly the settings for their APN on a per device basis.

InfoCard/CardSpace getting the big picture …

Recent posts on this blog suggest our interest in “open” in browser single sign on systems. As a result we have been discussing briefly perceived strengths and weaknesses of yahoo BBAuth and emerging OpenId standards. Regarding OpenId , it has appeared to us that the enthousiasm of the community is unfortunatly not backed by sufficient technology to make the system applicable in the context of the wild open Internet. The recent announcement that CardSpace and OpenId are engaging into a mariage allow microsoft to capitalize on the buzz created by OpenId. We now see OpenId as a void shell (a remarkable online marketing success though …) , the stringent question that remains to be addressed is what is the value of this CardSpace stuff ?

Paypal , password key fob goes mainstream …

It is official for about a month that Paypal will offer to its users a password key fob , in order to protect them better against identity theft. They will distribute the one time password key fob of Verisign for this.

This will certainly help in protecting Paypal users against identity theft , as this makes password guessing extremely difficult meanwhile the user is offline , however it is not correct to report that this will solve the problem of phishing . A phisher can capture a time synchronous one time password in much the same way he can capture a standard password and reuse it for its own purpose.

One time passwords have been a milk cow for security firms like RSA security and Vasco for years. They provide a strong end user proof of identity , however some innovation is required to make them suitable for being used securely in the context of web applications. The bad idea here is to assume that if used alone passwords can be moved on the network…

Transaction validation : part 2 , ECDSA signatures

Electronic signatures as offered by public key cryptography have impressing capabilities , combine those with the ubiquituous mobile phone and a global validation service that can be accessed from anywhere and you start seing many of the problems that are plagging today online electronic transaction as solved.

What we will show today is the way we integrate the token ECDSA signature capabilities with relying external web application. We take the view that end users will continue to use the desktop browser for the years to come , so part of the problem is how to integrate the on desktop accessed web application with the mobile token.

Transaction validation : part 1 , password signatures

The current KerPass token only provide for end user authentication using OATH one time passwords. The new KerPass token (code name “universal security token”) will additionnaly provide solutions for transaction validation using two differents technologies : password signatures and ECDSA electronic signatures. In this post we will discuss how password signatures are working and what are the benefits of using them.

A few words first on what is meant by transaction validation. The idea here is to allow a end user in control of a workable token to proove that he really agree with the content of a transaction , he is supposed to have been engaged… A simple example of transaction is an online payment , how do you reinsurre your bank and/or the seller that you are really the initiator of such transaction ? It is well known that this is a problem not reliably solved in current Internet. Our new mobile token will allow the end user to give a strong proof of his approval of such transaction. Let’s see how this can be simply achieved with password signatures:

Holdup on OpenId …

Meanwhile we were busy trying to evaluate if OpenId was an attractive in browser single sign on protocol , it looks that things have changed drastically on this side with the announcement of the alliance with microsoft cardspace.

It will be interesting to see how the dust will settle and if all the contributors that have invested valuable time and ressources in this effort feel happy about this move. On our side we have been following closely what was going on here , as we considered for a while that our strong authentication technologies could be used in the context of OpenId identity provider portails.

French TV has found it : sms can be spoofed …

A report made the headline of the French national news of yesterday (February 5th 2007) that it is actually possible to make a sms appear to come from a person that has not sent it. It took apparently a Belgian engineer to convince the French police that this is easy to achieve , and french mobile operators have acknowledged that this is a problem the technology has.

OpenID , BBAuth some interesting differences …

We often read that OpenID and yahoo BBAuth are very similar in principle. While this hold largely true , it looks interesting to us to see where those two protocols differ.

First of all BBAuth and OpenID have different objectives :

• BBAuth allows to reuse yahoo authentication (yahoo_identifier , password ) into websites (we call them Relying Party ) that have an agreement with yahoo (acting as Identity Provider) to allow so.
• OpenID for its part try to solve a more challenging problem , where a potentially large number of websites (Relying Party…) rely on a federation of Identity Provider to authenticate their end users…