Are there any viable alternatives to "classic" cookie authentication?

Question

Is there any way (apart from HTTP authentication, which I gather is inherently insecure over the Internet?) for a "real life" website to handle logins and authentication rather than the traditional way, using session cookies?

Answer 1

HTTP authentication is not insecure when using HTTPs.

Answer 2

HTTP basic authentication is perfectly safe when used with a SSL (https://) website since all HTTP traffic including the credentials will be encrypted. One subjective drawback though is when using this method your users will need to interact with their browser's authentication popup in order to log in to your site.

Answer 3

When you're using https, you can also install a certificate in your client's browser and verify that. myopenid offers this for their OpenID accounts. I have one and it works really well (from the client-side point of view).

Answer 4

To be clear, the only REAL way to do this is through HTTPS.

But, since I assume this is not an option, and I also assume you are looking for a "fully managed login" system, I continue:

Other than HTTPS it is possible to use JavaScript to do secure hashing of passwords on the client side, to prevent revealing plain text passwords over-the-wire, but this is only a half-solution.

The problems with this approach are:

1. A replay attack is still a viable option.
2. Only users with JavaScript enabled would be able to auth in this way.

Another approach is a more complicated challenge / response mechanism:

1. Send a "Challenge" along with the login page.
2. Calculate the hash of the Password + Challenge client side.
3. Submit the login.
4. Calculate the hash of the Password + Challenge (which MUST NOT be trusted in the page request) on the server side, and compare.

And the problems with that:

1. Only users with JavaScript enabled would be able to auth in this way.
2. The PLAINTEXT password must be stored on the server to validate the challenge response, and must be encrypted on disk or otherwise protected.

Now, to be fair, problem #2 is not as big of a danger as it sounds. In fact when you instead use HASH authentication, the hash itself is raised to the level of "key".

At this point it is fairly secure to use a cookie to store a randomly generated login ReferrenceID, similar to their session ID, but the server may want to encrypt using the referring IP as part of the IV or KEY to prevent other users from Hijacking the ReferrenceID.

Anyways, I hope that provides a little bit of direction in the way of your design.

Answer 5

Using SSL for encryption in combination with HttpOnly Cookies to help prevent XSS is your best bet for using cookies. I'm not going to say it is bullet-proof, though.

Answer 6

Firstly, HTTP Auth is secure over SSL other than the fact that you can't implement a true "Logout" functionality. User need to close their browser, which is pretty bad.

Secondly, It you need to use HTTPS in all cases to make it secure, after that you got Basic Auth similar stuff such as "Digest" and "NTLM Auth".

Answer 7

HTTP digest authentication (which is quite a different beast from HTTP basic authentication) is quite secure over straight HTTP, and not at all difficult to implement on the server. Nothing is sent over the wire that could reveal what the password is, just information that allows the client to demonstrate to the server that they have the correct password.

If you want a decent explanation of how to implement HTTP digest authentication in your application, Paul James has an excellent article on it.

The only real problem with HTTP authentication is in the browsers themselves: the UI is terrible, but that can be overcome with some Javascript.