On the web, a web server is usually authenticated to users by using SSL or TLS and a server certificate - but it’s not as easy to authenticate who the users are. SSL and TLS do support client-side certificates, but there are many practical problems with actually using them (e.g., web browsers don’t support a single user certificate format and users find it difficult to install them). You can learn about how to set up digital certificates from many places, e.g., Petbrain. Using Java or Javascript has its own problems, since many users disable them, some firewalls filter them out, and they tend to be slow. In most cases, requiring every user to install a plug-in is impractical too, though if the system is only for an intranet for a relatively small number of users this may be appropriate.
If you’re building an intranet application, you should generally use whatever authentication system is used by your users. Unix-like systems tend to use Kerberos, NIS+, or LDAP. You may also need to deal with a Windows-based authentication schemes (which can be viewed as proprietary variants of Kerberos and LDAP). Thus, if your organization depend on Kerberos, design your system to use Kerberos. Try to separate the authentication system from the rest of your application, since the organization may (will!) change their authentication system over time. The article Build and implement a single sign-on solution discusses some approaches for implementing single sign-on (SSO) for intranets.
Many techniques for authentication don’t work or don’t work very well for Internet applications. One approach that works in some cases is to use “basic authentication”, which is built into essentially all browsers and servers. Unfortunately, basic authentication sends passwords unencrypted, so it makes passwords easy to steal; basic authentication by itself is really useful only for worthless information. You could store authentication information in the URLs selected by the users, but for most circumstances you should never do this - not only are the URLs sent unprotected over the wire (as with basic authentication), but there are too many other ways that this information can leak to others (e.g., through the browser history logs stored by many browsers, logs of proxies, and to other web sites through the Referer: field). You could wrap all communication with a web server using an SSL/TLS connection (which would encrypt it); this is secure (depending on how you do it), and it’s necessary if you have important data, but note that this is costly in terms of performance. You could also use “digest authentication”, which exposes the communication but at least authenticates the user without exposing the underlying password used to authenticate the user. Digest authentication is intended to be a simple partial solution for low-value communications, but digest authentication is not widely supported in an interoperable way by web browsers and servers. In fact, as noted in a March 18, 2002 eWeek article, Microsoft’s web client (Internet Explorer) and web server (IIS) incorrectly implement the standard (RFC 2617), and thus won’t work with other servers or browsers. Since Microsoft don’t view this incorrect implementation as a serious problem, it will be a very long time before most of their customers have a correctly-working program.
Thus, the most common technique for storing authentication information on the web today is through cookies. Cookies weren’t really designed for this purpose, but they can be used to support authentication - but there are many wrong ways to use them that create security vulnerabilities, so be careful. For more information about cookies, see IETF RFC 2965, along with the older specifications about them. Note that to use cookies, some browsers (e.g., Microsoft Internet Explorer 6) may insist that you have a privacy profile (named p3p.xml on the root directory of the server).
Note that some users don’t accept cookies, so this solution still has some problems. If you want to support these users, you should send this authentication information back and forth via HTML form hidden fields (since nearly all browsers support them without concern). You’d use the same approach as with cookies - you’d just use a different technology to have the data sent from the user to the server. Naturally, if you implement this approach, you need to include settings to ensure that these pages aren’t cached for use by others. However, while I think avoiding cookies is preferable, in practice these other approaches often require much more development effort. Since it’s so hard to implement this on a large scale for many application developers, I’m not currently stressing these approaches. I would rather describe an approach that is reasonably secure and reasonably easy to implement, than emphasize approaches that are too hard to implement correctly (by either developers or users). However, if you can do so without much effort, by all means support sending the authentication information using form hidden fields and an encrypted link (e.g., SSL/TLS). As with all cookies, for these cookies you should turn on the HttpOnly flag unless you have a web browser script that must be able to read the cookie.
Fu [2001] discusses client authentication on the web, along with a suggested approach, and this is the approach I suggest for most sites. The basic idea is that client authentication is split into two parts, a “login procedure” and “subsequent requests.” In the login procedure, the server asks for the user’s username and password, the user provides them, and the server replies with an “authentication token”. In the subsequent requests, the client (web browser) sends the authentication token to the server (along with its request); the server verifies that the token is valid, and if it is, services the request. Another good source of information about web authentication is Seifried [2001].
One serious problem with some web authentication techniques is that they are vulnerable to a problem called "session fixation". In a session fixation attack, the attacker fixes the user’s session ID before the user even logs into the target server, thus eliminating the need to obtain the user’s session ID afterwards. Basically, the attacker obtains an account, and then tricks another user into using the attacker’s account - often by creating a special hypertext link and tricking the user into clicking on it. A good paper describing session fixation is the paper by Mitja Kolsek [2002]. A web authentication system you use should be resistant to session fixation.
A good general checklist that covers website authentication is Mark Burnett’s articles on SecurityFocus.
The login procedure is typically implemented as an HTML form; I suggest using the field names “username” and “password” so that web browsers can automatically perform some useful actions. Make sure that the password is sent over an encrypted connection (using SSL or TLS, through an https: connection) - otherwise, eavesdroppers could collect the password. Make sure all password text fields are marked as passwords in the HTML, so that the password text is not visible to anyone who can see the user’s screen.
If both the username and password fields are filled in, do not try to automatically log in as that user. Instead, display the login form with the user and password fields; this lets the user verify that they really want to log in as that user. If you fail to do this, attackers will be able to exploit this weakness to perform a session fixation attack. Paranoid systems might want simply ignore the password field and make the user fill it in, but this interferes with browsers which can store passwords for users.
When the user sends username and password, it must be checked against the user account database. This database shouldn’t store the passwords “in the clear”, since if someone got a copy of the this database they’d suddenly get everyone’s password (and users often reuse passwords). Some use crypt() to handle this, but crypt can only handle a small input, so I recommend using a different approach (this is my approach - Fu [2001] doesn’t discuss this). Instead, the user database should store a username, salt, and the password hash for that user. The “salt” is just a random sequence of characters, used to make it harder for attackers to determine a password even if they get the password database - I suggest an 8-character random sequence. It doesn’t need to be cryptographically random, just different from other users. The password hash should be computed by concatenating “server key1”, the user’s password, and the salt, and then running a cryptographically secure hash algorithm. Server key1 is a secret key unique to this server - keep it separate from the password database. Someone who has server key1 could then run programs to crack user passwords if they also had the password database; since it doesn’t need to be memorized, it can be a long and complex password.
Thus, when users create their accounts, the password is hashed and placed in the password database. When users try to log in, the purported password is hashed and compared against the hash in the database (they must be equal). When users change their password, they should type in both the old and new password, and the new password twice (to make sure they didn’t mistype it); and again, make sure none of these password’s characters are visible on the screen.
By default, don’t save the passwords themselves on the client’s web browser using cookies - users may sometimes use shared clients (say at some coffee shop). If you want, you can give users the option of “saving the password” on their browser, but if you do, make sure that the password is set to only be transmitted on “secure” connections, and make sure the user has to specifically request it (don’t do this by default).
Make sure that the page is marked to not be cached, or a proxy server might re-serve that page to other users.
Once a user successfully logs in, the server needs to send the client an “authentication token” in a cookie, which is described next.
Once a user logs in, the server sends back to the client a cookie with an authentication token that will be used from then on. A separate authentication token is used, so that users don’t need to keep logging in, so that passwords aren’t continually sent back and forth, and so that unencrypted communication can be used if desired. A suggested token (ignoring session fixation attacks) would look like this:
exp=t&data=s&digest=m |
There is a potential weakness in this approach. I have concerns that Fu’s approach, as originally described, is weak against session fixation attacks (from several different directions, which I don’t want to get into here). Thus, I now suggest modifying Fu’s approach and using this token format instead:
exp=t&data=s&client=c&digest=m |
Here’s an example. If a user logs into foobar.com sucessfully, you might establish the expiration date as 2002-12-30T1800 (let’s assume we’ll transmit as ASCII text in this format for the moment), the username as "fred", the client session as "1234", and you might determine that the client’s IP address was 5.6.7.8. If you use a simple SHA-1 keyed digest (and use a key prefixing the rest of the data), with the server key2 value of "rM!V^m~v*Dzx", the digest could be computed over:
exp=2002-12-30T1800&user=fred&session=1234&client=5.6.7.8 |
101cebfcc6ff86bc483e0538f616e9f5e9894d94 |
From then on, the server must check the expiration time and recompute the digest of this authentication token, and only accept client requests if the digest is correct. If there’s no token, the server should reply with the user login page (with a hidden form field to show where the successful login should go afterwards).
It would be prudent to display the username, especially on important screens, to help counter session fixation attacks. If users are given feedback on their username, they may notice if they don’t have their expected username. This is helpful anyway if it’s possible to have an unexpected username (e.g., a family that shares the same machine). Examples of important screens include those when a file is uploaded that should be kept private.
One odd implementation issue: although the specifications for the "Expires:" (expiration time) field for cookies permit time zones, it turns out that some versions of Microsoft’s Internet Explorer don’t implement time zones correctly for cookie expiration. Thus, you need to always use UTC time (also called Zulu time) in cookie expiration times for maximum portability. It’s a good idea in general to use UTC time for time values, and convert when necessary for human display, since this eliminates other time zone and daylight savings time issues.
If you include a sessionid in the authentication token, you can limit access further. Your server could “track” what pages a user has seen in a given session, and only permit access to other appropriate pages from that point (e.g., only those directly linked from those page(s)). For example, if a user is granted access to page foo.html, and page foo.html has pointers to resources bar1.jpg and bar2.png, then accesses to bar4.cgi can be rejected. You could even kill the session, though only do this if the authentication information is valid (otherwise, this would make it possible for attackers to cause denial-of-service attacks on other users). This would somewhat limit the access an attacker has, even if they successfully hijack a session, though clearly an attacker with time and an authentication token could “walk” the links just as a normal user would.
One decision is whether or not to require the authentication token and/or data to be sent over a secure connection (e.g., SSL). If you send an authentication token in the clear (non-secure), someone who intercepts the token could do whatever the user could do until the expiration time. Also, when you send data over an unencrypted link, there’s the risk of unnoticed change by an attacker; if you’re worried that someone might change the data on the way, then you need to authenticate the data being transmitted. Encryption by itself doesn’t guarantee authentication, but it does make corruption more likely to be detected, and typical libraries can support both encryption and authentication in a TLS/SSL connection. In general, if you’re encrypting a message, you should also authenticate it. If your needs vary, one alternative is to create two authentication tokens - one is used only in a “secure” connection for important operations, while the other used for less-critical operations. Make sure the token used for “secure” connections is marked so that only secure connections (typically encrypted SSL/TLS connections) are used. If users aren’t really different, the authentication token could omit the “data” entirely.
Again, make sure that the pages with this authentication token aren’t cached. There are other reasonable schemes also; the goal of this text is to provide at least one secure solution. Many variations are possible.
You should always provide users with a mechanism to “log out” - this is especially helpful for customers using shared browsers (say at a library). Your “logout” routine’s task is simple - just unset the client’s authentication token.