If you don't like the idea of using Microsoft-owned technology as an authentication system, we have an alternative for you... Show me your Passport
"Create your sign-in credentials (e-mail and password) once, then use them everywhere on the Microsoft Passport Network. You can even set the site to remember your credentials for you!"
This is what the MSN Passport does, in a nutshell: it provides a universal login system so that members only need to remember their email address and one password in order to be authenticated on every site that uses the Passport technology. It has been adopted quite happily by some websites and portals[3], and particularly by merchant sites, who liked the idea of making life easier for their users. So far, so good.
Like nearly every Microsoft technology seems to at one point or another, the MSN Passport became an object of criticism and concern, as shown in a 2002 MIT document[4]. The main problem is this: among the data collected by Microsoft upon a user's registration is a significant amount of personal information (such as age, date of birth, and addresses) which is stored on the Microsoft servers. What if someone gains access to that information? Who guarantees that that information will not be used by third parties?
Aside from the privacy issues, some people are concerned about the system's internal security and by the fact that the system is entirely dependent on Microsoft servers to work:
"As more services and components depend on remote servers, functionality can grind to a halt if there is a failure on the centralized Passport system."[5]
People have concerns, but what has been done? Are there any alternatives? Well, yes and no. Apparently the Liberty Alliance Project[6] was created to offer a valid and perhaps more democratic alternative to the Microsoft Passport:
"The Liberty Alliance Project was formed in September 2001 to serve as the premier open standards organization for federated identity and identity-based services. The Alliance is delivering specifications and guidelines to enable a complete network identity infrastructure that will resolve many of the technology and business issues hindering the deployment of identity-based Web services."[7]
The project's founders (160 IT organizations, including Sun Microsystems and VeriSign) aim to create a distributed authentication system, as opposed to the centralized MSN Passport. This will undoubtedly solve some of the problems, but the system is still under development.
Introducing Project Windstone
CyberArmy[8] is obviously like neither Microsoft or Sun Microsystems; it's a community of volunteers whose aim is sharing their knowledge and making the Internet a better place. Volunteers don't get paid, but sometimes something gets done, and some projects are released to the general public. Among these is a system for (if you haven't guessed already)a system for universal user authentication, called Project Windstone[9].
Project Windstone was developed by SoundWave on behalf of Special Operations and Security[10] to provide a universal authentication system that is easy to use and deploy on websites and in applications. Furthermore, the Windstone protocol is language-independent and functions via HTTP POST transactions between clients and the Windstone server, so virtually any website coded in any language or any application able to communicate with a web server can implement it.
It seems great so far, but what can Windstone be used for? As previously said, it is a system to allow users to authenticate themselves with the same credentials on many different websites and share profiles and information between those websites at the same time. Furthermore, users can send each other private messages that can be retrieved on any website that implements Windstone, with the added benefit of all transactions taking place in a secure and private environment.
On second thought, Windstone features seem to lead to some perplexity, especially among users who are particularly concerned about their own privacy: apparently a single centralized server is involved, and users can share their profile and send messages with each other, so what warranties does Windstone offers as far as privacy/security goes? Here's something which should reassure most of us:
- The information provided by users in their public profiles is entirely up to their discretion: in other words, it's up to the user if they want to list their credit card numbers on their profile or talk about their cat, as the Windstone server itself does not require any specific personal information in order to create a profile.
- The username can be any valid email address submitted by the user.
- User profiles are available only after authentication with the Windstone server, and only if the person requesting the profile already knows the email address used by another user for Windstone services. Currently, Windstone does not implement any form of listing of existing users among the standard commands.
- The password chosen for user authentication is NEVER saved in any form; not within the client applications, not on the central server, and not in cookies.
- Data sent from client to server and vice-versa is encrypted.
Some more technical details
I am actually planning to implement the system on one of my sites, so I started reading the short but straightforward documentation[11] available on the Windstone site to learn more about how the system works, and it seems quite simple and able to do what it does in a logical way; the Windstone "standard" contains a bunch of commands[12] which are used by the clients (agents) and the server to request information exchange such as requests for initialization, possible server replies, and so on. Commands and data are sent using the following format (excerpt from the official documentation):
The format of this command string is as follows:
AAAA.*BBBBBBBBBB.*CCCC::DDDDDDDDDDDDDDDDDDDD::EEEE::FFFFFFFFFF
A. This is the command. Commands tell us what kind of request or response is being made with the command string. It also lets us know how many elements of data to expect (see F).
B. This is the agent system identifier. Each website or IEP receives a unique alphanumeric ten (10) character identifier upon registration, which is used to identify this system within the network.
C. This is the protocol version number. Generally, the version number will not change much, if at all, but it must be present. The protocol version goes with all command strings to let other systems and the Windstone server know what version of the protocol you are using. If certain versions are incompatible with each other, or if there is an upgrade or change to the protocol you are using, the version number will be used to determine that.
D. This is the transaction identifier. Usually, this is not used, so the default information that should go here is six zeros ("000000"). The transaction identifier helps to link command strings into groups for processing and is most often used during the user login process.
E. This is the sequence number. The sequence number, in conjunction with the transaction identifier, is used to put grouped command strings into their logical order. The sequence numbers have no specified numbering sequence, default start value, or length limit: the only requirement is that a sequence number must be in order from lowest to highest. When not using a transaction identifier or sequence number, the default information that should go here is a simple "X" (note that when "X" is being used in a command string by itself, it should always be capitalized).
F. This is the data section. The data section is the heart of the command string. It is important to note that, at the minimum, all data sections need to be base-64 encoded prior to transmission - at no time should there be information in plain text format in the data section.
Obviously, command strings can be manipulated to access each section separately and the manipulation can be done with virtually any programming language used on the client side.
Normally, the client will send a command to the Windstone server to start the authentication process and then retrieve some information; the server will reply accordingly to the client's command strings with its own responses wrapped in command strings. Let's suppose a Windstone Agent is being used to perform the following actions:
- Initialize the system
- perform a login
- retrieve user profile from the Windstone server
In this simulation I will not use the actual command strings but just the codes for the various commands.
Agent: 0000 :: SETUP_INITIALIZE - The Windstone agent sends a request to the server to initialize the authentication process, supplying the software identifier, the software type ("PC-Based" or "Web-Based"), the command landing URL and the URL to redirect logins to.
Server: 0002 :: SETUP_COMPLETE - Everything looks good to the server, which replies with the following information: Unique agent identifier, primary authentication token, secondary authentication token, activation key, security code, shared encryption key (255 random characters, non-binary), registration completion date and time (epoch). These parameters will be used by the agent afterwards and are necessary to identify the agent on the Windstone server.
Agent: 1102 :: USER_LOGIN_REDIRECT - The agent requests to start the authentication process and sends the email address of the user to the server along with the URL where the user's password will be entered.
Server: 1105 :: USER_AUTH_SAVE - User credentials are checked by the Windstone server. Everything is fine, so the server sends this response to the agent. The response contains the authentication token which will be used to authenticate the user during the session, as well as the user's display name.
Agent: 1107 :: USER_INFO - The agent can now request the user's profile from the Windstone Server.
Server: 1108 :: USER_PROFILE - After checking the user's authentication token, the server can now send the following information to the agent: Email address, display name, user "About Me" text, last login date and time, account created date and time, online status.
This is just a simple example of how the Windstone protocol can be used; as mentioned earlier, there are various other commands[12] which can be used to perform various actions.
Development and deployment
The Windstone protocol is fully operational and can be implemented on any website or application able to communicate with a web server. The developer made a very basic PHP-based example of an Agent system available online[13]; it may not be a masterpiece of PHP coding (as the developer himself pointed out), but it can be useful in understanding how to develop a Windstone Agent System.
If you'd like to start developing your own Agent System or you just want to create a Windstone account, it can be done on the Windstone registration page[14]: you'll be asked to provide an email address, a display name and a profile (the last two can be modified afterwards). Then the system will prompt you for a password, and an email will be sent to the address you provided to confirm and activate your account. Once you have an account, you can login to any website or application implementing the Windstone protocol, such as the Windstone website itself[15].
Windstone is certainly not yet comparable to the MSN Passport technology - it's not used by a lot of important sites, and it's much simpler and offers fewer services, but it's undoubtedly an interesting approach to a free to use, secure and private system of universal user authentication.
Check it out![9]
Notes and Resources
[1] Microsoft Hotmail Service, http://www.hotmail.com
[2] MSN Passport Network: https://accountservices.passport.net/ppnetworkhome.srf?vv=320&lc=1033
[3] List of sites using MSN Passport, Passport@everything2: http://www.everything2.com/index.pl?node=passport
[4] "Microsoft .NET Passport and Wallet: Approach with Caution!", http://web.mit.edu/ist/isnews/v17/n04/170408.html
[5] "Microsoft Hailstorm and Passport", go-mono.com, http://www.go-mono.com/passport.html
[6] Liberty Alliance Project, Official Page, http://www.projectliberty.org/index.php
[7] Liberty Alliance Project, FAQs, http://www.projectliberty.org/about/faq.php
[8] CyberArmy, Official Page, http://www.cyberarmy.net/
[9] Project Windstone, Official Page, http://windstone.x-mirror.com/v2/
[10] Special Operations and Security, official website, http://sos.x-mirror.com/
[11] Windstone Communications Protocol, Development Whitepaper, http://windstone.x-mirror.com/v2/development.php
[12] Windstone Protocol Commands, http://windstone.x-mirror.com/v2/commands.php
[13] Example of PHP Agent System (ZIP file), http://windstone.x-mirror.com/v2/ws-testbed.zip
[14] Windstone Registration, http://windstone.x-mirror.com/v2/register.php
[15] Windstone Login Page, http://windstone.x-mirror.com/v2/login.php