I'm making a satistics program in PHP but do i need to notify the user that i am storing their Ip address? I've converted it to an INT with ip2long but i am not sure if it is allowed without notification or a privacy statement on your site.
In short:
Is it allowed to Save the visitors IP without their knowing?
An IP address in isolation is not personal data under the Data Protection Act, according to the Information Commissioner. But an IP address can become personal data when combined with other information or when used to build a profile of an individual, even if that individual's name is unknown.
In the hands of an ISP an IP address becomes personal data when combined with other information that is held – which will include a customer's name and address. In the hands of a website operator, it can become personal data through user profiling.
Most sites do not profile their users using IP addresses. They typically use IP addresses for demographic purposes such as counting visitors, their countries of origin and their choice of ISP. Their organisation might also be identifiable.
Sites typically gather statistical data about the path that users take through a website and the page from which they left the site. Banking websites might also use IP addresses as a security measure – for example, if a customer regularly accesses his account from an IP address in London, access to that customer's account from an IP address in Moscow might indicate fraud.
The most common privacy concern surrounding IP addresses is their use in marketing. A visitor's path through a website could be followed and any adverts that are clicked can be identified. On the next visit, that user could be shown ads that are similar to those he clicked on the previous visit. But this fails when the user has a dynamic IP address: the user will be unknown.
Other alternative would be:
Accordingly, most websites prefer to use cookies to track users for personalised marketing purposes in preference to IP addresses. A cookie is a small text file that is sent from a website to a visitor's computer. The cookie file can be used to identify an individual and a website operator can build a detailed profile of that person's activity at its site. Users can set their web browsers to refuse cookies but most users accept them, often unwittingly.
I may be wrong but since IP is not a personal data and since you are just using it for demographic purposes, you don't have to notify the users about it. The process is pretty much legal, and almost all websites are using this for tracking purposes.
For more information
Others
Related
Every users who is visiting my web page I store ip address and also send details of the user to the Google analytics (GA). But after 2 days I see my database table is showing 150k users but GA shows 6000 users.
I am using cloud flare variable to store IP address below is the syntax how I am getting the IP
$_SERVER['HTTP_CF_CONNECTING_IP']
How can I prevent this? I am storing only unique IP addresses
I'm building a website that sells items cheap and proceeds go to charity. You can't just buy an item though, because they will be very limited in quantity, so we want to give out free raffle tickets (daily) to users who visit the site. We'll then do a random drawing and the winner can buy the item.
My concern is people making 1,000 accounts to improve their odds at winning. I need a good way to prevent this from happening. Right now I'm thinking of checking IP ranges (12.12.x.x) to see if that IP has already received daily raffle tickets, but how reliable is that - what with proxies allowing people to use different IP's.
The somewhat-standard solution would be to require each user to provide an email account when they make their account. You then send an email to that email address, containing a unique link. When that link is clicked, you activate the account associated with that email; before that, they can do nothing.
You can have multiple steps of security in this case.
Have users sign up with unique email address and verify that when they sign up.
Log the IP address they signed up with in your database.
This will not keep them from using proxies or creating multiple email addresses.
I suggest having them also add a unique Street Address.
If they try signing up again with that same address, reject them.
You can also check for the phone number. For extra security.
recently I helped some friends ship an invite system in their website that works like this: A user creates an account, we send a verification email and when he verifies the e-mail he gets one free credit to spend on the website. In addition to that, he has personalized links he can share on social networks or via e-mail and when people register using this link (e-mail verified accounts again) he gets one credit per invite. Much like the invite system on thefancy.com or any other reward driven invite system on the web.
Lately we see elevated rates of fake user account which probably are automated. The registration page features a CAPTCHA but we're aware this can be bypassed. We also see elevated rates of users creating disposable email addresses to create accounts following specific invite links thus crediting one legit users that onwards uses the free credits he earns.
I am looking for an automated way to prevent such kind of abuse. I currently investigating putting rate limits on invites/registrations that come from the same ip address but this system itself has it own flaws.
Any other production tested ideas?
Thank you
Edit:
I've also proposed 2 factor registration via SMS but was turned down due to budget shortage.
It seems you need to require more than just a verified email address before a user can send invites, ideally something that shows the user has participated in your site in some way. Without knowing what your site is it's hard to give specifics, but the StackOverflow equivalent would be requiring users to have at least X reputation before they can invite others. If you're running a forum you could require that they've made at least X posts.
I'd also suggest a small time limit before new accounts can invite - e.g. they have to have been a member for at least X days. This complicates automated invites somewhat.
An extremely simple method that I have used before is to have an additional input in the registration form that is hidden using CSS (i.e. has display:none). Most form bots will fill this field in whereas humans will not (because it is not visible). In your server-side code you can then just reject any POST with the input populated.
Simple, but I've found it to be very effective!
A few ideas:
Ban use of emails like 'mailinator'.
Place a delay on the referral reward, allowing you to extend fraud detection time period, giving you more time to detect bogus accounts and respond accordingly.
Require the referred user to create a revenue generating transaction before you give out any referral rewards (I know that might not be a shift you can make) - possibly in turn increasing the reward to account for the inconvenience to the referrer (you should be saving money through decreased fraud so not a hard sell).
Machine learning. Ongoing observations and tuning with your fraud detection. The more data you have the better you will be able to identify these cases. (IP addresses as you mention.) Shipping / billing info even more telling if it applies - beware adjacent PO boxes.
Add a CAPTCHA test to the confirmation page. I would be wondering if your CAPTCHA is sturdy enough if it is getting bypassed somehow. You might consider using the (hateful) reCaptcha which seems popular. A CAPTCHA on the confirmation page would reduce the risk that a 'bot is submitting the confirmation page. In other words, it would implement the idea of client interaction with the site after registration. A similar method would be to ask for the registrant's password.
An issue that has come to light is to open up our application (we can visualise it a bit like an online shop) to unregistered users.
At the moment, there is an admin system where staff are added by superusers and a website with customers who add themselves by registering.
We have been asked to allow customers to use the website without registering or logging in, but we don't want to break the 'orders' table - we still need to refer to each customer individually and maintain the registered users functionality (address lookup, purchase history, etc). The main idea we've been mulling over is to use the unregistered customer's email address as a replacement for the surrogate key (or a hash of it) in the customer table so that new and old customers can just enter their email address at checkout to be added to our database and receive confirmation of their order. The problem of different email addresses per customer can be alleviated by a 'merge' tool on the admin side, and the problem of multiple customers sharing the same email (some office environments) isn't that much of a problem for us.
The main question is this: how do real-world applications handle unregistered users?
Update in response to answers
We don't want to force registered users to login each time even if their email address is already on our system as a registered user. Also, if people are advocating using the email address as a key, how would you deal with a scenario where a registered account holder gives up their email address to someone else?
In our company, we do it this way:
when ANY user makes an order, we look up his email (which he is required to specify and is unique) in customers table.
If it isn't there, we simply create the user (we already have all required data from the user's order) and we mark him as registred=0.
now we continue the order process with his user id.
when somebody registers under that email, we simply update his credentials (whatever he specifies), while keeping his order history and whatever else. I don't think that makes a security concern, the user is required to confirm the email address, so unless the account is really his, he wouldn't register anyway.
We don't allow already registred email to create an order, so that should clear out your merging of emails, because nobody will be able to create a registered and unregistered account under one email address and when he's done, he will never be able to shop unregistered again. Hope this helps.
I would recommend against using a natural key in this scenario since they are not interested in registering and wouldn't expect their details to be remembered (at least that's what I think of in un-registered mode).
Use a completely synthetic key (like a counter) and just go with that.
Unlike Pal, I would strongly favour using natural data as a key.
use the unregistered customer's email address as a surrogate key
First, that statement is an oxymoron. A surrogate key, by definition, is unrelated to the actual data.
Next, if you have their email address that means they have completed some sort of registration process.
If you have users sharing an email address (i.e. an assertion of identity) then by definition they want to share that identity - trying to differentiate between them is not your problem - particularly where you're already providing a mechanism for them to be individually identifiable.
The only thing you have to worry about is whether by using the email address in the absence of other authentication, you are leaking information which would otherwise be confidential (e.g. previous orders)
I have a website that is starting to grow but with that comes users who continue to signup and send SPAM messages to other members. I currently use google's captcha API service but if a user creates an account manually then it's of no use. My main problem is after a user creates a fake account they start sending duplicate messages so my thought here is to check with some PHP code for similarities in messages and deny them after x amount sent but I'm not sure how much of a load this puts on the server. Is there a way I can maybe grab the IP when they signup and ban that IP if they start spamming people. It's driving me nuts because I spend almost an hour a day now cleaning up SPAM and removing invalid users. Have others run into this and what measures have you taken?
There are various solutions but none of them work perfectly, It would be best to use a combination of solutions.
A few solutions:
Enforce a time limit for sending messages (1 message per 30 or 60 seconds)
Use the PHP function similar_text to check a new message against the last sent message and deny sending the message if the similarity is above a set percentage (I would guess above 70%)
Use CAPTCHA's if a user sends a lot of messages during a set time
Keep a list of IP adresses ($_SERVER['REMOTE_ADDR'] tells you which IP the user has) in your user database and keep a ban list which you then use to check against when a user registers to keep them from creating an account.
Give your users a report button which notifies you of spam
Automatically Temp-Ban a user when he/she is reported often
Also keep a ban list based on the email address of users (It takes more time for a spammer to create a new email address (only do this with confirmed email adresses as email adresses can be hijacked)
These are only some of the available options, just try to make the life of a spammer as hard as possible.
To get the IP of a user use
$_SERVER['REMOTE_ADDR'];
One step I've taken above and beyond is I've tapped into StopForumSpam's API to automatically block a user if their IP or email is found in their spammer database. Much smarter than a captcha.
I would recommend looking into a similar solution if you're getting hit a lot with spam.
The only one method used to develop my WAF was analyzing the traffic:
HTTP headers
request URL, method, protocol
POST data
GET parameters
COOKIES
Even it took years, the end product is a very sharp knife.
It should be connected to the linux firewall. I use Fail2ban.