RE: Logout

> >    - 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