Re: Cookie based authentication: Is it secure?⭐
by Ovid (Cardinal) on Aug 28, 2000 at 01:16 UTC
|
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. | [reply] [d/l] |
Re: Cookie based authentication: Is it secure?⭐
by chromatic (Archbishop) on Aug 28, 2000 at 03:10 UTC
|
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. | [reply] |
Re: Cookie based authentication: Is it secure?⭐
by wardk (Deacon) on Aug 28, 2000 at 21:14 UTC
|
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.
- Use an SSL site to encrypt the html form
- Created a seed string in my local SQL database for doing the encryption/decryption using crypt
- processed user input, taking password and encrypting it with the seed, compare to that users encrypted database password for a match
- 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.
- 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.
- 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. wardk@wardk.org
| [reply] |
Re: Cookie based authentication: Is it secure?⭐
by tilly (Archbishop) on Aug 28, 2000 at 04:44 UTC
|
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. | [reply] |
Re: Cookie based authentication: Is it secure?⭐
by Anonymous Monk on Apr 22, 2002 at 21:34 UTC
|
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.
| [reply] |
Re: Cookie based authentication: Is it secure?
by sinan (Sexton) on Aug 30, 2000 at 12:24 UTC
|
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
| [reply] [d/l] [select] |