- From: David W. Morris <dwm@xpasc.com>
- Date: Wed, 3 Jan 2001 13:19:02 -0500 (EST)
- To: Erik Aronesty <erik@primedata.org>
- cc: Tom McLaren <tom@mclaren.tc>, http-wg@cuckoo.hpl.hp.com
On Wed, 3 Jan 2001, Erik Aronesty wrote: > The site cannot easily know whether or not the request was coming from the > cache or the client... unless the cache tells it. > > Thus the server always relys on a "third party" (the browser or the > cache)... to manage or respect authentication "state". > > It's just an oversight that cookies are "expirable" (they have timeouts and > they can be forced by the server to expire) and usernames/passwords aren't. > > In a way, "cookies" are "more secure" than the security mechanisms built > into http. Except that as V1 cookies are implemented, once you set an expiration, even short on a cookie, it is written to the user's hard drive. An immediate exposure which to me negates any value in a timeout. What makes cookies more secure is that they can be used via a random opaque token as the value to create a server side notion of a session which can have expirations, sliding timeouts, re-authentication, etc. And if an application logout button is clicked, the cookie can be totally reset by client side javascript OR a serverside update. I've led a number of teams building web based applications and have never found http level authentication worth using. The user experience is confusing at best, the server side authentication processing excessively complex, error handling impossible to control, etc. It takes writing your own web server or complex ISAPI/NSAPI exits to control the interaction with application authentication mechanisms. So again cookies win. Dave Morris
Received on Wednesday, 3 January 2001 10:22:49 UTC