- From: Peter W <peterw@usa.net>
- Date: Sat, 6 Jan 2001 17:32:50 -0500 (EST)
- To: Joris Dobbelsteen <joris.dobbelsteen@mail.com>
- cc: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
> > - the "cookie standard" has progressed quickly and
> >supports all of the
> >things that regular authentication should have supported a
> >long time ago:
> >
> > - passing a "server key" to be added to the digest,
> >which can then
> >be expired on the server
> > - setting expiration times
>
> An issue with IE is the fact that passwords with forms are still stored.
Can be overcome/forbidden with HTML code.
The big problem with http + Basic auth is the static authentication
information is sent cleartext. Easy replay. I've outlined a
application-based solution in Bugtraq. Basically:
- login to https://server/login/path
- get at least two cookies:
insecure "ticket" contains server-generated unique value that
can be used to lookup user info when requesting protected pages
secure ticket "check", only to login server, only to login path
[if you serve https content, an "httpsticket" as well]
- central repository matches "ticket" to user, various stateful info
- at logout, the server marks the ticket as invalid; no replay
- periodically, content server can redirect user back to
https://server/login/path/verify?sendbackto=http://content/foo.html
- /login/path/verify checks for presence of both "ticket" and "check";
a net-sniffing bandit will lack "check"; at that point the "ticket"
is marked in the repository as 'tainted'; when the good user requests
another document, that user is warned about the taint, required to
log in again
The login system can be any system you prefer. user/pass, hardware token,
client certificate, whatever. The key is
- attackers can't see the authentication data
- they can't replay the insecure cookie, not for long, anyway
> Next, what if an adversary finds a way to use his cookie (obtaining it
> using spoofing or a man-in-the-middle attack (proxies are suitable for
> this)), the adversary can use that cookie on the victim's behalf.
See above.
As for webmail, I've also suggested ways to protect authentication tickets
from hostile email scripting by using one-time tickets for documents
containing untrusted code, e.g. mail reading frames.
> The next version of HTTP should have better security functions than
> currently provides. The current standard doesn't satisfy the requirements
> of many servers, today.
This is the place to make suggestions...
...IMO, with a little creativity the current infrastructure suffices; or,
at least it can't be significantly improved upon.
-Peter
Received on Saturday, 6 January 2001 14:35:41 UTC