> 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
Received on Jul 26 2003
Intro
