Term Paper On Web Authentication

INDEX Title of Paper ...2 Author of the Paper.....2 Supervisor of the Paper......2

1. 2. 3.

4. Introduction...3 5. Authentication Tokens.5

6. 7.

User Privacy.12 Conclusion...16

Ankit Gupta

Term Paper On Web Authentication

Title -:

Web Authentication

Author -: Ankit Gupta Supervisor -: Ram Krishna Tiwari

Ankit Gupta

Term Paper On Web Authentication

Introduction
In many web applications, it is desirable to have users log in by giving some unique login name and a password before accessing pages. There are many ways to implement this, each with different advantages and disadvantages. The considerations involved are complex enough that I'd guess that the majority of authentication systems in use on the web today have at least some fixable security weaknesses. I originally did a lot of thinking and studying on some of these methods in hopes of developing a better authentication system for my web conferencing system, Backtalk. This report summarizes my conclusions about the strengths and weaknesses of various methods that I have considered. I've since built many web authentication systems for many customers, so I've continued to update this with new ideas and concerns. I will discuss the two standard authentication systems which are described in the HTTP protocol documents: "basic authentication" which is supported by most browsers and HTTP servers, and "digest authentication" which isn't. I will then discuss various "do-it-yourself" alternatives to basic authentication, focusing on the three basic phases to the web authentication process:
1. Logging in: The user must be prompted for a login and password.

Some program on the server must check these against a database to confirm that they are valid. 2. User Tracking: Normally there is no persistent connection between a user's browser and and your web server. If the web-site consists of more than one page, and if you don't want the user to have to log in again for each new page he looks at, we need some way to preserve the login information from page to page. 3. Logging Off: If we have a way to remember that a user is logged on, we also need a way to destroy that information when the user logs off. Several commonly used server-side web development packages (such as Microsoft's Active Server Pages, Allaire's Cold Fusion, or Apache's Tomcat
Ankit Gupta 3

Term Paper On Web Authentication

server) have authentication systems built in. I won't describe how to use those here. Internally, they all work in much the same way as the "do-ityourself" methods described here, except that they are mostly done for you. Though this document does not describe the pre-fabricated authentication packages available, it is a pretty thorough discussion of the issues involved, and thus potentially educational for those interested in evaluating pre-fab packages. While most of this report applies equally to servers on all platforms, some of the details are specific to Unix systems. There are probably many issues relevant to security on NT systems that I personally don't know much about. Security issues on Unix systems are generally better understood due to wide availability of information about their internal operation. Finally, the advice and opinions expressed here are my own. No guarantees of completeness or accuracy are intended. If you disagree, let me know, but in the final analysis you must use your own judgment in designing your authentication systems. Many web-sites have accounts for users with personal information or the ability to control various things on the site. For this the site employs a username and password combination, such that the user has some permission and the password is used to make sure that the client who tries to login is truly the real user, that is, the client is authenticated. Password authentication is the most common, other forms include biological based authentication method, such as a retinal eye scan, additional forms use a smart token. However password authentication is the only feasible method for web-site authentication, the other methods require hardware that is not readily available for all users. The process by which the user sends the username and password for the site and the site acknowledges the user as authenticated is called the authentication protocol.

Ankit Gupta

Term Paper On Web Authentication

Authentication Tokens
After the user will be logged in we'll need to keep track of him so that he will not need to go through the login process for each page. For this we keep authentication tokens attached to the user, the authentication tokens will be verified on each page access and if they do not match what the user logged in with we will require him to login again. Token placement Before we discuss the tokens themselves let's see what options we have to attach them to the user. Basically we have two options, we either give the user a cookie or we could add the tokens to each URL in the site. The first option is the best since it is less intrusive and is hidden from the user, also cookies avoid the chance to bookmark stale tokens and the chance to remove the tokens inadvertantly. The problem with cookies is that they might be disabled, for this case we might require the user to support cookies or we could fallback to attach the tokens to the URL for each page, this is effectively what gets done in PHP4, whenever cookies are not supported by the browser, PHP4 will attach the tokens to the URL.

Tokens
The tokens purpose is to say that the user with this token is logged in, the simplest such token is to have it named logged in and set it to one after the user logged in. This only serves to show that the tokens themselves need to be secured in the sense that we don't want a user to be able to say that he is logged in without going through our login page. After all, in this example the user can just add the cookie by him and he will be regarded as logged in. Bad idea!
Ankit Gupta 5

Term Paper On Web Authentication

The simplest scheme for the tokens is to have a token called username and a token called password which will hold the users username and password, respectively. However it is possible to intercept this on the way and so it's insecure in the sense that someone can listen and learn the password. A simple and the most effective method is to have a session id that will be a random number attached to the user at login time and have all info on the server attached to this session id, when the user logs off the session id and it's associated information is dropped and so it poses no large problem. It is possible for an attacker to use the session ID of the user but that is only useful as long as the user is logged in, we will see later on that this is unavoidable under normal circumstances.

Audience
This document is aimed at programmers who are developing web applications that communicate with their users' Google services and who want to implement a programmatic way to gain access. It assumes you've read up on the service(s) being accessed and are aware of any access/authentication issues involved. You need to know some servicespecific details when incorporating use of the Authentication proxy service. Example Scenario Users of Google Calendar manage their schedules, add, update, or delete events, and share calendar information. In this scenario, you want your application to access your users' Google Calendar data and manipulate that data on their behalf. To do this, your application needs to get access to your user's Calendar account. Before accessing the Calendar service, the application must request authorization from Google. It does so by calling the Google Authentication URL and supplying some required information, such as the name of the service to be accessed. A Google page is displayed that prompts the user to either consent or refuse to provide access to their Google Calendar account.

Ankit Gupta

Term Paper On Web Authentication

If the user consents, Google redirects the user back to your web application and supplies an authentication token for the requested service. Your web application can then make requests directly to the Google service, referencing the token in each request. The Authentication Process Authentication for web applications involves a sequence of interactions between three entities: the web application, Google services, and the user. This diagram illustrates the sequence:

1. When the web application needs to access a user's Google service, it makes an AuthSub call to Google's Authentication Proxy service. 2. The Authentication service responds by serving up an Access Request page. This Google-managed page prompts the user to grant/deny access to their Google service. The user may first be asked to log into their account. 3. The user decides whether to grant or deny access to the web application. If the user denies access, they are directed to a Google page rather than back to the web application. 4. If the user grants access, the Authentication service redirects the user back to the web application. The redirect contains an

Ankit Gupta

Term Paper On Web Authentication

authentication token good for one use; it can be exchanged for a longlived token. 5. The web application contacts the Google service with a request, using the authentication token to act as an agent for the user. 6. If the Google service recognizes the token, it supplies the requested data.

Basic Protocol
The simplest such protocol is employed by web servers for the Basic Authentication, this is also the default protocol for authentication by the webserver, when you get a popup window to ask for a username and a password this is the basic authentication of the webserver, it is usually done with the htaccess file in Apache. In this protocol the server asks the user for authentication and the user provides the user and password, the web server then compares the password with the copy it has stored on file and allows access. All the data is transfered as-is, this means that anyone who can listen to the communication will learn the password. Listening on the communication line is called sniffing and is not so hard to do, so we want something that has better security.

Ankit Gupta

Term Paper On Web Authentication

quapro-arch of Web Authentication

Improved Protocol
The immediate solution is to encrypt the password in transit by some key, however this is not usually possible because both sides need to know the key beforehand. There are methods to create such a key on the fly but these algorithms are not suitable for implementation in the a regular web application. The solution for this is to use a Hash function, a Hash function is a oneway function, and that is, given some input it returns a number, the one way property means that if the sniffer gets the resulting number he will not be able to find an input that will generate this number. The two hash functions that are in wide use are MD5 and SHA1, MD5 returns a 128 bit number and SHA1 returns a 160 bit number. The number is

Ankit Gupta

Term Paper On Web Authentication

usually converted to hexadecimal notation in which each 4 bits are translated into a character that is easy to store and display. The authentication method now is switched to have the user send the username and the hash of the password instead of the password itself. The server cannot find from the hash what was the password the user types, but since the server knows the password from beforehand (during registration) it can compute the hash by itself and then compare the received hash with what it computed. This means that anyone who is listening will not learn the password and so supposedly he cannot enter the web-site as this user.

Final Protocol
Stopping at this point would have made this article rather short, luckily for us there is a hole in the above scheme. The hole in this scheme is that the sniffer now has the hash and since all we need is to send the username and the hash he can simply send them without knowing the password! So the problem now is that even though the sniffer can't learn the password he can still login, what are we to do? We solve this by adding a random variable, called salt, that is for each time the user logs in the server will send some random number, now the user will send the hash of the random number and the password, this way the hash will be unique for each login and the sniffer will not be able to login even if he gets some hash, since he'll need to get the hash for each random number that the server might send, if we make sure to have a choice from a large enough pool the sniffer will have a lot of trouble to get the access he so covets. A large enough salt will be at least 10 characters long, this will be enough to defeat most attackers, the longer the salt is the larger the work that the sniffer needs to do to have a chance, but the cost to the site is neglibigle. One thing that needs securing is making sure that these login requests with the salt will timeout after a short while, otherwise the sniffer will just use an old login to get into the system. This means that the server needs to
Ankit Gupta 10

Term Paper On Web Authentication

keep the last salt it sent for a user and a timestamp saying when it was sent. If a login is attempted with a different salt or after more than some predefined time the login is automatically denied and a new salt generated and provided. After all this work and revisions to the basic protocol we are still insecure, there are several problems that we cannot solve in the usual framework and will only be able to solve with external means, however, for most purposes and for most sites such an authentication method is sufficient, obviously if you work for a bank you should be looking for something better but for a web log or simple personalization you could go without the extra bother.

Unsolved problems
The first and foremost problem is that a sniffer even in the last protocol can hear the login sequence and as long as the real user is logged in the sniffer can use the authentication tokens of the logged in user to access the site. A stopping for this can be done by adding the IP address of the user to the hashed password and verifying that the request comes from that IP address, this will have the effect that the sniffer will also be forced to fake the real users IP address, however since the sniffer sees all messages between the user and the server he can also fake the IP address with relative ease, but this still imposes extra work that he will need to go through. Another possible problem that we haven't addressed is the possibility of a Man-In-The-Middle attack, that is, the sniffer could go active and simply catch all the traffic between the site and the user, read it and send to the site everything it wants, this means he can also change user commands and fake responses. This is a serious problem, but for most sites it is very unlikely that someone will go to the bother of doing such a thing. The only solution for these problems is to use a secure channel, the secure channel is usually an encrypted transmission channel, where the two sides have a shared key that only they know and so no one can read their
Ankit Gupta 11

Term Paper On Web Authentication

communication or fake it. Creating such a secure channel will not be covered as it requires an article (or a book) of its own. A secure channel can give protection against sniffing and against ManIn-The-Middle attacks; this is because the sniffer cannot know the password in advance. With a good protocol for the setup of this secure channel the sniffer will also be unable to impersonate the server. A standard way to initiate a secure channel is SSL (Secure Sockets Layer) which is the usual encryption used for web sites. With SSL the server has a key and a certificate from some known Certificate Agency (CA), the CA has a key that is distributed with the browsers and so when a browser hits an SSL website it asks for the certificate and can verify it, if the certificate verified ok the browser will trust the server key and will initiate a secure channel to it. The main drawback for SSL and the reason it is not so widely used for non e-commerce sites, is that it requires the server to pay for a certificate which has an expiration date and thus must be renewed every one or two years, also the processing time that is associated with encrypting and decrypting the secure channel is several times greater than a simple nonencrypted channel.

User Privacy The system transmits user credentials over a secure channel-:
Whenever users log in, set personal information, answer secret questions, etc., and always be sure to use SSL for the connection. Further, make sure that you specify a unique realm for all SSL pages to be sure that the information is not revealed when browsing to non-encrypted pages. Many Web sites such as Hotmail and Yahoo! do provide secure login pages, but this is not the default option; users must click on another link to log in securely.

Passwords stored using a strong hashing algorithm

Ankit Gupta

12

Term Paper On Web Authentication

You should never store a user's password in plain text. At a minimum you should use as strong encryption algorithm. The best thing to do is not store the password at all, but creates a hash of the password using a message digest or one-way hashing algorithm. These algorithms derive a hash that cannot be used to determine the original password. The occurrence of any two passwords creating the same hash is extremely rare, so this method is very secure. To verify a password, you hash the user's input and compare it with the hash stored in the database. In most cases, a Web site does not need to know a user's password; they just need to know that the user knows it. Hashing algorithms accomplishes that.

Session Authentication Anyone bypass authentication by accessing a module directly-:

To avoid backdoors, make sure that every protected resource authenticates the user's session. Never assume that a user will follow the correct path to a protected resource and never assume that an obscure filename will protect from unauthorized access.

The system allow authentication to the Web server's operating system or network-:
Many Web authentication systems are tied to operating system accounts. While this may be convenient for some purposes, you must carefully consider the consequences of doing this. For example, an attacker may be able to use your authentication system to guess passwords on administrator or other privileged accounts. They may also be able to lock out or otherwise impair important system accounts. If you do use operating system accounts, limit the scope of logins through carefully planned user groups, organizational units, or even using separate domains.

Users have the option to log out of their session-:

Ankit Gupta

13

Term Paper On Web Authentication

Always provide a conspicuous log-out link that abandons the session and destroys any session tokens. Make sure that users know that the safest way to end a session is to click on the log-out link.

The system destroys session tokens upon logging out or timing out-:
I have seen systems that delete any existing session tokens for users after they are authenticated. But you should also delete session stale tokens. Even better, add a timestamp to session tokens so that they expire after a period of time, even if the session has not timed out from inactivity. Every Web page should check the validity of a session token and require re-authorization if necessary.

The system prevents account hopping-:

A common programming flaw is to check a user's log in, then set a flag that indicates that the user is authenticated. Instead, you should generate a session token that is only valid for that user and check that token on each page. Otherwise, users may be able to switch to another user's account through URL or cookie tampering. For example, consider this URL: http://www.example.com/users/accountinfo.asp?userid=1254 My first thought when seeing a URL like that is to see what happens if I change the userid value to something like userid=1253, or even better, userid=1. If this system only looks at an authentication flag, it might let me view the details of someone else's account.

Cookies A hijacked cookie allows a user logon-:

Writing a persistent cookie to a user's system may be convenient but it is also a great security risk. If an attacker is somehow able to hijack a user's cookie, the user's account will be compromised. Other alternatives you may consider are to only provide limited account access without re-authentication

Ankit Gupta

14

Term Paper On Web Authentication

or to tie the cookie to other identifying information such as IP address, User Agent string, etc. Nonetheless, all cookies should have a reasonable fixed expiration date that requires re-authentication. Ultimately, the best solution is to require a login every session. Account hijacking can be a serious issue for users but can affect you as well. Say, for example, that a user places a large order but later says it was fraudulent; that someone else hijacked his or her account. If you require a login each session, it becomes more difficult for users to repudiate transactions on their account. Some of the world's largest Web sites have an option to automatically log in from a cookie. If you do this, keep in mind that the person logging in could either be the user, anyone who knows the user's password, anyone who has physical access to the user's computer, anyone with administrative network access to the user's computer, anyone who has broken in to the user's computer, or anyone who can see the network to sniff traffic. If you want to ignore this advice and allow automatic log in using cookies, at least give users the option to not save or erase cookies. You can erase a user's cookie by sending them a blank, expired cookie.

Sensitive information stored in cookies-:

Account login is not the only risk with cookies. Many sites store personal account information in cookies. Never store actual user information in cookies; rather, store a token that points to user information on the server's database.

Cookies marked as secure-:

According to RFC 2109, cookies can be marked secure, preventing their transmittal to non-SSL Web pages. But many Web sites overlook marking cookies as secure. The problem with this is that if a user browses from a secure page to a non- secure page on the same site, the browser will continue to send the cookie. If a cookie is marked as secure, the browser will not send it to non-secure pages.

Ankit Gupta

15

Term Paper On Web Authentication

Cookies specify a domain and path-:

Cookies also have Domain and Path properties to limit a cookie's scope. If you fail to set boundaries for cookies, it may be possible for an attacker to exploit a cross-site scripting flaw on another Web page or even another server to hijack a user's cookie.

General Principles
Beyond these questions you should step back and ask yourself if your Web authentication system follows generally accepted best practices. For instance, does the system use multiple layers of defense? Does it properly limit the scope of trust? Is it simple and does it maintain a minimal attack surface? Does the system properly prevent spoofing, tampering, repudiation, information disclosure, denial of service, and privilege escalation attacks? Despite the dramatic increase in security education and training over the last few years, passwords continue to be security's weakest link. Your Web application must do its part in keeping passwords secure. Some may argue that the principles in this article are a bit extreme, and perhaps it is just wishful thinking on my part for suggesting them, but they are a standard by which you can measure your own security. Obviously, you must take into consideration the unique risks and exposures of your own Web site. If you use user logins as a casual means to identify users, maybe all these security measures do not make sense. But if you are a financial, medical, educational, or government institution, maybe you should take a good hard look at your authentication system.

Conclusion
The final conclusion is that we have a relatively simple authentication method which is moderately secure against passive attacks, the sniffing, but is not secure against active attacks, such as IP address faking. We cannot have anything that is much better than that without encryption but for most websites such a method will suffice.

Ankit Gupta

16