Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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..
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?
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.
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.
Distribution: M$ Windows / Debian / Ubuntu / DSL / many others
Posts: 2,339
Rep:
Quote:
Originally Posted by qwertyjjj
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?
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.
Distribution: M$ Windows / Debian / Ubuntu / DSL / many others
Posts: 2,339
Rep:
Quote:
Originally Posted by qwertyjjj
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.
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 ...
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.
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.
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...
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.
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?
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
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.