Brian Mearns wrote:
On Tue, Jan 27, 2009 at 2:35 PM, Nick Kew <n...@webthing.com> wrote:
On Tue, 27 Jan 2009 14:16:55 -0500
Brian Mearns <mearn...@gmail.com> wrote:
I'm not concerned right now with security of content, I'm concerned
with someone highjacking another person's session.
Then Digest Authentication is exactly what you want.
Like I said, it's not clear to me how this would solve my problem. Can
you elaborate a little?
Maybe first read this :
http://en.wikipedia.org/wiki/Http_digest_authentication
The point is :
Presumably, you do not send a session token to the client, before the
client has gone through some authentication procedure (login).
If you use this HTTP Digest authentication, then that particular client
a) will be the only one who knows the "authentication string" to send
later to the server to confirm he is the one that previously
authenticated. This is sent as a HTTP header with each request, so it is
not immediately visible to a would-be miscreant. It is also encrypted,
so it is not really obvious what is in it.
b) the client will automatically repeat this authentication header when
talking to the same server, as long as the URL it is talking to appears
sufficiently similar, and as long as the browser is kept open, and as
long as the server does not force it to re-authenticate.
So in fact, it could also serve as a replacement for your "token",
without need to be included in the URl or in the posted forms or in a
cookie.
Now, it is up to you if in addition, you still want to send an
application token in some other form.
But when you get the token, you should anyway first check if the client
is authenticated, and only then accept the token.
If someone happened to get hold of your token, and tried to send it to
the server to impersonate another client, your application would know
that it is a fake, because there is no practical way the fake client
could also fake the HTTP Digest header and send it at the same time.
The only real weak spot is the "man in the middle".
If another server could convince the client that it is your site, it
could ask the client to authenticate in clear (using Basic
authentication), then grab the user-id/password of the client, and
itself make the call to your real server. Your server would request a
Digest authentication to him, thinking he is the real client. Having
saved the original client's id/password, he would then enter a proper
Digest negotiation with your server, and authenticate. Once it has done
that, it receives the server Digest token and your app's token, and can
continue to talk to your server on behalf of the original client.
Becoming a man-in-the-middle in that way takes some effort, and the
probability of someone making this effort is proportional to the gain to
be made by succeeding at it, and inversely proportional to the penalty
incurred for trying and being found out.
Whether that is an acceptable risk is your decision.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
" from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
