Hosting Provided By

Re: Problems with most web app auth schemes

From: Ingo Struck <ingo(at)ingostruck.de>
Date: Sat Jul 26 2003 - 16:41:22 EDT

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

Hi Kevin,

> that deserves recognition: the login and session id paradigm that most web
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.

Do you need help?

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
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----- Received on Sun Jul 27 08:20:02 2003

Do you need more help?

This message: [ Message body ]
Next message: Gabriel Lawrence: "RE: How to protect against cookie stealing?"
Previous message: Brant Langer Gurganus: "Re: Problems with most web app auth schemes"
In reply to Kevin Spett: "Problems with most web app auth schemes"

Contemporary messages sorted: [ By Date ] [ By Thread ] [ By Subject ] [ By Author ] [ By messages with attachments ]

This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:07:54 EDT