Session theft?

Johnny Elvers wrote:
>
>>>>
>>>> A session thief could retrieve the UID when it travels down to the
>>>> cliend, and use it right before the legitimate client uses it.
>>>>
>>>
>>> Right, but the same applies to the client side algorithms.
>>> For measurements against generic theft your point is taken though.
>>
>>
>>
>> I was assuming that the thief can see the data, but not touch it. In
>> this case, even if the thief gets the new_sid that travels from the
>> client to the server, it will be worthless, because that new_sid has
>> already arrived to the server and is no longer valid.
>>
>
> But the thief can do the same calculations as the client.

He needs the password to get the nex_sid from the current_sid. Only the
legitimate client knows that password.

>
> But you are right of cause, as this is about session theft and not
> hacking attempts :)
>
> /Johnny

Dani CS wrote:
>
> He needs the password to get the nex_sid from the current_sid. Only the
> legitimate client knows that password.
>

Yes, but the point is that whatever resides inside the client, in a non
ssl (or the like) encrypted setup, is public. So password, algorithm and
whatever is transmitted is copyable.
So whatever is sent, the actual password or an md5'ed password or
whatever doesn't really matter. All the thief has to do is intercept and
replicate the client functionality.

/Johnny

Johnny Elvers wrote:
> Dani CS wrote:
>
>>
>> He needs the password to get the nex_sid from the current_sid. Only
>> the legitimate client knows that password.
>>
>
> Yes, but the point is that whatever resides inside the client, in a non
> ssl (or the like) encrypted setup, is public. So password, algorithm and
> whatever is transmitted is copyable.
> So whatever is sent, the actual password or an md5'ed password or
> whatever doesn't really matter. All the thief has to do is intercept and
> replicate the client functionality.

The password is never sent over the net. It is typed down by the user on
the client, and then stored in a javascript variable. The thief can't
see it.

>
> /Johnny

Dani CS wrote:

> Johnny Elvers wrote:
>> Dani CS wrote:
>>
>>>
>>> He needs the password to get the nex_sid from the current_sid. Only
>>> the legitimate client knows that password.
>>>
>>
>> Yes, but the point is that whatever resides inside the client, in a
>> non ssl (or the like) encrypted setup, is public. So password,
>> algorithm and whatever is transmitted is copyable.
>> So whatever is sent, the actual password or an md5'ed password or
>> whatever doesn't really matter. All the thief has to do is intercept
>> and replicate the client functionality.
>
> The password is never sent over the net. It is typed down by the user
> on the client, and then stored in a javascript variable. The thief
> can't see it.

But what if they can work out what the javascript variable is called?
Then it's just a matter of typing javascript:window.alert(foo) into the
address bar in Internet Explorer or Mozilla to get the value,
subsituting "foo" for the variable name in my example.

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/

>
> The password is never sent over the net. It is typed down by the user on
> the client, and then stored in a javascript variable. The thief can't
> see it.

Yes he can. It is not simply a matter of traffic.
Sniffing is sometimes complicated. Parsing client content is, for most
parts, not.

/Johnny

"Robert Tweed" <robertNOSPAM@killingmoon.com> wrote in message
news:32f88iF3kgu43U1@individual.net...
> Does anyone know a good resource discussing the issues involved in session
> theft? I've read a couple, but none that really address the problem apart
> from acknowledging that it is a problem; you just don't seem to be able to
> do much about it.
>
> Does anyone have some tried-and-tested measures for preventing session
> theft, that aren't already built into PHP? For that matter, what measures
> _are_ already built into PHP? Are there significant differences between
PHP4
> and PHP5?

Easy. Don't rely on session for authentication (that is, in pages
subsequent to the login page). Authenticate with the HTTP digest method
instead. Session hijacking is basically a form of playback attack. A
properly implemented digest authentication is resistant to that.

Johnny Elvers wrote:
>
>>
>> The password is never sent over the net. It is typed down by the user
>> on the client, and then stored in a javascript variable. The thief
>> can't see it.
>
>
> Yes he can. It is not simply a matter of traffic.
> Sniffing is sometimes complicated. Parsing client content is, for most
> parts, not.

If the only thing the thief can do is look at the data on the wire, but
never change it, how could him grab something that is _never_ sent over
the wire?

If he can change the data on the wire, this and any other method of
authentication/session-management (lacking proper encryption) is already
defeated.

Apart from that, someone has already suggested a way to avoid cross-site
scripting vulnerabilities, by assigning a random ("impossible" to guess)
name to the window where all the data are.

>
> /Johnny

"Chung Leong" <chernyshevsky@hotmail.com> wrote in message
news:sIWdnekOd5sq8l7cRVn-ug@comcast.com...
>
> Easy. Don't rely on session for authentication (that is, in pages
> subsequent to the login page). Authenticate with the HTTP digest method
> instead. Session hijacking is basically a form of playback attack. A
> properly implemented digest authentication is resistant to that.

From what I've read about digest authentication it is no more secure than
plain HTTP authentication, except that an attacker won't actually get your
password in cleartext. They can still bypass your security using the hash.

OK, so you get rid of the problem of session theft, but you are just
shifting the issue: getting rid of one problem at the cost of another
problem.

Also, there appear to be some compatability problems with browsers and it is
not fully supported by Apache (although this last part may be out of date).

Am I correct about this, or have I got the facts wrong?

- Robert

Dani CS <contusiones.merluza@yahoo.es.quita-la-merluza> wrote:
> The trick is not to use one _fixed_ session id during the wholesession,
> but rather a _different_ session id for every client->server interaction
> (i.e. every time a new page is fetched from the server). In other words,
> multiple single-use session-ids for each session.
>
> A (single use) session id can be calculated from previos session ids and
> a secret shared between client and server (e.g. the password used for
> authentication of the user). This means that client and server must be
> in sync. Along with each request, the client must send the next session
> id that the server expects. This is why the 'back' button must not be
> used: the session id of the previous page would be sent to the server,
> but the server expects to get the session id for a new page. (I haven't
> worked at fixing this at the moment.)

I've never actually used UUCP, but one thing I've read about was the use
of "session counters".

The idea was for every dialup connection, a counter was advanced by 1 step
on both systems.

Next time the machine would connect, it would use this counter to authenticate,
if counters don't line up, neither could login again until someone corrected
the problem. (A nuisance if your visitor ever did use [Back] buttons)

Sounds a lot like what you're talking about.

Doesn't SSL have some kind of built in protection for this? I've never used it,
but it seems I'd heard about using SSL public key stuff for session management
in highly secure areas.

A challenge/answer is the only true way I can think of, browser sends public
key along with request. Server encrypts string using browsers public key and
sends it, next request, browser must answer previous question.

But it'd be really difficult to do w/out browser support.

Jamie
--
http://www.geniegate.com Custom web programming
guhzo_42@lnubb.pbz (rot13) User Management Solutions

>I've never actually used UUCP, but one thing I've read about was the use
>of "session counters".
>
>The idea was for every dialup connection, a counter was advanced by 1 step
>on both systems.

And one of the problems in practice of using it was that the counters
would get out of sync and require manual intervention to get the
connection working again.

There was supposed to be only a short timing window where one counter
but not the other was incremented, but it managed to hit that window
to drop modem carrier or whatever caused the out-of-sync problem
often enough that using session counters proved to be a real nuisance.

>Next time the machine would connect, it would use this counter to authenticate,
>if counters don't line up, neither could login again until someone corrected
>the problem.

Gordon L. Burditt