Re: Straw-man charter for http-bis

Henrik Nordstrom wrote:
> Web authors considering look & feel much more important than security,
> and not willing to ask for the ability to have both as forms + cookies
> accomplishes their goal of getting the look & feel they want?

A few notes on what I think forms + cookies offers that RFC2617 doesn't.

    1. The login cookie (or its validity) can be expired under control
       of the server.  That is, the site can offer a "logout now"
       button, options for "logout at end of session" and "keep me
       logged in between sessions" - and also control the idle expiry
       time.

       This has become more important with the spread of public
       terminals, vs. the convenience of remaining logged in on
       private terminals.

       I've noticed my bank site will expire login credentials after
       just 10 minutes, while other sites which are not so security
       conscious take much longer.  It is difficult for my browser to
       remember my security credentials - the site uses changing form
       field names - so I have to reenter them.  They both seem like
       a good idea to me.

    2. Related to above, different types of access can be maintained
       simultaneously for the same pages.  For example, the server may
       remember who you are between sessions for personalisation - but
       for critical operations require re-authentication between. I
       think Ebay does this - you can remain logged in between
       sessions for convenient browsing, but placing a bid requires a
       password confirmation each session.

    3. Password transfer for authentication can be done over SSL/TLS,
       even if the accessed pages after that are plaintext with the
       cookie as authenticator, for performance or caching reasons.  I
       think in some ways this is stronger than digest authentication,
       and in some ways it is weaker.

    4. Related to 3, a clever site could run client-side ECMAscript to
       apply a crypto operation to the authentication cookie on every
       page fetch, so the shared secret is not revealed on the wire
       and is immune to replay attacks, combining the advantages of
       both methods.  (I'm not aware of any site doing this, but it
       seems plausible, for browser-accessed sites only of course).

    5. Forms + cookies can be implemented by any server-side page
       rendering scheme, e.g. PHP, Perl, CGI, etc. which handles forms
       + cookies for other purposes.  In other words, it's accessible
       to actual site authors, who often can't reconfigure their web
       server but can write those scripts.  Yes, this is an
       implementation detail, but there's practical reasons why it's
       such as _very_ common implementation detail.

> Digest being different than the other authentication mechanisms, and
> therefore a bit of a pain to integrate into existing systems, requiring
> a different password store or alternatively access to plaintext?  (a
> problem shared with all secure authentication methods)

Forms + cookies authentication seems to integrate quite conveniently
into pretty much all existing systems for serving the rest of the page.
Naturally.

If there's a serious wish to define a HTTP authentication scheme which
is better enough that everyone wants to adopt it, I think it's
worth looking into how to improve "forms + cookies" with schemes that
offer all the capabilities of that, but are properly scrutinised as
security schemes.

A synthesis of the best of RFC2617-style, and forms + cookies for
security ought to:

    1. Be better in every respect - security and user interface, than
       forms + cookies _and_ RFC2617 at the same time.  Solicit buy-in
       from big users of forms + cookies at present, in order to
       properly understand and address the reasons they have for using that.

    2. Resemble RFC2617 type schemes in the sense of being accessible
       to non-browser clients, and non-HTML uses.  This surely means
       combining some of the _behaviour_ of cookie schemes, with
       transmission of authentication information over HTTP headers.

    3. Retaining the server control of behaviour that forms + cookies
       offers.  Ability to force "logout now" - not merely request, by
       declaring an authentication token no longer valid.  Ability to
       retain different levels of authentication simultaneously for
       different aspects of a site.  Ability to request that a client
       forgets the user's password.  Time-based expiration.

    4. Describing hooks whereby the UI elements can appear embedded in
       a related HTML page, but aren't required to be.

    5. Ensure that it's possible that site authors who write in
       e.g. PHP, Perl, CGI etc. can easily make use of the scheme.
       Simply because this is an important requirement for practical
       deployment.

-- Jamie

Received on Monday, 11 June 2007 09:39:17 UTC