Total votes: 1
Print: Print Article
Please login to rate or to leave a comment.
Published: 20 Apr 2011
Download Sample Code
Learn how to securely pass user identity information from one website to another. This short tip shows how to protect against replay attacks, how to stop tampering, and how to encrypt the identity token information.
An identity token is a security device that provides details about the identity of the person holding the token. Identity tokens are part of everyday life; you probably have one in your pocket right now (your driver's license). Software identity tokens are tokens stored on an electronic device, such as a desktop computer, and serve the same purpose, namely as a means for identifying a user who is requesting a computer service.
Take forms-based authentication as an example. Forms-based authentication is a common technique used by websites to identify their visitors. In a nutshell, a anonymous visitor is presented with a form into which they supply their credentials, typically a username and password. Upon successful authentication, the website stores an identity token in the client's cookies collection. Consequently, the identity token is sent to the website with each request made by the client. The server inspects this token to determine the requestor's identity.
In certain scenarios you may need to pass an identity token from one website to another. I once worked on a website that aimed to improve teamwork by analyzing team members' personalities and leadership traits. Companies interested in using this system would send their employees to our website to take a survey, answer questionnaires, and so on. Employees would reach our site by clicking a link from within their intranet. The link sent the users to our site and, in the querystring, included an identity token that told us the username of the arriving user, the company they worked for, their department, manager, and other pertinent information. Due to having this information supplied to us via an identity token we did not have to require users arriving at our site to create an account or tell us their name, their company's name, or other required information.
This article shows how to: create an identity token; securely pass it to another website via the querystring; and how to read the identity token on the receiving end. For these examples let's presume that the only identity information that needs to be captured in the token is the user's username.
Do Not Store Passwords in Identity Tokens
Software identity tokens should not be used to store passwords, credit card information, or other sensitive data. After all, your passport doesn't list your bank account numbers, PIN numbers, and the combination to your home safe. Instead, a token should contain just the information related to identity – the user's username and, if necessary, other related data.
A First Stab at Creating an Identity Token
The simplest way to pass identity information from one website (or web page) to another is to send the contents of the token directly in the querystring. For example, to send the username of the currently signed in user from website A to website B we could do the following:
- Have website A create a hyperlink that, when clicked, sends the user to website B's
IncomingUser.aspx page - www.websiteB.com/IncomingUser.aspx?Username=username. Here, username is the username of the currently logged on user in website A.
IncomingUser.aspx page on website B would read the
Username querystring field to identify the user.
While this simple approach certainly works to convey identity information from website A to website B, it is vulnerable to a number of security attacks. Most glaringly, there is no guaranteed authenticity. That is, there is no way that website B can determine whether the token has been modified since it was created by website A. Steve, a meddlesome and mischevious user, might notice that the hyperlink points to www.websiteB.com/IncomingUser.aspx?Username=Steve and try changing it to www.websiteB.com/IncomingUser.aspx?Username=Alice. This minor tweak would, in effect, allow Steve to visit website B as if he were Alice!
Ensuring Token Authenticity with Digital Signatures
A digital signature is a mechanism for demonstrating the authenticity of an electronic message. A common technique for creating a digital signature is to take the message to be transmitted (in this case the username), append it with a secret key known only to the two parties exchanging the token, and then compute a cryptographic hash of that combined input.
The code in Listing 1 shows how website A would create a digital signature and send it to website B. In a nutshell, website A starts by defining the string to sign, which is the username concatenated with the secret key. Next, the .NET Framework's MD5CryptoServiceProvider class is used to compute the MD5 hash of the username plus secret key input string. (MD5 is one of many available hash functions.) This resulting hash is then converted into a base-64 string and it and the username are placed in the querystring of the hyperlink that the user would click to go to website B.
Listing 1: Website A includes a digital signature to ensure authenticity of the identity token.
When the user clicks the hyperlink they are whisked to www.websiteB.com/IncomingUser.aspx?Username=username&Signature=signature. The
IncomingUser.aspx page on website B can determine the identity of the user via the
Username querystring parameter (as before), but can now ensure the authenticity of the token by computing the digital signature (using the same steps as website A) and comparing it to the submitted signature. If the two signatures are not equal then something is amiss – either the username has been modified or the signature has been modified. In either case, website B would display some error message and not let the user proceed.
The download for this article includes a complete working demo for creating the identity token and digital signature and for reading the token and verifying its authenticity.
Mitigating Replay Attacks
Replay attacks are a common concern when working with identity tokens. In a replay attack, a malicious user somehow obtains an identity token and uses it to assume the identity of that user. For example, imagine that user Scott is being passed from website A to website B, which prompts website A to create an identity token with a signature that results in a URL like so: www.websiteB.com/IncomingUser.aspx?Username=Scott&Signature=rm4u5GYfv5LO8MoKSh%2bTDg%3d%3d. If malicious user Frank somehow discovers this URL, either by sniffing traffic on the network or seeing it cached in Scott's browser history, he can enter this exact same URL into his browser and visit website B as Scott. Website B has no way of knowing whether the user bearing the identity token is truly Scott or whether it's Frank (or someone else) who has somehow come across Scott's token.
To mitigate replay attacks create an expiry for the identity token. An expiry ensures that a token is only valid for a specified duration. While this does not prevent a malicious user from instigating a replay attack, it greatly reduces the chances by limiting the time frame that such an attack could be used.
To implement this functionality, website A needs to include the date and time the identity token was generated. (Because website A and website B may reside in different time zones it's a good idea to specify the time using Coordinated Universal Time, or UTC.) This timestamp also needs to be digitally signed to ensure that it is not modified.
Listing 2 illustrates how to get the current date and time in UTC time –
DateTime.UtcNow – and how to include that information as part of the digital signature. Note that the hyperlink's now includes three bits of information: the identity token (the username); the timestamp; and the signature.
Listing 2: A timestamp is supplied with the identity token to mitigate replay attacks.
When the user clicks the hyperlink they are whisked to www.websiteB.com/IncomingUser.aspx?Username=username&Timestamp=timeStamp&Signature=signature. The
IncomingUser.aspx page on website B can determine the identity of the user and the authenticity of the token and timestamp as before, but now must also check the age of the timestamp. If it is older than some determined amount of time – whether that's 5 minutes, 5 hours, or 5 days – then the website B should stop the user from accessing the site.
The download for this article includes a complete working demo for including timestamps with the identity token to mitigate replay attacks.
Tokens are commonly used in web applications to transmit identity information between the client and server or between websites. When transmitting identity tokens it is important to take steps to prevent tampering and to reduce to likelihood of replay attacks. This article showed how to use digital signatures to ensure authenticity and how to use timestamps to mitigate replay attacks.
With the approaches presented in this article the identity token is passed as plain-text in the querystring. If privacy is important, consider encrypting the identity token.
- Passing Tamper-Proof Querystring Parameters
- Website Security Tutorials
Scott Mitchell, author of eight ASP/ASP.NET books and founder of 4GuysFromRolla.com, has been working with Microsoft Web technologies since 1998. Scott works as an independent consultant, trainer, ...
This author has published 16 articles on DotNetSlackers. View other articles or the complete profile here.
Please login to rate or to leave a comment.