Cookie Monster

James A. Donald jamesd at echeque.com
Fri Sep 19 04:50:48 EDT 2008


EMC IMAP wrote:
 > Yet another web attack:
 >
 > <http://www.theregister.co.uk/2008/09/11/cookiemonstor_rampage/>

 > My own conclusion from this:  This is yet another indication that
 > the whole browser authentication model is irretrievably broken. It's
 > just way too complex, with way too many moving parts which can
 > interact in dangerous ways.  The list of requirements for a "safe"
 > Web application - even just based on attacks known today - is so
 > long that no one can remember them all, much less check any
 > substantial Web application to see if it follows them.
 >
 > We need a better approach.

As I posted earlier:

SSL/TLS does not supply secure logon and sessions, because it does not
know what a session or a login is.   Instead http+tls provides a pile
of matchsticks and glue with which the website server can implement
something that kind of sort of mostly behaves rather like logins and
sessions.

It should have been obvious that everything really important relates
to logins and sessions and that the rest can be treated as a login by
"anon 37283" with the null password, and that therefore the
cryptography *and* *the* *browser* *user* *interface* needs to
implement logins and sessions.

It should have been obvious that logging in on the web page was going
to lead to the phishing disaster - that people should login on a
trusted path from the browser chrome.

The user login status should be displayed in the chrome on every
logged in web page, and the server has to know that the user knows his
login status, has to know the login status not only of the user, but
of the web page that the user has clicked on that generated this
request to this server.

The state of being logged in should guarantee privacy and authenticity
- that only the client and the server can know what they are
communicating, and that no one else should be able to pass himself off
as client or server, or modify their communications

Everything should have been written around the user concepts of
"logging in"  "a logged in page", and "logging out", and should have
made those user concepts real, made them into pages with appropriate
built in cryptographic behaviors, rather than providing capabilities
that could potentially be used to make pages behave like that.

The user concept of "logged in" has to be real rather than
superficially simulated by server side code

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list