Two factor authentication for CardSpace

Hi,

Though the CardSpace adoption meter shows only a 10.2 % capability to use CardSpace as on October 2007, many early adopters have been talking about the usage of CardSpace for payments. The proposals range from using the cards as an authentication mechanism in the existing schemes to embedding the payment information right into the cards. However, when it comes to financial transactions, many banks are still skeptical about a scheme were the user login is protected only by a password. It would be a great selling point for CardSpace to demonstrate stronger authentication mechanisms to enable banks adopt the technology.
This post explores the usage of two factor authentication schemes to secure the card sessions. I was playing around with the RSA SecurID for some time, and realized that integrating and deploying two factor authentication into existing banking systems can be very simple. Everything from the user identity store to the existing token distribution among the customer base can be reused.
A simple Java based CardSpace implementation is available at xmldap.org. The code, hosted on Google code repository, can be tweaked to use custom user management. A sample Access management module for OpenSSO is also available. User authentication using RSA SecurID can can be done in a similar fashion. Currently, XMLDAP uses a derby database to store user information. In the code, a DAO layer takes care of the actual database communication. This can be changed to point to either the RSA Radius Server, or any other existing store. The code for this is available in the org.xmldap.sts.db.impl.CardStorageEmbeddedDBImpl class. The method public boolean authenticate(String uid, String password) does the user authentication. To introduce SecurID authentication, this is the method that requires to be changed. As described in the RSA SecurID ToolKit, a code that resembles the snippet below can be used to do authentication with SecurID.

AuthSessionFactory factory = AuthSessionFactory.getInstance("c:\\Data\\workspace\\openinfocard\\conf\\rsa.config");

AuthSession session = factory.createUserSession();
int status = session.check(userName, password);
switch (status)
{
case AuthSession.ACCESS_OK:
case AuthSession.NEW_PIN_REQUIRED:
case AuthSession.NEXT_CODE_REQUIRED:
result = true;
break;
default :
break;

}
session.close();
System.out.println("Status : " + status);


With the ability to now use custom error messages, it may also be easier to relay the error message that the SecurID shows on an unsuccessful login. However, supporting the "next token code mode" for the SecurID tokens in CardSpace can still be a little trickier.
As described above, cards are now secured with two factor authentication. The potential ease of implementation and deployment should serve as a compelling fact for bank to adopt CardSpace as a payment mechanism. This method is definitely more secure that traditionally entering user credentials at the browser. Please do let me know if you want to see a working version of this experiment.

The new Driving Directions in Yahoo Maps

Hey,

Looks like YAHOO just released a new feature in their Yahoo India maps, a feature that lets you find driving directions for India. The Yahoo India Maps sure is getting better than its Google counterpart, at least for India. As always, curiosity got even of me, and I started probing various internals of the site. On the whole, the security in the site was impressive, and the script injection that I had earlier found was also fixed. There was also this new SMS feature, and the design of this feature was the one that impressed me the most.
First things first, here are the details of how the script injection was fixed. The script injection was in the print page, and the reason it occurred was that the JavaScript code in the page executed as soon as the page loaded, and did not validate inputs. The change that has fixes the injection is that the server now handles all requests, and the input checking is far better now.
I tried other places where I could potentially insert scripts, but all other places displayed had input obtained and sanitized by the server.
The SMS part was the most interesting. The functionality says that you can select two places, get driving directions between them, and can also get it on SMS to the mobile phone in India. A little trace on that and I realized that it was a simple URL get with the message, the phone number and a signature for the message. Now that was the interesting part. To prevent message spam, every message at the browser is signed. The URL receiver at the server side verifies the signature before the SMS is actually sent. As the signature and the message, both arrive from the server, the client cannot really mess around with the contents, thus preventing spam SMS to users. As of today however, replay is still possible as the signature does not seem to have time as a factor.
Hence, any user can hit a URL multiple time. The URL happens to be something like http://in.maps.yahoo.com/php/ymi_send_sms.php?phnum=&mesg=Start%2CStop&sign=2jZ21gYzovjuiP9GhEUl9Q--
multiple times to send message spams !!
This can be fixed however, but I am not sure that including a time frame for the signature can actually solve the problem of replay. Something simpler like captchas for messages that are re-sent to the same mobile number seems a more practical solution . So, right now, you can hit the browser reload a million times with the proper URL, and the SMS reciever is sure to get a little irritated.
To conclude, it sure looks like the entire Yahoo India Maps has got a face lift. It is a lot better in design over the previous time, and unfortunately, I have not found any hacks yet. Congratulating the maps team, I am back to my work to see if I can get lucky to hit atleast one vulnerability !!!

Seam Carving as a Service

Hey,

This is in continuation of my posts on Seam Carving. In the previous article, I was talking about making Seam Carving as a web service. I had noted that both HTML Canvas, and Flash were terribly slow while resizing images. The Java implementation of the algorithm seemed fast enough, and given network speeds of today, server based image resizing seems like a practical solution to bring seam carving to the browser. Due to lack of hosting space, I was not really able to host the servlet. However, it would be great if someone could host the Java Servlet that I wrote.
The corresponding client side operations would now become a lot simpler. The HTML Pages that contains images that require to be contextually resized could have a class, say something like <img src="http://www.blogger.com/../img.jpg" class="seam-resize" />. A non-obtrusive JavaScript on the page could have a hook to all the resize events of the image, and replace the source of the image with something that is like
http://../imageResizeServlet?url=originalUrl.jpg&width=newWidth&height=newHeight
The Servlet internally reads the original image in an InputStream and applies the seam carve function on it. The output of the servlet is the image with the appropriate headers. As an optimization, the JavaScript in the page can stretch the image immediately after the resize, and then redraw the seam carved image as soon as the server returns it. At the server side, instead of reading the original image on every request, it can be cached. The result images with a step of an optimal values can also be cached to enable faster replies by the server.
I am still trying to host it by writing a PHP version and hosting it. Will post the link as soon as that is complete.

Doodle on maps using QuikMaps.com

Hey,

When I first started writing the maps doodle, I thought that an idea like that must already exist. However, googling in that limited time did not really yield any useful results, and so I thought of writing it myself.
Today, when I was analyzing me FeedJIT table, I found that one of the visitors had visited my page using this search. Out of curiosity, I tried the search again, and that is when the second search result turned out to be a site that did something similar, but on Google Maps. The site, called QuikMaps, seemed to have good usability, and the JavaScript in it also well written.
With features like drag and drop signs, the site was an advanced version of the 24 hour that I had put in. A little more dissection showed me the simple tricks that achieved the doodling capability.
The JavaScript in the site was just a simple wrapper over the Google Maps API, using the map overlays extensively. A simple line drawn over the map surface is converted to the to the google maps PolyLines, as specified in the maps API. The images were also placed similarly. This data is saved at the server under a temporary user, and can be shared, printed, etc.
Speaking about the polylines capability in Google Maps, they are effectively placed as HTML 4 SVG tags on the map. This was the only difference from my design, where I used a canvas to overlay the polylines. A comparison between SVG and canvas is here and here. Apparently, I did not notice any difference in performance with both approaches though.
To conclude, as I have found a service that allows doodling on maps already, I may not continue development of the Maps Doodle. I think I would now start hacking into other stuff !!

The Transliteration Component in YUI

Hey,

Some posts ago, I was describing a greasemonkey script that I had written to enable transliteration of the roman script to Indian languages. It leveraged the service called Quillpad. However, it was still greasemonkey, and was not really wide spread. For websites to plugin this components of transliteration, a lot of work still remained to be done.
I was thinking of writing a Javascript Component that when included would bring in the capabilities of transliteration right away. That was when I heard Chris Heilmann talk about the YUI Rich Text Editor (RTE). Though still in its beta, the architecture seems great, allowing pluggable functionality, something that is a must for an editor. Our team at the Yahoo picked this up to create a hack for the hack day. I was hacking up the JavaScript part, while Anishek and Srithar wrote the proxy for quillpad.
Some of the changes that the quillpad guys made included sending individual words instead of sentences, and throwing the 500 internal server error on sending trailing spaces. Thus, the backend proxy had to separate the words, remember the special characters between the words, call the quillpad service to do the transliteration, add the special characters properly back to the words and send the result back.
On the front end, I had to add an extra button to the "insert" button group, and on clicking it, send the selected text up to the server to get the transliteration. I did have some time to fetch the selected text as there were no public JavaScript methods in the RTE that did this. Investigation revealed a method called _getSelection(). There was also a private variable called _select, but that seemed more like a buffer to hold the current node that was selected. A little experimentation, and I got the selection up and working.
That was it for the hack day, but I am now also working on it to tranliteration of the text as I type. This would make getting an Indic interface link in Orkut (Ctrl+G) or the hindi blogger interface easier into a website.

Hack-a-doodle

Hey,

Twenty four hours, one laptop at hand, endless combination of cakes and chips, one Nintendo Wii at stake, and two hundred programmers hacking away at code. The last two days was just this, and it is only today that I have caught up with lost sleep. The YAHOO Hack day , Bangalore, India is finally over, but I am still dizzy with all the fun I have had. This post is a short and lazy description of the hack that I came up with, on the Hack day.
Sometime back, I had written about YAHOO India Maps, and all the time I had spent trying hack it. Though the maps teams at YAHOO and Google are struggling hard to come up with ways to show directions, nothing can ever equal a friend drawing the directions on the map. Well, that was my hack - the power of doodling over the maps, and then sharing them with friends.
Done in HTML, picking up code from the canvas painter and YDN Maps, I had to add the power to save the positions, transformations, zooming and distribution. Painting on the canvas is simple, it is the transformations and zooming that took time. Initially, I wanted to leverage the style:width and style:height to zoom and pan, but the solution did not really seem scalable. With increasing doodles, the browser seemed to get a lot slower. Luckily for me, I was drawing paths I had to use AJAX to save and retrieve the paths, just like Yahoo maps draws the images. The only optimization that I could chip in was the retrieval of surrounding paths. Finally, all I could present was a heavily simplified version of an application that I wanted to build !
You can take a look at the most basic version of the hack here (saved as a HTML), as I don't have external hosting space.



So much for a hack, lucky for me, they loved it.. They handed me that Nintendo Wii, autographed by David Filo himself !!!

Orkut on Facebook....start of social meta networking ?

Hi,

I had been toying with the idea of getting orkut to the facebook platform to quite some time now. Well, I just got an invite to a similar application today. In the words of the author,
This application brings you your very own Orkut profile to your Facebook account! You dont have to provide any login or password. All you specify is your Orkut Profile URL!
This definitely is an improvement over sites that require the google credentials. Though the UI of the application is not great, that is an easier problem to fix.
Adding this application to the Facebook lets a write scraps to other on orkut, the only point being that the scrap seems to have sent from an automated Orkut user. The last sentence however states that the identity of the one who has sent a scrap is not verified. This last sentence opens up the a host of possibilities to spam and phished scraps.
Strangely enough, it could be a simple, two step process confirm that a user really hold a particular profile.
  1. The automated orkut user sends a friend request to the the profile that the user claims
  2. After the user logs into the the claimed profile (which is possible only if he owns it)
  3. The user then requests for a 'validation random number' that the automated orkut user sends as a message
  4. The user is then requried to look up the message, and type in the code in the facebook application.
Though steps 1 and 2 seem sufficient, the 'validation random number' is more to stop replay attacks. Though this verifies a user, the user who receives this scrap need not necessarily trust the application. Hence we need another way where the users trust each other, without any dependency of trust on the application.
Now, that problem is more like the one that is solved by digital certificates, only that the Certificate authority in this case should be a lot simpler.
Working on this....would update when I can come up with a solution.

The Smilies in Gmail - Gtalk

Hey,

A lazy Saturday afternoon, chatting on Gmail with a couple of friends, and this interesting thing caught my attention. Strange that it had not caught my attention till now, but I decided to check out the way the smilies rotate. This is not rocket science, but I sure was impressed by the way it was done.
It is obvious that the rotation cannot be textual, and so I was looking at the presence of a GIF to do the job. However, I discovered this image replaced the actual text with this and this being the background images. The animation was achieved by using a setTimeOut and changing the -x-background-y-position style from 0 to 132 at regular intervals. Thats is how the image seems to rotate.
Now this is a pretty interesting way to achieve animation, given the fact that the animation has to be replayed when a user hovers the mouse on the smilies. Sure thing that GIFs to achieve would be a pain, specially the way animation is handled across Internet Explorer and Firefox !!