Subject: Re: Logout

From: "Erik Aronesty" <[email-masked]>
Date: Tue, 2 Jan 2001 16:15:03 -0500

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.

                - Erik

----- Original Message -----
From: "Erik Aronesty" <[email-masked]>
To: "Scott Lawrence" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, January 02, 2001 4:12 PM
Subject: Re: Logout

> > > the passwords that are used to access HTTP servers?  IE: a "logout"
> button
> > > for HTTP built-in authentication.
> > >
> > > I imagine that this is the sort of requirement that HTTP people think
> that
> > > this should be in the HTML group - and vice-versa.
> > >
> > > However it is an embarrassing oversight in modern browsers.
> >
> > One that some of us have tried hard to overcome, to no avail.  The
> > basic problem is that the browser vendors have listened carefully to
> > what thier customers want, and have heard loud and clear that they
> > don't want to have to remember passwords.
>
> Over 600 users have asked us within the last year how to "log out" of
sites
> such as etrade and daytek which use HTTP based authentication.
>
> Browser customers don't want to remember passwords - however they want
> a "logout button" as well.  This is not a paradox and there is no
> inextricable reason why
> browsers can't cache usr information but have a button for "clearing the
> cache"
>
> I think the real reason that this has not been done is because both major
> browsers today have other agendas regarding network access and security.
>
> Currently there is no way to clear the cache by having an HTTP server
> request
> it to be cleared - or by a user initiating the clearing of this
information.
> This
> is a basic security leak - and should be plugged.
>
> > Paul Leach of Microsoft and I attempted to provide a framework for a
> > solution to this and some related problems in a submission to the
> > W3C (User Agent Authentication Forms) in February of 1999:
> >
> >     http://www.w3.org/TR/1999/NOTE-authentform-19990203
>
>
> However, this is a "forms based" solution which undermines digest
> authentication
> and other more "standard" forms of authentication - that have proved very
> helpful
> to developers of web applications.
>
> Simply, there should be one line added to section 4.13
>
>     ftp://ftp.isi.edu/in-notes/rfc2617.txt
>
> "It is reccomended that the authenticating agent provide a set mechanisms
> for
> removing entries from the "password file" associated with a given realm,
for
> the purposes of logging out of a system."
>
> And that's about all that's necessary.
>
> I don't think it needs a whole RFC ... just an addendum to existing ones.
>
>             - Erik
>

---

From: "Tom McLaren" <[email-masked]>
Date: Wed, 3 Jan 2001 09:47:57 -0000

I agree that a "logout" type button should certainly be implemented. I'm
interested in your choice of words however, naming the non-provision of an
HTTP server cache clearance request as a security hole. In my opinion it is
the responsibility of the site to provide some form of timeout security. To
provide an HTTP type clearance of the cache is exposing the agent to what
amounts to control by a third party. Surely this would constitute a greater
threat to security and not be a road to wander down without serious
consideration of the potential future implications?

Tom

> -----Original Message-----
> From: Erik Aronesty [mailto:[email-masked]]
> Sent: 02 January 2001 21:15
> To: Erik Aronesty; Scott Lawrence
> Cc: [email-masked]; [email-masked]
> Subject: Re: Logout
>
>
>

---

From: "Erik Aronesty" <[email-masked]>
Date: Wed, 3 Jan 2001 11:47:32 -0500

Dear Tom,

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.

                - Erik

---

From: "David W. Morris" <[email-masked]>
Date: Wed, 3 Jan 2001 13:08:58 -0500 (EST)

> consideration of the potential future implications?

Any control provided to the server should of course be scoped to the data
'owned' by that server, hence no security exposure. Likewise, it should be
possible for a user to expunge ALL data cached from their session, login
credentials, cookies, pages etc. It should be possible for the 'owner' of
the user agent installation to configure the UA to peform this function
automatically when closed, etc.  Again not a security issue if the action
is performed by or directly on behalf of the human user.

And of course, any well designed web application will implement a timeout
stragegy because they can't trust the other end.  Unfortunately short
timeouts which improve security have the strong potential for very
frustrated users who happen to be interrupted by a phone call or other
task while in the middle of an interaction.

Dave Morris

---

From: "David W. Morris" <[email-masked]>
Date: Wed, 3 Jan 2001 13:19:02 -0500 (EST)

> In a way, "cookies" are "more secure" than the security mechanisms built

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

---

From: "Erik Aronesty" <[email-masked]>
Date: Wed, 3 Jan 2001 21:23:15 -0500

So, "cookies win" because :

    - iis and netscape's support for http authentication are generally lousy

    - http-authentication standard has somehow "slipped" and has been
overlooked in each successive version

    - 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

                                            - Erik

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Sat, 6 Jan 2001 23:00:11 +0100

>Sent: Tuesday 02 January, 2001 22:15
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:

>Sent: Thursday 04 January, 2001 3:23
>To: David W. Morris
>Cc: Tom McLaren; [email-masked]
>Subject: Re: Logout
>
>
>

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

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

---

From: Peter W <[email-masked]>
Date: Sat, 6 Jan 2001 17:32:50 -0500 (EST)

> 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

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

> currently provides. The current standard doesn't satisfy the requirements

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

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Mon, 8 Jan 2001 15:49:48 +0100

>From: Peter W [mailto:[email-masked]]
>Sent: Saturday, 6 January 2001 23:33
>To: Joris Dobbelsteen
>Cc: WWW WG (E-mail)
>Subject: RE: Logout
>
>
Basic is completely insecure. Digest has some security hazards:
Server sends a 'key' to use with hashing. When the same 'key' is used,
the hashed password captured can be reused.
Also doesn't digest authentication (nor basic authentication) provide
data integrity.

>    another document, that user is warned about the taint, required to
You get one 'public' ticket for use over HTTP, and one 'secret' that is
used only over the HTTPS for validation of the originator of the
request. That is what I understand....
HTTPS can be used to rotate 'public' ticket (not really public, but
anyone can read it anyway once transmitted over HTTP).

Seems securely enough to me for general purposes, however there are
still some real vulnerabilities...
The 'public' ticket CAN be used, in some occasions, for a (limited)
time.

Next there is no garantee of data integrity. This part I'm missing. I
can hijack a connection and alter it's (unsecured) data, thus sending
damaging messages on your behalf (or someone else).

As for webmail, when this security is implemented on this pad, later on
I can still alter the data, when send over the SMTP 'network'. So in
this case, it's not a real requirement, but when data is send using
SMTP, probably too many messages are send for the adversery to care
about them all.

I would prefer a scenario of an employee downloading and uploading data
from his company, that doesn't require data confidence (there's no data
confidence when using HTTP).

>> this)), the adversary can use that cookie on the victim's behalf.

Think I got it. But still vulnerable, see above...
>at least it can't be significantly improved upon.

The obvious thing that is still bad is:
* lack of data integrity validation
* possibility to use a 'ticket' for a (limited) time

The all-in-one solution for this problem is this (maybe can be proposed
as a security extension to HTTP):
[Have a good time reading - 20 kB mail message]

===
Hope I didn't make too much typo errors. and the goal/purpose is
clear...
If you find the word "of" and you think it should not appear here, try
whether "or" fits better. The Dutch "of" is the English "or". I tend to
mix these up sometimes (why I don't know).
===

It relies fully on public-key encryption and looks simuliar to S/MIME.
Note that also proxies should be aware of the use of this feature. Maybe
they can be told using cache-control directive not to manipulate the
message?
I suppose "Cache-control: no-transform" can do the job, but fearing many
proxies will not obey to the directive.

In the case that data confidence is required, using HTTPS is required.

*** REQUIREMENTS
SERVER
* Valid certificate to ensure data integrity and orgin authentication.
* Optional: Hardware hashing and hash signing support, to improve
performance dramatically.
CLIENT
/ None
PROXY/GATEWAY
/ None

*** PART ONE: LOGON
The client should generate a key-pair: private key with according public
key. Next the client should be aware of the user's authentication
credentials (user/pass), and should not save these (without explicitly
asking the user). A HTTP connection can be used to ask the sever for a
SessionID, and at the same time send the user's authentication
credentials and the public key. The client can purpose a lifetime of the
session and for the key. Also the algorithms used must be agreed on by
the client and server. In case of unsecured transmission (HTTP, not for
HTTPS), the HTTP message should be signed.
In case of the correct credentials are used, and the server agrees on
the methods/protocols used, the server sends his certificate (with
public key) and a session ID.

In reality this can be done over HTTPS, using Digest authentication by
preference.
The client connects to a HTTP server using HTTPS. Next it sends it's
authentication credentials, with the password hashed (standard digest
authentication), but also includes the public key. No need to sign the
message (already secure channel).
Assuming the correct ID and server accepts methods used...
The server responds with a a SessionID, and a certificate. Also the
server specifies where the SessionID should/can be used and gives
servernames with the according certificates, or a group that uses the
same certificate. Also expiration of the sessionID and maybe the key is
included (when using 1024-bit or larger keys, this is not required).
Messsage doesn't need be signed, because the connection is secure.

If the user has a certificate already, this can be used, instead of the
custom-generated key-pair. The entire certificate should be send in this
case, instead of only the public key.
With the appropiate methods, HTTPS will not be needed. This sample used
the old authentication methods in combination with the new features
provided by this security extension.

It is possible to use certificate authentication together with the
user/password authentication, but allowing a higher level of access when
using certificate authentication.

The server must send the certificate to identify itself, as it has no
user/password authentication possibility, but the certificate alone will
be enough for the job.

Note that the rule (for certificates) is that the private key NEVER
leaves the local computer, but only the public key. When I say, send the
certificate, only the certificate with the public key and withOUT the
private key. This applies through all this specification. No confusion
on this...

*** PART TWO: HTTP MESSAGE SIGNING

On unsecure channels, we sign the HTTP message.
We need to sign data that is affected, this includes the Request/Reponse
line and non-modifiable headers. The headers that can be signed are
outlined in section 13.5.2 (Non-modifiable Headers). Also the header
including the sessionID should be signed.

We need a hash of the request/response line, headers and, of course, the
content (data). Next the hash should be signed with the private key. The
public key cannot be used for signing, because the adversery also knows
the public key.

This means the remote side can check the data intigrity. The SessionID
will be used to check the user credentials.

*** PART THREE: LOGOFF
Logoff occurs quire simply by expiration of the SessionID or sending an
instruction to the server to logoff. The server can also instruct the
client to logoff.
Logoff includes the expiration of the SessionID and erasing the key-pair
on the client. Most important is the expiration of the SessionID to
succeed on the server-side.
This means LOGOFF IS REQUIRED using either expiration or user-actived
logoff!!!

*** PART FOUR: EXTENDING SESSION LIFETIME
Resons for ending a session without intension of the user is expiration
of the SessionID. Before extending the session, the user should be aware
of it, by asking him/her/it first. Closing the browser should retire the
SessionID and key-pairs and preferably, the server should send a message
to retire the session.

A signed message with this request can be issued to the (original)
authentication server in order to extend the session for a specific time
(maximum limit by the server). The server may refuse. Adding user
credentials again is not needed but may be requested by the server. Also
key rotation or sessionID rotation may be requested/done by the server.

*** PART FIVE: WEAKNESSES/DISADVANTAGES OF THE PROTOCOL
The protocol requires on the strength of the security protocols used.
Known-plaintext attacks are possible, and security protocols used should
be designed to be properly (heavily) protected against this type of
attack. Such attacks can result fast into many known-plaintexts with
there accompanying ciphertext.

Servers require significanly more performance to do the job.

Key- and session-management is required and probably will get more
complex.

Requires browser and server support.

Expire-times should be relatively short (couple minutes), to improve
security. Long expire-times give the adversery a good chance to do
damage. This is because delivery is still not ensured, and thus
retirement of sessions by the user is not garanteed to happen (you can
easily filter such messages out).

*** PART SIX: FEATURES OF THE PROTOCOL
Provides orgin authentication

Provides data integrity

Extended security over existing methods, by eliminating some severe
weaknesses that exist in the cookies-implementation.

Long sessionkeys (256-bits would probably allow you to have almost
certainly unique IDs)

A (e.g. authentication) server can have a different certificate that the
other servers.

*** PART SEVEN: WORK TO DO
- How on chunked transfers
- How to sign headers and the request/response line.
  These probably change due to proxies, gateways, firewalls and such
things.
- .....

That was the mail for today...
Hope you like it.

If you have some other suggestions, send them...
maybe some protocol errors, but it probably needs to be reviewed, when
we want to implement such functionality.
Maybe I forget thinks where, I did or didn't think about...

- Joris

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Mon, 8 Jan 2001 18:57:43 +0100

A stupid mistake made in the previous mail...

Hashing and signing the hash is always required, because it is an
intergral part of the orgin authentication (and data integrity)
validation. Corrected in this mail (I really hope)...

==============================

===

*** REQUIREMENTS
SERVER

*** PART ONE: LOGON
The client should generate a key-pair: private key with according public
key. Next the client should be aware of the user's authentication
credentials (user/pass), and should not save these (without explicitly
asking the user). A HTTP connection can be used to ask the sever for a
SessionID, and at the same time send the user's authentication
credentials and the public key. The client can purpose a lifetime of the
session and for the key. Also the algorithms used must be agreed on by
the client and server. Next the message must be signed, as it provides a
integral part of the orgin authentication and data integrity check.
On a secure channel, in a logon message ONLY, it's not a direct
requirement that the message is signed

In reality this can be done over HTTPS, using Digest authentication by
preference.
The client connects to a HTTPS server. Next it sends it's authentication
credentials, with the password hashed (standard digest authentication),
but also includes the public key. No need to sign the message (already
secure channel, note that this is for a logon message only).
Assuming the correct ID and server accepts methods used...
The server responds with a a SessionID, and a certificate. Also the
server specifies where the SessionID should/can be used and gives
servernames with the according certificates, or a group that uses the
same certificate. Also expiration of the sessionID and maybe the key is
included (when using 1024-bit or larger keys, this is not required).
Messsage doesn't need be signed, because the connection is secure.

On unsecure and SECURE channels, we sign the HTTP(S) message.
We need to sign data that can be affected by an adversery in a way that
it will provide a security hole, this includes the Request/Reponse line
and non-modifiable headers. The headers that can be signed are outlined
in section 13.5.2 (Non-modifiable Headers). Also the header including
the sessionID should be signed.

Note that signing is an important operation, as it provides orgin
authentication and data integrity.

*** PART THREE: LOGOFF
Logoff messages must be signed.

Provides data integrity

*** PART EIGTH: HACKING ATTEMPTS
If a false message was detected that was incorrectly signed, the server
should notify the actual owner of the session of this attempt. It's
recommended to retire the session. On the other hand, the session can
probably continue to exist, because this security is more difficult to
break, than with the cookies.

- Joris