Re: Problems with most web app auth schemes

[Ingo Struck <ingo () ingostruck de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Kevin,

> that deserves recognition: the login and session id paradigm that most web
> applications use for authentication is not correct.  If you think from the
> ground up about how authentication should be performed, you do not arrive
> at what is being used today.
Of course you are right.
The main problem with "long-term" authentication over HTTP is the try
to make a stateless protocol stateful. If properly used, the auth mechanisms
for HTTP could at most be useful on a "per-URL / per-Request" basis.
Within RFC 2069 (Digest Authentication) it is already stated that this auth
scheme is not secure from a cryptographic point of view.
If you think further in the direction you indicated, the final question would 
then be:

        "Is HTTP *at all* suited for securely authenticated transmission?"

(For a longer consideration cf. RFC 3205, http://www.ietf.org/rfc/rfc3205.txt)

It is not hard to render the answer to a clear "no".
Alas, it is *very* hard to establish a protocol that supersedes HTTP due to 
it's pervasiveness.

As outlined in the document mentioned above, SSL with both client and server
side authentication is not viable, since it would require each client to 
obtain a valid and signed certificate, which is a complicated and costly 
process. 

One viable way that is rather easy to implement is tunnelling, e.g. using SSH.
Using this approach you can establish a rather well-secured *stateful* 
connection with both client and server side auth and a keypair mechanism if 
you like to. The valid public key for such a tunnel could be uploaded upon
user registration, similar to the process used by sourceforge.net for the CVS
over SSH access.

However there are some drawbacks:
- - tunnelling is not implemented as a default option in today's browsers
- - an average user is not skilled enough to build up a working ssh tunnel by 
hand
- - the connection is slowed down
- - there is nearly no web-server / site with an alternative ssh-tunneled access

Maybe somebody should write a "local proxy" that could be used to establish
a tunneled connection to servers which provide such an alternative access.
The user could then tell his browser to use that proxy for connections to 
servers who support tunnelling. The local proxy would then handle the 
tunneling on the client side (I guess I will try that out with a web 
application of mine).

> It's dissapointing to see that this knowledge is not being applied in
> fields such as web security that could benefit from it.
That is really disappointing and there are obviously not so many people
who try to to ameliorate the situation.

Kind regards

Ingo


YASP (yet another shameless plug):
The Open Web Application Security Project has been working for quite a
while on a "Guide to Building Secure Web Applications and Web Services",
available under http://owasp.org/guide/
Volunteers and writers for this projects, as well as suggestions for 
improvement are always highly welcome.

- -- 
ingo () ingostruck de
Use PGP: http://ingostruck.de/ingostruck.gpg with fingerprint
C700 9951 E759 1594 0807  5BBF 8508 AF92 19AA 3D24
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE/Iud4hQivkhmqPSQRAjRvAKCkIU9Q+ySrN18gP4yIV4lYmhxFsgCgj5Py
T8qjUXdIqDrN49RYyAPZ7pE=
=QW/m
-----END PGP SIGNATURE-----