Re: [WEB SECURITY] Ways To Identify Returning Web Visitors

[Nathanael Hoyle <nhoyle@xxxxxxxxxxxxx>]

James Hatcher wrote:
> My company has a problem with certain people repeatedly coming back to 
> our website and performing fraudulent transactions.
>
>  
>
> In an effort to stop these people from performing transactions, we 
> attempt to identify returning visitors in a couple of ways:
>
>  
>
>    1. Our site sets a long-term persistent cookie in the user's
>       browser that contains a unique identifier.  If our fraud
>       investigators see that someone with a particular cookie is
>       performing fraudulent transactions, their cookie is added to a
>       "black list", and if they come back to the site later with that
>       cookie they are not allowed to perform transactions.  Of course,
>       the fraudsters were mostly able to quickly figure out that they
>       can get around this by deleting their cookies every time they
>       come back to our site.
>    2. We then started setting another unique identifier in a Flash
>       cookie and added a black list of fraudulent Flash cookie values.
>        This works better than the regular cookie because not so many
>       people know how to delete Flash cookies, but it one could still
>       get around this by deleting or disabling Flash cookies.
>
>
> We would love to be able to identify a user's computer by MAC address, 
> but MAC address is only used for point-to-point communication on a 
> network so we don't have the ability to see the user's MAC address.
>
> Using a blacklist of client IP addresses is not feasible because some 
> of the fraudsters are using ISPs where many people come from the same 
> client IP, including legitimate users.
>
>  
>
> Beyond the ideas mentioned above, are there any other ways to identify 
> repeat visitors to a website that keep coming back using the same 
> computer/browser?  I realize that any answer you guys give me will 
> probably be another cat and mouse game like the solutions above, but 
> I'd be really interested in anything we can do improve our ability to 
> detect these returning visitors, even if they are just small 
> improvements.
>
>
> -Jim
I'm not aware of much that you can do that is reliable.  As you said, it 
is mostly cat and mouse.  Also, your comment about MAC addresses implies 
that you believe the MAC address is a reliable identifier (if you could 
see it), when it is in fact not one.  While it is somewhat more 
difficult in most cases than clearing cookies, the MAC address your 
computer presents to the local network segment can readily be changed in 
most cases.

As a counter to someone disabling flash, it would be possible to make 
some part of the transaction process *rely* on flash in such a way that 
the transaction cannot be completed if flash and/or flash cookies are 
disabled.  I would not rely on this.  Never rely on the trustability of 
data you send to a client coming back to you for authentication... an 
advanced attacker could randomize the flash cookie identifiers on the 
fly via a custom proxy of some sort...  Furthermore, this imposes the 
flash requirement on all of your customers... undesirable in my own 
mind, although more and more commonly accepted I suppose.

Even if you wanted to block whole IP ranges, people using anonymous 
relaying proxies or networks like tor, etc could bypass such 
restrictions.   I believe you may be attempting to attack the problem 
from the wrong angle.  An attacker's computer is, by definition, under 
his or her control, and can thus be made to present itself to you 
differently at the whim of the attacker.  Unless you wish to force your 
users to install a nasty activex component which calculates hashes of 
hard drive serials, install dates, license keys, etc to generate a 
machine id... (I'd never shop with you if you did that).

Rather than trying to exclude certain computers, however, I would look 
at user accounts.  If users are performing transactions, they reasonably 
would need to identify themselves to the system.  Make the sign-up 
process non-trivial enough and people may tire of it:

* Require a valid email address to activate a new account.  Optionally 
exclude email accounts from free email providers you observe to be 
abused by your attackers.

* Require the user to pass a captcha during sign-up.

* Possibly try validation of this sort: "For security, to prevent 
automated sign-ups, please enter the next value in this sequence: '3 6 9 
12 15  ___ '" Easy for most humans, but with a variety of such puzzles, 
harder for a machine.  Multiple choice is bad: four options to choose 
from just means the script has to run 4 times as many times to generate 
the same number of bad accounts.

If it's too much effort to generate a new, valid account to try again...

All of this is still prone to cat and mouse.  Your mileage may vary, all 
of that...

Aside from that, you may need to examine why the same individuals are 
able to pursue many fraudulent transactions.  If this is "Real Money 
(TM)" fraud, i.e. credit card fraud or similar, you really need to 
pursue formal channels for police reporting of the incidents.  That's 
not a panacea by a long stretch, but sending people to prison can be a 
deterrent.

Good luck.

-Nathanael




----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA