Cookie based authentication: Is it secure?

[rodry]

Most of the web sites I do in PERL involve some type of authentication. I always opt for a cookie based authentication scheme by delivering a session cookie with the username of the person. All the scripts there after check for this cookie, and they also pull its value (in this case, username) to run the required queries to the database.

So here is the question: What are the security implications of this method and what are other (better?) ways of implementing authentication thru the use of cookies.

Thanks in advance.

Originally posted as a Categorized Question.

[Ovid]

The header information with a cookie can look something like the following:

Set-Cookie: user_id:dajohn13; domain=.somedomain.com; path=/cgi-bin;
            expires=Sat, 01-Apr-2003 11:30:00 GMT; secure

That is sent as plain text, which is not secure. Whatever values you set for the cookie can then be sniffed, so sensitive information shouldn't be passed this way.

In the example above, the secure parameter is used, which means that the browser will not return the cooking unless you are using a secure URL with the https protocol. That should provide adequate security and will make your scripts much safer if you plan to use cookies.

[chromatic]

The only thing successfully retrieving a cookie should imply, from a security standpoint, is that, at one time, someone using that particular browser (session, if you're using session cookies) was successfully authenticated. Period.

If I logged in to your site from a public terminal and left the browser open, anyone else could potentially use my cookie.

For some applications, this is enough security. For others, you might save a timestamp of the user's last access and require reauthentication if X minutes/hours/days have passed since the last transaction.

In general, if you don't store too much information in a cookie and if you realize the implications of what I've said above, this is a decent method of saving state.

[wardk]

Recently used cookies for authentication at a customer site. While I can't submit any code from that particular project. Here is how I addressed the problem.

1. Use an SSL site to encrypt the html form
2. Created a seed string in my local SQL database for doing the encryption/decryption using crypt
3. processed user input, taking password and encrypting it with the seed, compare to that users encrypted database password for a match
4. if the above passed validation, I then took some more info I would need later and created another encrypted string, storing it all as one ugly cookie. I also stored the userid as a cookie, in the clear.
5. every time the user hit the database, I'd take the clear userid cookie, nab the known user info I'd store for that "real" user and encrypted it all over again.
6. if the above ugly string matched the ugly cookie, they continue, else they'd get kicked back to the login screen.

Some of the "extra" data I encrypted was date info, so it also acted as a user timeout. (handled by my program, not using a cookie "expire")

Not sure I've explained it clearly, but this technique worked, and worked fast.

One gotcha is crypt can create some characters that can get hosed sending via the server, so I had some additional escape'ing of non-valid cookie characters.

Since I seemed to have rambled a bit here, and I am pressed for time, feel free to email me for a clearer explantion. [e-mail]

[tilly]

Ovid already explained the security issue.

Unless you encrypt the whole site (which is a huge performance hit) you should assume that any data sent in cookies is meant to be public and will be used by someone trying to break in. Think about that before passing passwords and credit card numbers around.

Currently standard https authentication will cost money in the US. However in a couple of months the RSA patent expires and you will be able to both legally and freely use mod_ssl with Apache. Outside of North America this patent does not hold and you can use mod_ssl without legal worries. Certainly things like credit card information should only be passed through https. (In fact as an anti-fraud measure VISA is introducing new standards that will disqualify any merchant that sends credit card information over http!)

An alternative for simple authentication that I find interesting is turning a form into http authentication like Hotmail does. Quite a few FAQs say that this is impossible, but it is not and I explained the procedure in Put name and password in URLs.

[Anonymous Monk]

Another way to keep this secure is discussed in the book Writing Modules for Apache with C and Perl (O'Reilly's "mod_perl" book, basically :).

Store a random string (generate it however you want; talk to the cryptography experts for advice if you want it to be truly random :) on the server that nobody has access to except the processes on the server that handle authentication. When a user logs in, store a cookie on his local machine that contains a few variables (like username, last access time, etc.) but *not* the user's password or the secret key.

The other field to store should be a hash. The example the mod_perl book shows just uses MD5 -- you build a string concatenating that secret key, the user name, login time, last access, requesting IP address, etc. then send that hash along with the rest of the fields.

The upshot of this is you can detect tampering of the cookie (copied to another box, changed username or last-access time, etc.) and immediately kill the session it refers to (or take whatever action you want) when you notice the difference. The fields in the cookie are only valid if the hash is also valid, and only the server can create a valid hash.

Combine this with a check to see how long it's been since the user last access a secured page, and if it's over your threshold (say 30 minutes) you immediately redirect to a login page and only on success would you redirect back to the session. It's a VERY neat example in the book.

[sinan]

There is something you can do to insure security. Everytime a user logs on, generate a random number, put it on the user's machine as a cookie.

print "Set-Cookie: temp-id=$random_no; domain=yourdomain.com; expires=
+".($now+3600);

At the same time, write the same $random_no to a DB on your server, as well as the user's username. So, you can now identify the user using a temporary id.

Hope this helps,

Sinan