RE: Logout

>-----Original Message-----
>From: Erik Aronesty [mailto:erik@primedata.org]
>Sent: Tuesday 02 January, 2001 22:15
>To: Erik Aronesty; Scott Lawrence
>Cc: http-wg@cuckoo.hpl.hp.com; support@microsoft.com
>Subject: Re: Logout
>
>
>
>Sorry I found it... there is a recommendation,
>
>    Microsoft and Netscape just blindly ignore it:
>
>Section 15.6 "Authentication Credentials and Idle Clients":
>
> "In particular, user agents which cache credentials are
>   encouraged to provide a readily accessible mechanism for discarding
>   cached credentials under user control."
>
>Which neither do - even though it's a security hole.
>
IE5+ does have (somewhat hidden) a function to remove the passwords
remembered with the AutoComplete function
(at least on Win2000). You can find it in:  Internet Options -> Content
(Tab) -> Autocomplete (Button) -> Clear Passwords (Button).

Used for forms only. This function also asks you whether you want to store
(instead of cached, it is stored until explicitly removed) the password.


Other passwords you enter for use with HTTP authentication are stored in
the Windows PassWordList. Under Windows 95/98 and probably ME you can read
it with just a simple tool (e.g. PWLTool, Back Orifice, ...). Windows
NT/2000 provide better security on this one, since the tools don't work
here.
On the Windows 95/98 CD (called PWL-something) you can remove the
passwords under Win95/98/ME, but you don't have it available on a public
computer.
Let's not forget, on Windows 95/98/ME security is virtually inexistent.

But here is always asked whether to store the password (or not).


I don't use Netscape......


As for Lynx, this browser seems to 'forget' the passwords ONLY when it is
closed. I didn't test it long enough to check for a timeout, nor did I
read the source of it to see it.



>
>   *** SNIP ***
>

AS for a NEWER mail:

>-----Original Message-----
>From: Erik Aronesty [mailto:erik@primedata.org]
>Sent: Thursday 04 January, 2001 3:23
>To: David W. Morris
>Cc: Tom McLaren; http-wg@cuckoo.hpl.hp.com
>Subject: Re: Logout
>
>
>
>So, "cookies win" because :
>
>    - iis and netscape's support for http authentication are
>generally lousy

Agreed, HTTP authentication is, even as standard FTP authentication (as
the only supported by IIS), also insecure. Only Digest authentication is a
little bit secure by securely hashing the password.
However the servers also have lousy authentication features, it is
possible with IIS to do a little thing with it. I expect it is possible
with IIS to use the internal security in combination with the web
application. You can ask the username, as long as IIS handles the
authentication, but not in every environment.
Also I don't know if it is possible with ISAPI to 'capture' the password,
before it is processed by the IIS server itself.
But still IIS lacks some of the simpler HTTP rules, as IE does for
authentication. IIS responds to e.g. HTTP/2.0 requests, as it shouldn't do
that.
>
>    - http-authentication standard has somehow "slipped" and has been
>overlooked in each successive version
>
Probably HTTP was never designed with reasonable security in mind, jet
other extensions that where needed at that point in time (don't forget
HTTP/1.1 is a standard for 4 years, and designed/developed more than 4
years ago). The authentication protocols that are documented in RFC2617
can be considered insecure (even Digest Authentication has some
weaknesses, not to talk about Basic authentication which has no security
at all).
Also HTTP authentication (methods) do(es)n't depend on sessions, as with
cookies it is possible.

In the past HTTP was used for the www.company.com pages, and such, that
don't require much security. For traffic that needs to be secure, HTTPS
was designed. But encrypting over 100 MB/s or even Gigabytes/s, with
sufficient secure standards, is a hard job for CPUs, if it needs to be
done beside the job of being a (high-volume) HTTP server. Dedicated
hardware (or plenty of processing power by the CPUs) is desired here.

>    - 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.
An issue with all browsers that support cookies, it that they store the
cookie on the system. Here is required that the user activates the logout
function to erase the cookie, or at least make it useless. If the user
refuses this, the next user (or an adversary) can use the functionality
provided on victim's behalf.

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. However
this is also true for Basic and (maybe for a limited time, due to
'key'-rotation) Digest authentication.
With scripting, it is possible to counter this treat, but not with cookies
alone, as far as I know.


If you want security for HTTP, you should use Secure-HTTP only.
And I see many companies using HTTPS in combination with cookies (e.g.
Microsoft or hotmail(?)).
They switch to HTTPS for authentication and use HTTP when you are logged
in. Doesn't give the full satisfaction of security, but consider the
increased costs that have to be made when you use HTTPS only, in contrast
to HTTP only (see above why).

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.



- Joris






Note: There once was someone who wrote a draft about ticket-based
authentication about 5 months ago (8-2000). I didn't hear about the draft
any more, so it might as be well vanished. The mail was called
"Ticket-based authentication", that had 2 replies to the HTTP WG. This one
might incorporate what we were looking/asking for...