NYCPHP Meetup

[Dan Cech]

Joseph,

To understand the approach you need to take a step back and look at the 
bigger picture of what we're trying to achieve.

Say we have a client who always uses the same browser, and all of a 
sudden you get a request that comes from a different browser.  This does 
not fit the profile, and so we should prompt for a password because it 
is likely to be an attacker.

If you have a client who for whatever reason changes their user agent 
string all the time, you don't want to enforce the user agent check 
because it will just annoy them, and probably lose you the client.

So, you keep track of the user agent to see which the client in question 
is.  If you are dealing with the former, enforce the check because it 
will increase their security, otherwise use a different check.

The counter is there to determine which category the client in question 
falls into, so when their user agent hasn't changed for some number of 
page loads you assume they fall into the first category and enforce the 
check.

This same approach could also be very powerful when applied to IP 
address checking, to provide protection for clients whose IP does not 
change often, without affecting those who do.

Dan

Joseph Crawford wrote:
> That seems a bit backwards to me.
> 
> If thier User Agent doesnt change and it hit's my threshold why should i 
> prompt for a password? If thier user agent continuously changes they will 
> never get prompted for the password. Isnt the idea to promp for the password 
> if thier user agent changes often?
> 
> I guess i am not understanding why it would work like this
> 
> user hits the page User Agent stored
> user hits again User Agent Compared
> If they match increment counter
> 
> When counter hits threshold prompt for password.