SSL Sign-In
.jpg)
SSL Sign-In
Secure Sockets Layer (SSL) sign-in provides a way to minimize vulnerability to replay and dictionary attacks. Sending the domain-authority cookies in the header made it remotely possible to intercept them at a packet-sniffing or gateway level, and then to make an attempt to authenticate in another Microsoft® .NET Passport domain as long as the site's time-window requirements were satisfied. Similarly, intercepting the t and p parameters of a query string and submitting them back to the same site would also spoof a user as far as a site's calls to the IsAuthenticated method are concerned, and would satisfy authentication for the remainder of the time window.
The base .NET Passport service has a vulnerability to a concerted brute-force attack against a user's credentials. The Login servers for .NET Passport implement a slow-down mechanism to discourage casual attempts to gain access to a user's account by repeatedly guessing passwords. This functionality is intended to provide a moderate level of security combined with a reasonable level of usability without creating a vulnerability to a denial of service attack directed against user credentials.
SSL sign-in eliminates these vulnerabilities by adding features to the sign-in process. The IsAuthenticated, LogoTag2, and AuthURL2 methods of Passport Manager and related interfaces accept a new parameter that allows your site to indicate one of the two new levels of authentication security:
The first level (called SSL Required) requires the use of SSL communication for all authentication iterations and also determines whether your domain Secure cookie should be decrypted and checked against the user's .NET Passport Unique ID (PUID) in the Ticket. If there is a mismatch, the user is not considered authenticated. The user should then be sent to the SSL sign-in server to be reauthenticated.
The second level (called Security Key) requires that the user select a secondary credential, known as a Security Key, which is used to sign in to participating sites that require it. This Security Key is considered to be strong because it requires the compromise of the base credentials in order to attack it (effectively increasing the overall protection of the base credential on a protected site), and because it is protected by a lock-out mechanism that goes into effect after five failed attempts. The Security Key does not automatically unlock and requires the user to go through a reset process to regain access to protected sites.
SSL Required
The SSL Required level of SSL sign-in includes the following features to eliminate the packet-sniffing window of vulnerability.
The Login server URL pages are served from a secure domain if a SSL sign-in is requested by a site. Previously, the sign-in process used a secure address only when silently redirecting to the network-side page used to set the Ticket-Granting cookie.
SSL sign-in now writes a new "Secure" cookie in the HTTPS header both into passport.com and into your domain. The Secure cookie contains the encrypted PUID (MemberIDHigh and MemberIDLow attributes of the core profile) that uniquely identifies a .NET Passport user. Packet sniffing cannot extract the Secure cookie from the query string and cannot use it to spoof a user.
When SSL sign-in is used, if the PUIDs in the Ticket and Secure cookies do not match (or no Secure cookie exists), no cookies are copied; the SSL sign-in user interface (UI) is presented, through which the user must resubmit credentials. This prevents the case in which cookies submitted in headers to the Login server could be copied and used on other sites.
Upon completion of any SSL sign-in, Passport Manager writes the Secure cookie into your domain as an HTTPS cookie. If SSL sign-in is requested, the return URL given must therefore be an HTTPS URL. The Ticket and Profile are still written as nonsecure cookies so that they can still be accessed by non-HTTPS pages on your site if desired.
The .NET Passport application programming interface (API) will continue to extract the required timestamping information from the regular Ticket. However, if you call the IsAuthenticated method to check for Ticket validity within the time window, you can specify SecureLevel=10. Returning True now necessitates that the last sign-in has written the Secure cookie, and that the PUID in the Secure cookie must match that in the nonsecure Ticket.
Secure and nonsecure versions of the t and p parameters submitted to your site, as well as the cookies in headers, are physically different even though they are encrypted in the same key. Unscrupulous users cannot simply submit the nonsecure Ticket and Profile cookies they captured and use them to connect to the secure Login server and get secure Ticket and Profile copies back. The Secure cookie is never transmitted as a query string parameter.
An efficient use of SSL sign-in would be to request SSL sign-in on the initial check for authentication when you send the user to the Login server. Subsequent checks for authentication can use IsAuthenticated, which does not require a Login server redirect, specifying that the Secure cookie should be checked. Even if someone captured t or p parameters to your site, or managed to submit captured cookies in the header to the Login server, the authentication would fail because there would not be a Secure cookie to match the most recent Ticket.
Security Key
The Security Key level of SSL sign-in was introduced in .NET Passport version 2.0 to support sites that had even higher security requirements than handling sign-in over secure channels. This level includes all of the features of SSL Required, plus additional security features.
The first time a user attempts to access a site where the Security Key is indicated, a Security Key selection page is displayed. The user is required to select a four-character Security Key along with three different secret question-and-answer combinations. The Security Key is used by the user to sign in to any SSL sign-in-enabled site that has 'request Security Key' level security. The secret questions and answers are used if the user needs to change or reset the Security Key.
Implementing SSL Sign-In
To implement SSL sign-in, include the optional SecureLevel parameter in calls to the methods IsAuthenticated, LoginUser, and LogoTag2. The value of the parameter may be either 0, 10, or 100. If the value is 0 (or unspecified), SSL sign-in is not used. If the value is 10, SSL Required is used. If the value is 100, Security Key is used. The following example shows a call to IsAuthenticated using SSL Required. For more information about the SecureLevel parameter, see Manager.IsAuthenticated.
...
TimeWindow = 60
ForceLogin = True
SecureLevel = 10 ' Use SSL Required
'Check for IsAuthenticated, using the defined parameters.
If oMgr.IsAuthenticated(TimeWindow,ForceLogin,SecureLevel) Then
Response.Write ("You have been authenticated with your password " & _
"within the TimeWindow of " & TimeWindow & " seconds.")
End If
Why Use SSL Sign-In?
Your site might use SSL sign-in if you are already using fairly long time windows (such as the 10,000-second default) and thus do not expect to be making many further reauthentication checks. Longer time windows increase the opportunity for replay attacks, but help to provide better performance on a site because of fewer required redirects back to the Login server. You could also use SSL sign-in if successful .NET Passport authentication provides your users access to extensive personal or sensitive information, such as transactional abilities or the ability to edit personal data above and beyond the .NET Passport profile.
Requirements for Using SSL Sign-In
The primary requirement for using SSL sign-in is that your site be capable of serving pages using HTTPS protocol. This requires that your site has established and signed certificates. Microsoft .NET Passport servers already use HTTPS in order to write secure Ticket-Granting cookies. Requiring that your users have HTTPS-capable browsers does not increase the requirements for your users and will not intrude in the user experience any further, as long as your certificates are signed and in order. If you are using cobranding on the Login server and other network servers and specifying SSL sign-in requirements, cobranding elements must also be available using HTTPS. Cobranding with SSL sign-in is limited to the logo image URLs you specify when registering your .NET Passport participating site. This limitation is designed to increase the security of the transaction.
Possible Disadvantages of Using SSL Sign-In?
The possible disadvantages of using SSL sign-in are primarily in terms of performance. Serving pages over HTTPS transmits more data because of the added infrastructure of the key exchange, which can take more time to construct and serve at the server end. HTTPS pages also take more time to be loaded and rendered at the client end. If your site does not expose extremely sensitive user data on the basis of .NET Passport authentication, or already uses TimeWindow parameters to assure that sensitive data pages are difficult to access through replay attacks, the standard HTTP Login server and standard Passport Manager calls are probably adequate for your needs and will be more efficient.
Do Not Use Short Time Windows
If you use SSL sign-in and secure authentication checks, it is not necessary to establish extremely short time windows, especially when submitting these TimeWindow values to the Login server in AuthURL2 or LogoTag2 calls. The purpose of specifying shorter time windows is to minimize the opportunity for replay attacks. SSL sign-in generally eliminates the chance of success of an ordinary replay attack, so constantly rewriting all cookies only increases the load on the network servers, and more important, will slow load times for your site's pages because of frequent loads, rewrites, and redirects over HTTPS.
See Also