WebApp Sec mailing list archives
Re: Problems with most web app auth schemes
From: "Erik Kangas, PhD" <kangas () luxsci com>
Date: Sat, 26 Jul 2003 10:44:01 -0400 (EDT)
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
Current thread:
- Problems with most web app auth schemes Kevin Spett (Jul 26)
- Re: Problems with most web app auth schemes Erik Kangas, PhD (Jul 26)
- Re: Problems with most web app auth schemes Brant Langer Gurganus (Jul 27)
- Re: Problems with most web app auth schemes Tim (Jul 27)
- Re: Problems with most web app auth schemes George W. Capehart (Jul 27)
- Re: Problems with most web app auth schemes Tim (Jul 27)
- Re: Problems with most web app auth schemes George W. Capehart (Jul 28)
- Re: Problems with most web app auth schemes Tim (Jul 27)
- Re: Problems with most web app auth schemes Ingo Struck (Jul 27)
- <Possible follow-ups>
- RE: Problems with most web app auth schemes Cowles, Robert D. (Jul 27)
- Re: Problems with most web app auth schemes Ingo Struck (Jul 27)
- Re: Problems with most web app auth schemes webappsec (Jul 28)