fingerprinting and HTTP_USER_AGENT

I have read quite a few articles on "fingerprinting" a user when they
start a session. Chris Shiflett has a good article here:

http://shiflett.org/articles/the-truth-about-sessions

However, this part of his (and all the other similar articles) doesn't
make sense to me.

session_start();
$fingerprint = 'SECRETSTUFF' . $_SERVER['HTTP_USER_AGENT'];
$_SESSION['fingerprint'] = md5($fingerprint . session_id());

"With a fingerprint that is difficult to guess, little is gained without
leveraging this information in an additional way than demonstrated thus
far."

I don't really understand how this is more secure than just feeding
$_SERVER['HTTP_USER_AGENT'] into md5() without the secret seed, but I
must be missing something because everybody that talks about
fingerprinting seems to advocate adding a seed.

I am confused because as far as I can tell, every subsequent request the
user makes really only depends on $_SERVER['HTTP_USER_AGENT']. If an
attacker can successfully spoof this value, what does any of the
secretstuff matter? In order to check that we have a "valid" browser
after the initial saving in the session, we will have to re-supply the
seed and md5 representation after every submission of the user agent.

Given the above code, the only scenario I can envision in which we can
successfully match up this info would be something along the lines of:

$fingerprint = 'SECRETSTUFF' . $_SERVER['HTTP_USER_AGENT'];
if(md5($fingerprint) != $_SESSION['fingerprint'])
{
// prompt for password
}

called on each page, which to me doesn't really add any security since
we are providing what secretstuff is on every page.

Sorry for the length, and thanks in advance.

re: fingerprinting and HTTP_USER_AGENT

Marcus wrote:[color=blue]
> I have read quite a few articles on "fingerprinting" a user when they
> start a session. Chris Shiflett has a good article here:
>
> http://shiflett.org/articles/the-truth-about-sessions
>
> However, this part of his (and all the other similar articles) doesn't
> make sense to me.
>
> session_start();
> $fingerprint = 'SECRETSTUFF' . $_SERVER['HTTP_USER_AGENT'];
> $_SESSION['fingerprint'] = md5($fingerprint . session_id());
>
> "With a fingerprint that is difficult to guess, little is gained without
> leveraging this information in an additional way than demonstrated thus
> far."
>
> I don't really understand how this is more secure than just feeding
> $_SERVER['HTTP_USER_AGENT'] into md5() without the secret seed, but I
> must be missing something because everybody that talks about
> fingerprinting seems to advocate adding a seed.
>
> I am confused because as far as I can tell, every subsequent request the
> user makes really only depends on $_SERVER['HTTP_USER_AGENT']. If an
> attacker can successfully spoof this value, what does any of the
> secretstuff matter? In order to check that we have a "valid" browser
> after the initial saving in the session, we will have to re-supply the
> seed and md5 representation after every submission of the user agent.
>
> Given the above code, the only scenario I can envision in which we can
> successfully match up this info would be something along the lines of:
>
> $fingerprint = 'SECRETSTUFF' . $_SERVER['HTTP_USER_AGENT'];
> if(md5($fingerprint) != $_SESSION['fingerprint'])
> {
> // prompt for password
> }
>
> called on each page, which to me doesn't really add any security since
> we are providing what secretstuff is on every page.
>
> Sorry for the length, and thanks in advance.[/color]

Marcus,

Did you ask him about it? He should be able to justify his position.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

re: fingerprinting and HTTP_USER_AGENT

Marcus said the following on 14/11/2005 08:10:[color=blue]
> I have read quite a few articles on "fingerprinting" a user when they
> start a session. Chris Shiflett has a good article here:
>
> http://shiflett.org/articles/the-truth-about-sessions
>
> However, this part of his (and all the other similar articles) doesn't
> make sense to me.
>
> session_start();
> $fingerprint = 'SECRETSTUFF' . $_SERVER['HTTP_USER_AGENT'];
> $_SESSION['fingerprint'] = md5($fingerprint . session_id());
>
> "With a fingerprint that is difficult to guess, little is gained without
> leveraging this information in an additional way than demonstrated thus
> far."
>
> I don't really understand how this is more secure than just feeding
> $_SERVER['HTTP_USER_AGENT'] into md5() without the secret seed, but I
> must be missing something because everybody that talks about
> fingerprinting seems to advocate adding a seed.[/color]

I agree. Equally, I don't see what benefits using md5() gives at all.
Why not just store $_SERVER['HTTP_USER_AGENT'] in $_SESSION directly?



--
Oli

re: fingerprinting and HTTP_USER_AGENT

>However, this part of his (and all the other similar articles) doesn't[color=blue]
>make sense to me.
>
>session_start();
>$fingerprint = 'SECRETSTUFF' . $_SERVER['HTTP_USER_AGENT'];
>$_SESSION['fingerprint'] = md5($fingerprint . session_id());
>
>"With a fingerprint that is difficult to guess, little is gained without
>leveraging this information in an additional way than demonstrated thus
>far."
>
>I don't really understand how this is more secure than just feeding
>$_SERVER['HTTP_USER_AGENT'] into md5() without the secret seed, but I
>must be missing something because everybody that talks about
>fingerprinting seems to advocate adding a seed.[/color]

Consider other threats than the user. If someone manages to snoop
your session data (say, an employee of your hosting company), the
extra secret stuff makes the fingerprint a bit harder to interpret
and it's harder for that person to endanger your users.

I think that argument is a bit weak, but it's a real possibility.

Gordon L. Burditt

re: fingerprinting and HTTP_USER_AGENT

Gordon Burditt said the following on 14/11/2005 15:17:[color=blue][color=green]
>>However, this part of his (and all the other similar articles) doesn't
>>make sense to me.
>>
>>session_start();
>>$fingerprint = 'SECRETSTUFF' . $_SERVER['HTTP_USER_AGENT'];
>>$_SESSION['fingerprint'] = md5($fingerprint . session_id());
>>
>>"With a fingerprint that is difficult to guess, little is gained without
>>leveraging this information in an additional way than demonstrated thus
>>far."
>>
>>I don't really understand how this is more secure than just feeding
>>$_SERVER['HTTP_USER_AGENT'] into md5() without the secret seed, but I
>>must be missing something because everybody that talks about
>>fingerprinting seems to advocate adding a seed.[/color]
>
>
> Consider other threats than the user. If someone manages to snoop
> your session data (say, an employee of your hosting company), the
> extra secret stuff makes the fingerprint a bit harder to interpret
> and it's harder for that person to endanger your users.
>
> I think that argument is a bit weak, but it's a real possibility.[/color]


It's possible, but if someone has that level of access to your data,
then you're pretty much screwed anyway, I would have imagined...

If they can access your session data folder, then it's probably not
going to be much of a challenge for them to access your scripts and do
anything they want.


--
Oli

re: fingerprinting and HTTP_USER_AGENT

Oli Filth wrote:[color=blue]
> Gordon Burditt said the following on 14/11/2005 15:17:
>[color=green][color=darkred]
>>> However, this part of his (and all the other similar articles)
>>> doesn't make sense to me.
>>>
>>> session_start();
>>> $fingerprint = 'SECRETSTUFF' . $_SERVER['HTTP_USER_AGENT'];
>>> $_SESSION['fingerprint'] = md5($fingerprint . session_id());
>>>
>>> "With a fingerprint that is difficult to guess, little is gained
>>> without leveraging this information in an additional way than
>>> demonstrated thus far."
>>>
>>> I don't really understand how this is more secure than just feeding
>>> $_SERVER['HTTP_USER_AGENT'] into md5() without the secret seed, but I
>>> must be missing something because everybody that talks about
>>> fingerprinting seems to advocate adding a seed.[/color]
>>
>>
>>
>> Consider other threats than the user. If someone manages to snoop
>> your session data (say, an employee of your hosting company), the
>> extra secret stuff makes the fingerprint a bit harder to interpret
>> and it's harder for that person to endanger your users.
>>
>> I think that argument is a bit weak, but it's a real possibility.[/color]
>
>
>
> It's possible, but if someone has that level of access to your data,
> then you're pretty much screwed anyway, I would have imagined...
>
> If they can access your session data folder, then it's probably not
> going to be much of a challenge for them to access your scripts and do
> anything they want.
>
>[/color]

Thanks guys, I will try and email Chris and see what he says. I emailed
him once before with a question about an article of his and he was very
helpful in his response, but it took a long time - I'm sure he gets
deluged with emails every day for the numerous articles he writes. In
the meantime, am I performing my check right? That is my biggest
confusion... if I am performing the

$fingerprint = 'SECRETSTUFF' . $_SERVER['HTTP_USER_AGENT'];
if(md5($fingerprint) != $_SESSION['fingerprint'])
{
// prompt for password
}

check correctly, I see no real reason to use the full fingerprint (other
than what Gordon pointed out). However, if I am missing something here
and should be performing the check some other way, I could definitely
see the benefit in using some sort of padding to create a fingerprint
that does not simply contain the user agent. Thanks!!!

re: fingerprinting and HTTP_USER_AGENT

I think I just figured out the reasoning...

Oli, in response to what you said, I believe we don't want to just store
the user agent in the session in plain text because if an attacker were
to hijack the session, he would easily know what user agent to spoof in
order to trick the system into thinking he is the legit user.

Even with the md5 representation, I don't think it would be *that*
difficult for an attacker who was motivated to supply the correct user
agent for a compromised session, although obviously it would be more
difficult than plain text.

I believe the reason for padding the fingerprint with extra data is so
that if an attacker does in fact hijack a session, it would be tougher
for him to reverse engineer what the user agent is from the saved
fingerprint (as opposed to plain text or the md5 of just the browser).

Someone please correct me if I am wrong, but as far as I know md5 is a
one way function, i.e. we can't reverse it and come back to our original
string.

re: fingerprinting and HTTP_USER_AGENT

Marcus said the following on 14/11/2005 18:38:[color=blue]
> I think I just figured out the reasoning...
>
> Oli, in response to what you said, I believe we don't want to just store
> the user agent in the session in plain text because if an attacker were
> to hijack the session, he would easily know what user agent to spoof in
> order to trick the system into thinking he is the legit user.
>
> Even with the md5 representation, I don't think it would be *that*
> difficult for an attacker who was motivated to supply the correct user
> agent for a compromised session, although obviously it would be more
> difficult than plain text.
>
> I believe the reason for padding the fingerprint with extra data is so
> that if an attacker does in fact hijack a session, it would be tougher
> for him to reverse engineer what the user agent is from the saved
> fingerprint (as opposed to plain text or the md5 of just the browser).[/color]

But a hacker doesn't have access to the saved fingerprint, because it's
saved server-side. It never leaves the server. So encrypting it, etc. is
pointless.

The only exception to this is if the hacker has actually somehow got
access to the session data folder on the server, but if he has that
level of access then you're buggered anyway.

Regardless of how the user-agent string is stored server-side, the input
to the session "validation" routine is simply the plain user-agent string.

Either the hacker knows the user-agent-string or he doesn't, so IMO what
happens behinds the scenes is completely irrelevant.

i.e. if you have some string X, and want to validate it against string
Y, it doesn't matter whether you do:

if (X == Y) ...

or:

if (f(X) == f(Y)) ...


[color=blue]
> Someone please correct me if I am wrong, but as far as I know md5 is a
> one way function, i.e. we can't reverse it and come back to our original
> string.[/color]

This is true.



--
Oli