LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   user bypassing demo restrictions (https://www.linuxquestions.org/questions/linux-security-4/user-bypassing-demo-restrictions-782761/)

qwertyjjj 01-17-2010 08:56 AM

user bypassing demo restrictions
 
I have a user that has already used up a demo 24hr trial on my website.
At present, I only check the customer id and the IP address to search for duplicates.
On the whole this works but it's not foolproof. We now have 1 user from China that is changing their IP address everyday to get access to the free trial.
Any options on what to do?
I thought of downloading a cookie to their computer that the website could pick up - again not foolproff but most people don't disable cookies.
Any other options?

I could ban China temporarily until the user gives up but if they find another proxy to chain then their IP address will be different again.

b0uncer 01-17-2010 09:27 AM

Banning all connections from China, or any other source for that matter, is a bad idea because you're potentially banning a horde of "quality users" per one "bad user". I've personally seen way too many forums on the web that, when entered for the first time in my life, tell me my IP address (which is dynamic and thus changes from time to time) is banned and that I would have to contact an administrator to do anything with the site. Banning an area to target one or few users is just a bad idea.

Cookie is also useless. Even if people have cookies enabled, a lot of people (including me) clear them from time to time, perhaps even every single time they close their browser. Therefore it is just as useful (actually even less so) as your IP catcher. Considering the extents to which banks have gone here to identify their users and make sure that the sessions are not hijacked, I don't think you have any real options to restrict your demo to the trial time "completely" except one: have all the users register and have (human) staff check their identities somehow before accepting. Even that's not bullet proof (for example consider how many illegal immigrants there are in USA!) Checking a credit card number might be one way, but you'd need to do it with the credit card companies and that's sure to pay. It could also scare off at least some of your potential demo users, and still not be perfect (card numbers can be stolen...) You could also just limit the demo functionality somehow, but it depends on your product whether or not that's good for the business.

Edit: of course you can collect a warehouse of information from all your visitors and then statistically try to deduce whether or not the user in question is likely to have been there before...but as you may guess, anything that has to do with statistics is only so accurate, and in this case I don't really think it would be reliable enough. Konqueror for example allows changing the browser information sent, so you would only make it slightly more difficult to "get in", not impossible. Of course when you make it hard enough, even the persistent users might give up..

qwertyjjj 01-17-2010 04:16 PM

Quote:

Originally Posted by b0uncer (Post 3829700)
Banning all connections from China, or any other source for that matter, is a bad idea because you're potentially banning a horde of "quality users" per one "bad user". I've personally seen way too many forums on the web that, when entered for the first time in my life, tell me my IP address (which is dynamic and thus changes from time to time) is banned and that I would have to contact an administrator to do anything with the site. Banning an area to target one or few users is just a bad idea.

Cookie is also useless. Even if people have cookies enabled, a lot of people (including me) clear them from time to time, perhaps even every single time they close their browser. Therefore it is just as useful (actually even less so) as your IP catcher. Considering the extents to which banks have gone here to identify their users and make sure that the sessions are not hijacked, I don't think you have any real options to restrict your demo to the trial time "completely" except one: have all the users register and have (human) staff check their identities somehow before accepting. Even that's not bullet proof (for example consider how many illegal immigrants there are in USA!) Checking a credit card number might be one way, but you'd need to do it with the credit card companies and that's sure to pay. It could also scare off at least some of your potential demo users, and still not be perfect (card numbers can be stolen...) You could also just limit the demo functionality somehow, but it depends on your product whether or not that's good for the business.

Edit: of course you can collect a warehouse of information from all your visitors and then statistically try to deduce whether or not the user in question is likely to have been there before...but as you may guess, anything that has to do with statistics is only so accurate, and in this case I don't really think it would be reliable enough. Konqueror for example allows changing the browser information sent, so you would only make it slightly more difficult to "get in", not impossible. Of course when you make it hard enough, even the persistent users might give up..

What information can I collect from their browser that would be identifiable?
I realise cookies could be deleted everytime the browser is closed but then the majority of people do not do this.
IP addresses change dynamically.
I have to keep the demo functionality as automated as it would take too long to setup accounts and check them manually. I can continue to close off the demo when I realise it's the same persistent user and it hasn't been a problem so far but some people will try to bypass the checks.

Someone once mentioned fingerprinting but apparently even these can change from time to time?

Quakeboy02 01-17-2010 06:07 PM

Are you using email validation? Sure, they can change their email, but it's a layer that takes up the abuser's time, but one-time users are used to using it.

qwertyjjj 01-17-2010 06:18 PM

Quote:

Originally Posted by Quakeboy02 (Post 3830204)
Are you using email validation? Sure, they can change their email, but it's a layer that takes up the abuser's time, but one-time users are used to using it.

Well, I use email validation only in the sense that if they have already used the demo then it is registered against their customer ID and therefore email address. They are getting around this by registering a new free email account and registering on the site a s a new customer and with new IP address.
Fortunately, they are not very inventive on their country origin or customer name so I can see it is a duplicate but that is purely coincidental, they could change their name if they wanted.

smeezekitty 01-17-2010 07:16 PM

Quote:

Originally Posted by qwertyjjj (Post 3830210)
Well, I use email validation only in the sense that if they have already used the demo then it is registered against their customer ID and therefore email address. They are getting around this by registering a new free email account and registering on the site a s a new customer and with new IP address.
Fortunately, they are not very inventive on their country origin or customer name so I can see it is a duplicate but that is purely coincidental, they could change their name if they wanted.

That also implies they will be able to bypass cookies too.
BTW How do you know its the same user?

qwertyjjj 01-17-2010 07:33 PM

Quote:

Originally Posted by smeezekitty (Post 3830257)
That also implies they will be able to bypass cookies too.
BTW How do you know its the same user?

They could bypass cookies but how many people really delete cookies?
I know it's the same user as they tried a duplicate demo order, then a duplicate IP showed, then they registered under a new customer but with the same name. Once a day around the same time, they register under a new customer as the same firstname but made up 2nd name...obvious stuff for the moment - I just sent them an email to warn them but I'd prefer to have some checks pick up the possibles.
ANyone who knew what they were doing could bypass it more easily I reckon.

smeezekitty 01-17-2010 07:35 PM

Quote:

Originally Posted by qwertyjjj (Post 3830273)
They could bypass cookies but how many people really delete cookies?
I know it's the same user as they tried a duplicate demo order, then a duplicate IP showed, then they registered under a new customer but with the same name. Once a day around the same time, they register under a new customer as the same firstname but made up 2nd name...obvious stuff for the moment - I just sent them an email to warn them but I'd prefer to have some checks pick up the possibles.
ANyone who knew what they were doing could bypass it more easily I reckon.

How about a name comparison?

chrism01 01-17-2010 07:35 PM

Realistically, given they go to a lot of effort already (new IP & email), unless you supply the passwd to the user at first login, and they can't change it, I don't think you can stop them.
They can always register a new acct even then...
Also, even then they can share it ...

qwertyjjj 01-17-2010 07:45 PM

Quote:

Originally Posted by chrism01 (Post 3830277)
Realistically, given they go to a lot of effort already (new IP & email), unless you supply the passwd to the user at first login, and they can't change it, I don't think you can stop them.
They can always register a new acct even then...
Also, even then they can share it ...

I get past the sharing by not allowing 2 different IP addresses using the same login.

qwertyjjj 01-17-2010 07:46 PM

Quote:

Originally Posted by smeezekitty (Post 3830275)
How about a name comparison?

Maybe in a bit of SQL that I then have to check manually every day?
The demo is only 24hrs so they'd probably have some access but really this is just about making it more difficult for them.

chrism01 01-18-2010 06:57 PM

What I meant was that if they are willing to change IP addresses to get a new demo acct, they are also willing to share (give) their IP address with their mates as in 'here's a working IP + email for the demo' and then the first guy creates a new acct as you've described...

qwertyjjj 01-18-2010 07:03 PM

Quote:

Originally Posted by chrism01 (Post 3831517)
What I meant was that if they are willing to change IP addresses to get a new demo acct, they are also willing to share (give) their IP address with their mates as in 'here's a working IP + email for the demo' and then the first guy creates a new acct as you've described...

The demo only lasts 24hrs and each login can only be used by 1 IP address.

r0b0 01-19-2010 04:08 AM

What is the structure of IP addresses? They must be limited to a specific IP block. You can either block the whole block (no pun intended!) or put an extra verification step for requests from this block?

b0uncer 01-19-2010 02:29 PM

Quote:

Originally Posted by qwertyjjj (Post 3831522)
The demo only lasts 24hrs and each login can only be used by 1 IP address.

Referring to my earlier post, IP addresses can and do change, and in some cases this can be quick. Many ISPs I know that give public IP addresses do try to keep it the same at least for some time, but at least the last dialup connection I had changed the IP every time I reconnected. Therefore you should assume, even though it isn't very probable, that some "good" customers may well have their IP change during that 24 hour demo time and thus will be unable to take full advantage of it...of course you could count on the number of such clients being low and give them a way to inform you that this has happened, in which case you could grant them extra time. But it's more work, again.

Quote:

Originally Posted by r0b0 (Post 3831920)
What is the structure of IP addresses? They must be limited to a specific IP block. You can either block the whole block (no pun intended!) or put an extra verification step for requests from this block?

Again, even if you block one block, you're potentially blocking hundreds of IP addresses at minimum. I wouldn't go there unless it's the very last chance.

As to what information can be collected from the visitor, see for example this page. There are plenty. You could try to turn this into a sort of fingerprint, but it is easily cheated and not too reliable.


All times are GMT -5. The time now is 09:54 PM.