Re: Problems with most web app auth schemes

> However, even with all of these deterents, it's still not really

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.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

[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(at)luxsci.com  ---  
http://luxsci.com