in reply to mmmmm .. cookies

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

Replies are listed 'Best First'.
RE: RE: mmmmm .. cookies
by merlyn (Sage) on May 28, 2000 at 21:40 UTC
    Cookies can certainly be used as an identification token for authentication and authorization purposes, as long as you remember the golden rule:
    • A user is not a browser
    You must provide a way to timeout a cookie, remove a cookie, and reload the cookie onto a different browser.

    -- Randal L. Schwartz, Perl hacker

[reply]
      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]
RE: RE: mmmmm .. cookies
by BBQ (Curate) on May 29, 2000 at 09:53 UTC
    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]
RE: RE: mmmmm .. cookies
by Anonymous Monk on May 28, 2000 at 20:35 UTC
    Can someone tell me what the apaloosa book is? Thanks.
[reply]
      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]

In Section Seekers of Perl Wisdom