Web Authentication 101

25 Dec 2014

Web authentication is commonly built on top of three technologies: Cookies and Hashing and Database. Read on …

Cookies

Cookies are set (by web server) or sent (by client) through HTTP headers. The headers use the following formats:

Set-Cookie: name1 = value1; name2 = value2

Send Existing Cookies

Cookie: name1 = value1; name2 = value2

It is clear from the syntax above that semicolon is used to separate multiple name-value pairs, therefore, it is wise to avoid using it in the values of your cookies, otherwise your cookies might be corrupted.

Cookies are used to store temporary stateful information since HTTP has no states; and in the web authentication context, cookies are used to store user identification as part of the ‘login/registration’ mechanism.

Further reading about HTTP Cookie: Wikipage.

Hashing

Hashing is used to protect the integrity of a cookie as well as user passwords stored in the backend database.

For the cookie integrity part, Hashed-based Message Authentication Code or HMAC is a commonly used technique. Python has an hmac module to do just that.

For the passwords protection part, normal hashing (not HMAC) is used to make sure passwords are not stored in plaintext; in other words, if the data in the database gets stolen, user credentials will not be immediately usable. Additionally, to further protect hashed passwords from brute-force attack like rainbow tables, passwords are usually combined with salt before hashing.

Wonder how to make salt? Check out this page.

Hashing with standard hashing algorithms like SHA256 is designed to be fast, which is good for validating cookies and so on. However, for passwords, where brute-force attack is more likely, a ‘slow’ algorithm is more desirable: meet bcrypt.

Bcrypt implementation in python: py-bcrypt.

Database

In a registration-login system, database is often used to store user crendentials (like username, passwords, last visited and so on). With such information stored in a database, a website can use it to determine things like a. if a username is already a registered one, b. the user trying to login has the right username-password combination.

Putting It All Together

Here is what typically happens when a user tries to sign-up:

  1. username and password sent to the server from a client browser (by method POST)
  2. server checks if username exists and validity of username and password
  3. assuming check passed, server store username and password in a database
  4. server then sends response to client brower with Set-Cookie: header containing user-id information
  5. server redirects user to the homepage of the website
  6. client brower therefore sends a request to website homepage with Cookie: header containing user-id information
  7. server verifies the cookie sent and determine if the client is a registered and valid user

Here is what typically happens when a user tries to login:

  1. client browser sends out username and password typed in by the user (by method POST)
  2. server receives request and checks username exists and validity of username-password combination
  3. assuming check passed, server sends response to client brower with Set-Cookie: header containing user-id information
  4. server redirects client brower to the homepage of the website
  5. client brower therefore sends a request to website homepage with Cookie: header containing user-id information
  6. server verifies the cookie sent and determine if the client is a registered and valid user

Here is what typically happens when a user tries to logout:

  1. client browser requests logout page (by method GET)
  2. server sends response to reset client cookie with Set-Cookie: header containing empty user-id information
  3. server redirects client brower to signup or login page of the website

From the above protocol, it is clear that web server knows if a user is logged-in or signed-up or logged-out by checking the validity of the cookie being sent by client brower!

HTTPS

Now passwords are stored securely on the server, but, not yet sent securely over the wire. A man-in-the-middle attack could sniff off the passwords since they are sent in cleartext.

To prevent this, the messages being sent between client and server need to be encrypted. This is done through HTTPs protocol, which is just HTTP but with the channel encrypted over SSL.