473,320 Members | 1,832 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

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.
Nov 22 '05 #1
7 2720
Marcus wrote:
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.


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.
js*******@attglobal.net
==================
Nov 22 '05 #2
Marcus said the following on 14/11/2005 08:10:
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 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
Nov 22 '05 #3
>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.


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
Nov 22 '05 #4
Gordon Burditt said the following on 14/11/2005 15:17:
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.

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.

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
Nov 22 '05 #5
Oli Filth wrote:
Gordon Burditt said the following on 14/11/2005 15:17:
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.


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.


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.


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!!!
Nov 22 '05 #6
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.
Nov 22 '05 #7
Marcus said the following on 14/11/2005 18:38:
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).
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)) ...
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.


This is true.

--
Oli
Nov 22 '05 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Sims | last post by:
Hi, if i use... // php $info = getenv("HTTP_USER_AGENT"); // I noticed that Mozzila and Netscape <6(?) both use the same Agent. // so i was thinking of if...
1
by: ruggierorizzi | last post by:
Hi again, what is exact sense of $_SERVER output? Tnx, bye
2
by: Sharon | last post by:
Can I use request.servervariables("HTTP_USER_AGENT") to determine if the user has Firefox or Internet Explorer? Is the return string differentiated enough? Thanks for any input.
1
by: juglesh | last post by:
are $_SERVER in php and navigator.userAgent in js the same thing? always? I just need to determine if the browser is IE5+ on win32 (.png issues).
7
by: patelxxx | last post by:
When I run the code below, the $ENV{'HTTP_USER_AGENT'} is coming up blank, I'm saved the file under .pl and .cgi extensions and still I can't display the browser name. For this reason the code...
5
by: Gordon | last post by:
As part of a data collecting system (basically a system that collects submissions from forms), I was planning on logging a bit of data about the submitting user agent for the purposes of spotting...
3
by: =?Utf-8?B?Yml0YnVja2V0?= | last post by:
hi: i have an asp.net 1.1 app. when i visit the site with my normal browser (ie7 on xp), i get 'default' info in the request.browser object (Type = Unknown, Name = Unknown, Version = 0.0, etc.)....
2
by: kailashchandra | last post by:
<html> <head> <title>PHP Test</title> </head> <body> <?php echo $_SERVER; ?> </body> </html>
1
by: Moiseszaragoza | last post by:
I am wondering what is the equivalent of Request.ServerVariables("HTTP_USER_AGENT") in C#? Thanks
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.