Logging In: Background Details

Question

What happens when you log into a website?

I know cookies are stored and some info (what info?) gets sent to the server...but maybe some more detail?

Answer 1

Once upon a time, somewhere on the Internet....

• Browser: "hey, can I see this web page?, Trouble is, I don't remember speaking to you before"
• Website: "sure, fill in the form, I need your username and your password"
• Browser: "Here ya go"
• Website: "Great!, Welcome back koldfyre! Here's the page. Look, if you want more pages, take this token and use it when you ask for another one"
• Browser: Cool. That site gave me a token. I'll memorize it!

A few minutes later

• Browser: "Ooh! Can I see this other web page? Here's my token"
• Website: "That token looks good, hello again koldfyre, here's your web page"

That, in essence, is it. In order to remember a user has logged in, it gives the user a token which it must present with its next request. This is normally achieved by the server telling the browser to store this token in a cookie.

Delving deeper - transport layer authentication

The way the credentials are passed to the server, and the nature of the token it returns, vary depending on the authentication method employed.

The very simplest, HTTP Basic Authentication, is provided by most web server implementations. It causes your browser to pop open the familiar login dialog box. The "token" is simply your plaintext username and password base64 encoded. Not particularly secure.

A server might also provide Digest Authentication, which avoids transmission of the actual credentials - the client instead generates a hash of their credentials with a server generated salt. It is designed to prevent password sniffing and replay attacks.

Deeper still - application layer authentication

For maximum flexibility and control, most sites opt to implement the authorization in the application layer rather than the HTTP transport layer. This gives a wider variety of security choices. Any site which asks for credentials in a web page (rather than the browser's login dialog box) is using a custom authorization method.

Custom methods will vary wildly in their initial interaction, but they almost always result in the user being given a session cookie containing a randomly generated identifier. The browser then automatically presents the cookie with each subsequent request. The web application will inspect the cookie value to ensure it is still valid.

It's also possible to hand off the authorization to a trusted third party, generally to provide some sort of single-signon service. In cases like that, when you notice a user isn't authenticated, you bounce them off to the authentication provider. They authenticate them, and they will be returned to you with some kind of token you verify with the provider. Shibboleth is one example of this. You also logged into this very site using a similar method employed by OpenID

Further reading

Here's some nice answers from a similar question

• PART I: How To Log In
• PART II: How To Remain Logged In - The Infamous "Remember Me" Checkbox
• PART III: Using Secret Questions
• PART IV: Forgotten Password Functionality
• PART V: Checking Password Strength
• PART VI: Much More - Or: Preventing Rapid-Fire Login Attempts
• PART VII: Distributed Brute Force Attacks

Other answers in that question provide even more links to round out your education!

Answer 2

That's a pretty general question. What you're doing, over all, is establishing some kind of credentials with the site itself. If we take the simple version, you enter a user name and a password; that means you identify yourself to the website, and then show it a secret you and the website share that no one else knows (we hope). That establishes you as authentically the person with that user name, and so we say you have authenticated yourself.

Once you've done so, there are some design decisions the website designer has to make. most people don't want to log in for every page, so the web site wants to store a little information, a credential, on your end. This means that it can tell it's still you. Often, as you say, that's a "cookie", which is nothing more that a tiny text file named with the web site's URL. This file is stored by the browser.

On many web sites, like for banking, you also want to guarantee that the data being exchanged can't be intercepted by a third party. If so, you establish a secure connection using a protocol known as SSL or TLS. What this adds to the basic connection is an exchange of information that establishes a session key. This session key is then used to encrypt the communications. This usually happens before you exchange the user name and password, so that your password is never visible to a malicious third party either.

Under the covers, when you establish a secure connection, the web site sends your browser a block of formatted data called an x509 certificate. This is another form of authentication; the certificate will have been signed by an issuer (the certificate authority or "CA") and the browser can use stored data about the CA's to ensure that the certificate is authentic.

Answer 3

This completely depends on the implementation of the website. Even the usage of cookies is not mandatory, but very common.

In most cases however, something like this happens:

• You send in your username and password using an HTML form.
• The server looks up the relevant user (using a database)
• The server checks if the password matches the password that is stored in the database alongside the user.
• If the password is correct, the server will store what user currently is active in the session. The identifier of this session is stored in a cookie, the actual data of this session (the current user) is stored on the server under this identifier.

Now you are logged in. You will remain logged in during the remainder of the session:

• When you request another page from the server, you will send the cookie with the sesison identifier.
• The server loads the session using this identifier. In this session, the current user is stored, so the server knows what user is logged in.