l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2002 Aug 07 12:33

The following is an archive of a post made to our 'vox mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
[vox] Semi-OT: HTML, HTTP, authentication, revocation of auth
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vox] Semi-OT: HTML, HTTP, authentication, revocation of auth

ME writes:
 > There is something with web browsers with HTTP  that has caused me to to
 > wonder about authentication ever since the early days with Mosaic. It has
 > bugged me, but never enough to really work at researching it - until now.
 > When you use the "standard" authentication
 > (example, within apache, use of a .htaccess file with:
 > AuthType Basic 
 > AuthUserFile /path/to/a/password/file
 > AuthName "special restricted directory"
 > require valid-user 
 > )
 > The client is required to authenticate before they may see the content of
 > that dir. If they choose a valid user (one in the password "file" above
 > that has a good password) then they are permitted to continue. However,
 > their authentication is cached in the memory used by their local
 > browser. While the browser is left running, any user using that browser
 > session can walk through any other part of that site or posibly other
 > similar sites without being prompted for a username and password again.
 > So here are my questions:
 > Is it possible to write HTML that would be understood by all browsers to
 > tell them to "forget" about all previous valid username/passwords
 > (authentication)? (This may be a kind of META HTML, or non-standard that I
 > don't know about.)
 > If there is no HTML, or Meta-HTML, is there something that can be done
 > with JavaScript or Java to solve this? If you have experience with it, how
 > consistent is enforcement of things like authentication timeouts, timed
 > escrow, or ?

I believe the usual way to cause a password to be "forgotten" is to
vary the authentication realm ("AuthName", in your .htaccess...).

To handle this, you'll either need to write an Apache filter, a CGI
script, or use an SSI directive which will generate the appropriate
headers (being sure to indicate to Apache that it should use those
headers and not its own).

The relevant RFC on HTTP authentication is RFC 2617:


 > I have a particular section of web pages behind an SSL Service (https)
 > where users authenticate to use WebDAV, change their passwords (cgi page),
 > see the webalyzer reports, search the logs for certain hits with rDNS and
 > jwhois on busy IPs, and check on the status of their web account space. In
 > the case of the CGI for changing passwords, they are required to enter a
 > password to get to the page (using the basic auth system but over SSL) and
 > then the CGI also requires them to re-enter their username/password and
 > compare the username entered with that of the auth session (ENV VAR) and
 > the password after crypt/md5 hash (whichever is used) with that of what is
 > stored in the password file. All of these checks are fine and good, but a
 > user who has left a browser running with the basic auth still cached may
 > permit a non-authorized user to view content within the priv user
 > space.
 > I would like to include a timeout - where after that timeout is reached,
 > the web browser is forced to "forget" the basic authentication and require
 > the user to re-authenticate to view the page.

You could consider cookies; these are easily expirable, and might
serve your purposes better than Basic Authentication. Of course, this
requires that the user allow cookies from your site...

 > Surely, I know the user could just quit the web browser, and restart to
 > eliminate the basic authentication cache (assuming they did not enable
 > some additional password caching system.)

Usually, I think it's okay to leave this up to the user - nearly every
other site does.

Naturally, I'm not suggesting that users are generally competent
enough to manage their own security - but, you can't take
responsibility over *everything*... I think, if they can be "trusted"
to set their own passwords, they can be "trusted" not to leave their
browser unattended if they are worried about someone using their
already-authenticated password...

vox mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.