fingerprinting and HTTP_USER_AGENT

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

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

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

$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  

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:

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:
Quoted text here. Click to load it


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.

Re: fingerprinting and HTTP_USER_AGENT

Marcus said the following on 14/11/2005 08:10:
Quoted text here. Click to load it

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?


Re: fingerprinting and HTTP_USER_AGENT

Quoted text here. Click to load it

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:
Quoted text here. Click to load it

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.


Re: fingerprinting and HTTP_USER_AGENT

Oli Filth wrote:
Quoted text here. Click to load it

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

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  

Re: fingerprinting and HTTP_USER_AGENT

Marcus said the following on 14/11/2005 18:38:
Quoted text here. Click to load it

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  

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) ...


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

Quoted text here. Click to load it

This is true.


Site Timeline