Passport authentication messages are passed in the form of electronic "tickets" that are used to inform the site that the user has signed in successfully. A ticket is a small amount of data that indicates the time the sign in occurred, when the user last manually signed in, and other information that is useful to the authentication process. Within the Passport system, these tickets take the form of cookies.
To obtain a ticket, a user with a Passport account signs in to the site or tries to access a protected Web page within the merchant site (e.g., a page that requires user authentication before allowing access). This redirects the user to a special page on Passport.com. This page takes information that the merchant site has appended to the URL and processes it. This allows the Passport service to know which merchant site has referred the user, and which merchant site to return the user to. Once the information has been processed, Passport redirects the user to a page on Passport.net.
Once the user enters their credentials, they are sent back to the Passport.com domain. Once there and verified, Passport writes a cookie on the user's browser that stores information about this sign in. This is called a "ticket-granting-cookie" and it is used in subsequent sign in attempts. Then Passport redirects them back to your site.
When the user arrives back at the merchant site, they bring two encrypted packets of information attached to the query string. Software called the Passport Manager which is installed on the merchant's authenticating servers reads those packets and writes them as encrypted cookies in the merchant site domain.
The first cookie contains the authentication ticket information. The second contains any profile information that the user has chosen to share, and any operational information and unique identifiers that need to be passed. These packets are encrypted with a unique secret key that is shared between Passport and the merchant site. This helps to ensure that only the merchant can decode these messages.
The merchant site then takes this information and uses it to issue his cookies. Since these cookies are issued from the merchant domain, the merchant will have access to them. The merchant can use the Passport User ID to look a user up in the merchant database and perform authorization tasks.
When the user navigates to another Passport participating site, the new site has several choices to make about how they will authenticate this user. When the user clicks the sign in button, they are directed to the Passport service exactly as they were at their first sign in. The difference is that this time there is a ticket-granting-cookie saved on the browser that Passport can read.
Since the ticket contains the time that it was issued, it allows the referring site to decide how "fresh" the cookie needs to be in order for the site to accept it. If the ticket meets the rules the referring site has chosen, the user is redirected back to the referring site along with the encrypted ticket and profile cookies. If the ticket is too old, the user is prompted to re-enter their credentials.
| Note | However, passport has been plagued with security issues - right from reuse of authentication cache to privacy flouting activities. Apart from this exploits that plague Microsoft based web systems such as Unicode exploits, cross site scripting and cookie stealing cast more than a shadow of doubt on this means of authentication. |
A few links exploring these issues are given below:
It is highly customizable authentication mechanism that uses a form composed of HTML with
After the data input via HTTP or SSL, it is evaluated by some server-side logic and if the credentials are valid, then a cookie is given to the client to be reused on subsequent visits.
Forms based authentication technique is the popular authentication technique on the internet.
Conventionally, web applications had users authenticate themselves through a Web form. The user's credentials as captured by this form are submitted to the business logic which determines the authorization level. If the user is authenticated, the application generates a cookie or session variable. This cookie contains anything from a valid session identification access token to customized personalization values. The time period for which the cookie is valid or the contents stored in it are subject to security risks.
Forms Authentication is a system in which unauthenticated requests are redirected to a web form where the unauthenticated users are required to provide their credentials. In the context of ASP.NET, it extends similar logic into its architecture as an authentication facility, Forms Authentication. Forms Authentication is one of three authentication providers. Windows Authentication and Passport Authentication make up the other two providers.
Reverting back to the web based authentication method, on being properly verified by the application, based on the credentials input by the user, an authorization ticket is issued by the Web application in the form of a cookie. In essence, Forms Authentication is a means for wrapping the web application around the login user interface and verification processes.
| Note | Forms Authentication Flow
|
-
WinSSLMiM is an HTTPS Man in the Middle attacking tool. It includes FakeCert, a tool to make fake certificates.
-
It can be used to exploit the Certificate Chain vulnerability in Internet Explorer. The tool works under Windows 9x/2000.
-
Usage:
-
FakeCert: fc -h
-
WinSSLMiM: wsm -h
-
We have seen how digital certificates are used for authentication purposes. Typically, the administrator of a web site opts to provide secure communication through the SSL. To enable this, the administrator generates a certificate and gets it signed by a Certification Authority. The generated certificate will list the URL of the secure web site in the Common Name (CN) field of the Distinguished Name section. The CA verifies that the administrator legitimately owns the URL in the CN field, signs the certificate, and gives it back.
[CERT - Issuer: VeriSign / Subject: VeriSign] -> [CERT - Issuer: VeriSign / Subject: www.website.com]
| Note | When a web browser receives the certificate, it should verify that the CN field matches the domain it just connected to, and that it is signed by a known CA certificate. No man in the middle attack is possible because it should not be possible to substitute a certificate with a valid CN and a valid signature. However, it is possible that the signing authority has been delegated to more localized authorities. In this case, the administrator of www.website.com will get a chain of certificates from the localized authority: |
| Attack Methods | However, as far as IE is concerned, anyone with a valid CA-signed certificate for any domain can generate a valid CA-signed certificate for any other domain. If an attacker wants to, he can generate a valid certificate and request a signature from VeriSign: [CERT - Issuer: VeriSign / Subject: VeriSign] -> [CERT - Issuer: VeriSign / Subject: www.attacker.com] |
Then he can generate a certificate for any domain he wants to, and sign it using his CA-signed certificate: [CERT - Issuer: VeriSign / Subject: VeriSign]
-> [CERT - Issuer: VeriSign / Subject: www.attacker.com] -> [CERT - Issuer: www.attacker.com / Subject: www.amazon.com]
Since IE does not check the Basic Constraints on the www.attacker.com certificate, it accepts this certificate chain as valid for www.amazon.com. This means that anyone with any CA-signed certificate (and the corresponding private key) can spoof anyone else. Any of the standard connection hijacking techniques can be combined with this vulnerability to produce a successful man in the middle attack.
| Tools | WinSSLMiM is an HTTPS Man in the Middle attacking tool. It includes FakeCert, a tool to make fake certificates. It can be used to exploit the Certificate Chain vulnerability in Internet Explorer. The tool works under Windows 9x/2000. |
Amarjit Singh
No comments:
Post a Comment