Re: Problems with most web app auth schemes

["Erik Kangas, PhD" <kangas () luxsci com>]

> However, even with all of these deterents, it's still not really
> theoretically secure.  Exchanging session id, even one that changes every
> request or when the server will verify the IP address of the client, has a
> flaw: you are openly exchanging a secret.  This is not how well-designed
> authentication systems work.  It is the equivalent of sending the actual
> password across a network for a domain login.  Even with encryption layer,
> you're not supposed to do this.  You use a hash.  The reason for this is so
> that you can prove that you know the password, but don't actually have to
> divulge it.

What you have said is all completely correct, however, I think the assumptions 
and steps in standard web security should really be pointed out -- not for 
rebuttal, as there is none, but for some justification of the current schema.

* Most web sites interested in real security use SSL for their "login 
sessions".  Let us restrict ourselves to this case.

* When the client connects to a web site two things have to happen for 
security:
  1. The web site must prove that it is the correct web site
  2. The user must authenticate him/herself

  The web site proves that it is correct via its SSL certificate issued 
to the domain in question by some "trusted" third party.  Depending on
how much the user trusts the certificate issuer, s/he can have confidence
that the web site is what it claims to be. 

  Now, the user and the web site have a secure data connection established
via the public key mechanism of SSL so that ALL data that is transmitted 
between them is encrypted.

  The user then enters a username/password into a form and this data is 
transmitted in an encrypted fashion to the web site for authentication.

  If the client is authenticated, a session cookie is generated with
timeout and validation information and this is sent back to the user
as a "secure cookie" - i.e. one that is only passed back and forth
over SSL.

So, you are passing a shared secret back and forth, but it is encrypted and is 
not the actual password and does timeout. You have to pass one shared secret 
(username/password) for each session anyway, so the additional hashed session 
codes do not diminish the security greatly over that fact that you password is 
sent over SSL.

You can also use a cookieless scheme where the session codes are embedded in 
the site URLs so tha they are never stored in the hard disk of the client 
computer.  This alternative has its own pros and cons.

[Of course, if you web site does not use SSL or good cookie timeout and 
validation techniques, then the security of your authentication is really 
quite poor.]

This is how things are done now, in general, and it is really pretty good.
Some web sites do require their users to obtain client SSL certificates 
so that the web site can authenticate the clients via these certificates
and thus not need this whole username/password scheme (except, possibly,
in obtaining the client certificates...).  While this scheme does 
afford much better security, it is on the down-side of the 
security-usability tradeoff for most sites.  It is really only
feasible where you can force your clients to get the certificates (i.e.
in a University or Intranet setting -- MIT does this, for example),
but not where site use is completely optional -- i.e. eCommernce.



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Erik Kangas, Ph.D. --- President of Lux Scientiae, Incorporated

Lux Scientiae:       1-800-441-6612        46 Central Street
FAX:                 1-413-332-0598        Somerville, Massachusetts
Cell:                1-617-596-9558        02143, United States of America
AOL Messenger:       "luxsci"

kangas () luxsci com  ---  http://luxsci.com