RE: mmmmm .. cookies
by jjhorner (Hermit) on May 28, 2000 at 19:07 UTC
|
As a professional web server admin, I'm not a big fan of
using cookies to perform authentication/admission control.
If you are using Apache (and if you aren't, you have no
hope of secure webservers anyway), you can block access
using an .htaccess file or by specifying in the Directory
tag in the httpd.conf file. It is very simple to setup
"accounts" using a www_passwd file and www_group file.
You can even (if using SSL) create the www_passwd file and
synchronize it with your /etc/passwd file at set time periods
so that there isn't a chance of your web accounts and system
accounts passwords from becoming unsynchronized.
Anyone have any different thoughts on using cookies for
admission control? I have always thought it better to use
a DB oriented access method.
Look into Chapter 5 of the Appaloosa book. Good stuff.
I may even post my password syncing script to the snippet
section.
J. J. Horner
Linux, Perl, Apache, Stronghold, Unix
jhorner@knoxlug.org http://www.knoxlug.org
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
Question regarding this:
On a site that I am preparing for rollout, I am implementing a cookie-based authentication, and rather than what appears to be the "standard" method of returning a cookie for the loginId, and a cookie with a one-way encrypted password, I set a (pseudo)random string in the DB when the user logs in, and send that string to the user as a cookie. As I see it, the differences between the two are:
- My method involves more DB overhead (an UPDATE with every login)
- My method does NOT allow more than one client logged in with the same ID at a time.
- My method lets me be lazier and not learn the various MD5 stuff until I have more time :)
The DB overhead isn't a problem for quite a while, but are there any other advantages/disadvantages to this that I'm not seeing?
| [reply] [Watch: Dir/Any] |
|
I would second the htaccess method unless you need to be more flexible about what the user is accessing, or in the event that you cannot restrict access to the current directory. The examples that I can think of would be:
- one cgi-bin, no subdirectories
- timeouts
- access to several items from the same url
- non-Apache webserver
- keeping everything in perl
...just my R$0.02 worth
| [reply] [Watch: Dir/Any] |
|
Can someone tell me what the apaloosa book is?
Thanks.
| [reply] [Watch: Dir/Any] |
|
it took me a little while to find it on O'Reilly's site, but
here
it is: Apache: The Definitive Guide, 2nd Edition.
Chapter 5 regards Authentication.
| [reply] [Watch: Dir/Any] |
RE: mmmmm .. cookies
by t0mas (Priest) on May 28, 2000 at 09:56 UTC
|
You have to check for the cookies on every page not allowed I guess. I usually write som generic printHeaders() sub that I call with arguments
to check stuff. If the other pages are static html pages I would use the webservers security features instead.
/brother t0mas
| [reply] [Watch: Dir/Any] |
A bookmark for you
by Kozz (Friar) on May 28, 2000 at 21:16 UTC
|
You can learn some of the basics of using .htaccess files HERE. | [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
I've never heard using <limit> is a bad thing; what's your aversion to it?
| [reply] [Watch: Dir/Any] |
|
RE: mmmmm .. cookies
by dempa (Friar) on May 29, 2000 at 00:28 UTC
|
Hmmm, I read the other replies to this question, and to
use the servers own authentication modules is probably
the best way to go. However, if daemonchild still wants
to use cookies, maybe the REFERER variable could be of
some use? Or is that stupid? Can it be abused? (Hmm,
well OK.. it most certainly can be abused. Just write
your own snarf/wget/curl type thingy and set the REFERER
variable to the 'correct' value, and you're in. Forget
this comment, please. :] ) | [reply] [Watch: Dir/Any] |
Re: mmmmm .. cookies
by daemonchild (Acolyte) on May 29, 2000 at 03:20 UTC
|
<body>
thanks all!
i am using apache, so the .htaccess method is looking like
the best solution.
your help has been much appreciated.
--steve
</body>
| [reply] [Watch: Dir/Any] |