Enhancing the Firefox Password Manager with OpenID


With Blogger announcing beta support for OpenID, the idea of federation sure is catching up. In addition, active support with CardSpace would apparently increase the adoption. However, till the time this technology becomes mainstream, people are still going to be bogged down with the problem of multiple passwords.
Just recently, the draft of OpenID 2.0 has graduated to the final stages, and many providers would be implementing the specifications. The service providers however would still take time to catch up. This article is an extension of my previous work on signon manager, trying tdyo formally describe the idea of extending the firefox password manager to become portable and secure. Currently, all passwords are stored in the local stored, encrypted by a master password if required. Hence, when a user hits the web on another system, and if he cannot remember the passwords, he cannot really login to the sites.
To start with, the user would have to setup the password manager by specifying the OpenID server, and authenticating with it.
In case of the extended Firefox password manager, when the user click the "Remember Password", the extension would make a call to a remote OpenID server, and store the username/password that are sent over a secure connection. Now, the user visits the service provider, and types in the credentials for the first time. On hitting the "Remember password" button in the dialog that pops up, a remote request is made to the OpenID server to store the credentials that are sent over a secure channel. As there is no explicit way to tell the OpenID to "store" user attributes, this has to be achieved by screen scraping.
Subsequently when the user visits the site, the password manager would get the credentials from the remote site (if the user is authenticated to that site for the session). If the user is not authenticated, an authentication page of the OpenId IDP is shown. This transaction would flow using the attribute exchange protocol in OpenID 2.0.
Though I am not planning to work on the extension manager in the near future, I am definitely trying to integrate this with the SignON Manager that I had been working on for some time now. Given that case, the user would be a step close to single sign on as he will not be require to hit th e Login Button. More like a faked-single-sign-on !! :)

SezWho :: Analysis of an Identity Based Commenting System

At the last Barcamp, there was a talk by Jitendra Gupta of a startup called SezWho. In the words of the company, SezWho is a distributed context, rating and reputation service for blogs, forums, wikis and other social sites. It provides WordPress plugins that show up a rating system for comments on a blog. The biggest advantage is the possibility of carrying over the comments to other blogs that have this embedded.
However, there still are some fundamental technical questions that have not been answered. When a user wants to comment on a site, his identification solely relies on the email address provided. However, no confirmation about the user is actually used. Simple script can hence change the reputation of a person rapidly.
Additionally, with services like a temporary inbox, the genuine reputation of any user can be very easily tampered with, even if confirmation mails are provided. Providing random emails would only make SezWho believe that the ratings have been submitted by a first time user. The argument that the algorithms at SezWho would not allow drastic rating changes also would not stand as sites with heavy traffic do change reputation of people drastically.
The root of all these problems is the fact that at no step in the flow is the authenticity of the user checked. Though it is easier by not requiring the users to register, it opens up a lot of potential to spam. Hence, I would imagine that it would be a lot easier to use existing Identity Systems, and leave the assurance of authenticity of the users to them. Infact, instead of asking for the mail id, the user could be required to supply his OpenID at the same place. Since it is the blogging platform, I guess that the distribution of OpenID should be a lot more than the distribution of SezWho.
As an alternative, if a user does not have an OpenID account, SezWho can offer the user to provide an OpenID account, thereby ensuring authentication in subsequent transactions. Thus, instead of asking for the email address in the popup dialog, the site would not ask the user to enter his OpenID, and then popup a dialog (belonging to the OpenID provider, in an iFrame) to authenticate the user, or get user consent.

To summarize, it apparently looks like SezWho does not really emphasize on the authenticity o the users who rate comments. This is a task that can be performed by any Identity system like OpenID. If you this that the scheme described above has flaws, I would love to discuss them.

CardsSpace as a Password Protection Module


Since the inception of FORMS in HTML, nothing really has changed for the password input fields. Though password is supposed to be secret and holds the key to a user's session, it is treated at par with the other fields in the FORM, differentiated only by an attribute. There seem to be no real standards that mandate the way this "form data" is to be sent to the server in a protected manner. Though sites do use SSL or Hash the passwords, many still send them as plain text. Additionally, keylogger malware and phishing attacks against passwords are common. To protect against this, people have on screen keyboards and other mechanisms, but the environment is still very unprotected.
People have tried to overcome this limitation by giving elevated status to the the password collection by collecting credentials in a secured environment. This patent details the idea of protecting the passwords on the web against various threats.
It has been quite some time I had been working on CardSpace and I was wondering if CardSpace can actually be used as a password protection module. The architecture of CardSpace claims that the Identity Selector is a protected environment for the Windows Operating System. As discussed in the architecture presentation, no external programs can have a hook to this protected environment, that is supposed to be similar to the Windows login (or the Ctrl+Alt+Delete) screen.
The business case for using CardSpace as a password protection module ( PPM ) is simple. A bank that currently issues passwords to its customer (in addition to one time passwords like securid) would issue the users, a Card. There could be an attribute that is unique to the bank so that only that card shows up when the Identity Selector pops up in the login page of the bank. Hence, in the case, the bank acts as both the identity provider and the relying party.
Given the inherent nature of CardSpace, the architecture claims that it is secure from phishing, and key logging, as talked about in the Video. The idea of using certificates and protocols of sending credentials on the wire as industry standards, hence ensuring theoretical correctness.
This can also be integrated with other security mechanisms like SecurID or One Time Passwords very easily. Development kits already exist for Java and .NET.
To summarize, although federating identities across web sites may not have hit mainstream yet, this component of the Identity MetaSystem can be leveraged to give the users, enhanced security when they log in. I think it is time that the password fields graduate from being a FORM control, to a component of a full fledged secure authentication system.

FriendFeed - Building Custom Feeders


When I first saw friendfeed.com on Sridhar's blog, I knew I wanted to try it. The site definitely looked like a super twitter to me, and I got hold of a beta testing account. Though there are other services, the simple and elegant UI is the prime factor I have decided to stick with this service.
The number of services is by no means the exhaustive list of my online presence. There is no orkut monitor, no place where I can show off my achievements in silly flash games, or no ways to put data out of custom sites that I frequent.
Though the developers seemed to have asked for sites which they are interested in crawling, the approach is hardly scalable. A better approach would be to simple open up an API that lets sites notify friendfeed of activities. Since these activities are very much context specific. if such an API is available, web sites and user can have better control over the type of content displayed. A simple quick fix would have been to atleast allow custom RSS feeds as a part of the feed.
I was looking at the bookmarklet that they have just released, and apparently, it can be utilized by sites for such notifications. The way to share links is a simple form post, if the user has logged in.
Hence, for now, sites can ask for the user's friendfeed credentials and send updates, based on the events on the site. I am currently working on such an application that polls my avtar in duels.com, and posts any updates as a friendfeed. Till then, keep following me at http://friendfeed.com/axemclion !!

Into the Google Indic Transliteration


I had seen it first in blogspot, but it was today that a friend pointed me to the Google Labs home page of the Indic transliteration application.
Some time ago, I was working on a greasemonkey script that added this capability to any text boxes on the browser. I was using QuillPad at the back to fetch the words in Indic languages. The script however broke after the guys at QuillPad decided to change the API to disallow spaces in the queries. I had also written a plugin for the YUI Rich Text Editor that had the same functionality. I had used QuillPad again; I could not really find a competing service.
Today, I was peeking a little into the service that Google was providing, and found that it did stuff similar to quillpad, just that it was a little faster, and accepted whole sentences. The Indic Transliteration of Google is JavaScript based, and makes AJAX calls to an endpoint that represents something like


The parameters are
  • tlqt=1 -- The value always has to be 1. Seems to be some kind of page identifier.
  • langpair=en|hi -- Looks limilar to the google translation tools, representing transliteration from English to Hindi
  • text='"' -- Words are separated by %2C (which happens to be the comma character). Apparently, the text is expected in a comma separated format.
  • tl_app=3 -- Only value 1,2,3,4 seem to work. Any other value does not an AJAX style response.
The response obtained is a JavaScript code while(1);[]. The array at the end contains the response object that is self explanatory. The AJAX call is made at every word ending, marked by spaces, commas, full stops, etc. The response handler to the AJAX call not only uses a hidden DIV to populate the indic characters, it also replaces stuff in the TEXTAREA.

I am planning to get the GreaseMonkey Script functional again using this service. I am also planning to replace the dependency of QuillPad for the YUI Rich Text Editor. However, I am not really sure why the google guys have not come up with a JavaScript widget for this !! (I am not aware if this is available as a part of GWT though. )