I was looking for a way to create an IP filter, so that I could easily identify customers, but many examples I saw, I could not understand in a way.
Then, I come here with some questions
A customer enters my site, IP x recovered from $_SERVER ['REMOTE_ADDR'], but I've been reading some things about CRID, which is one way to check if this IP is on the list denied, because obviously 90% of customers accessing the site, when you restart the modem IP is changed, I do not know if I'm talking nonsense, but a good idea to create an IP filter?
You should combine multiple factors such as sessions, cookies and ip filters.
But of course users still be able to clear cookies and sessions.
You may try to get mac-id of user's pc or computer but it is complicated and dunno it is useful or not and also user still can change mac-id but it's not an easy thing to do.
Related
I am thinking of a very simple log in system that doesn't require a login, but instead a system with an id and store it in a database. Then when the user comes back to the website he gets matched with his unique ID and logged-in in that way.
I am trying to do this with php as much as possible, initially I wanted to do it by using the IP address but as some people pointed out, places such as campuses share the same IP for many, many users.
So is there any way to uniquely identify each computer without using cookies, sessions or anything else that is client-side. Preferably with php.
No it is completely impossible to do what you are asking. The only theoretical way would be, as you say - the MAC address but it is not sent in web requests.
I am making a script that show popup only one time , then it will never show again on that device..
How is it possible to do this?
I have already tried by using cookies, but these can be deleted by the user and so the effect is limited.
Another question is what is wholly unique per device, IP Address or MAC Address?
The only way is a cookie. There's nothing 100% uniquely identifiable about a machine that you have access to in an HTTP request. Yes, cookies may be deleted by the user. This is deliberate, live with it.
The 2 options that are most obvious are either Cookies or a flag on an Account (if your users are authenticated).
Even though you've mentioned that cookies can be deleted, it's still a reliable form of saying "I have done something for this client before". If the user deletes the cookies then there's a high chance they know what they're doing, and should be expecting to have to repeat tasks (such as logging into other websites too).
If your users are authenticated (namely: they have to login to your site/service), then you can easily store a flag saying that the user has already been shown the notification.
That way is of course more reliable, but relies on authentication. Long story short: You need to take what you can get, and cookies are your best bet to have some form of unique device ID.
Regarding your other question: Nothing is unique in reality. MAC Addresses (which you wouldn't have access to anyway) can be spoofed, and IPs can be shared.
Neither. Millions of Internet devices have 192.168.0.2 as their IP. So that's not unique. And MAC addresses aren't Internet things at all, they're Ethernet things.
If you explain your outer problem in more detail, there's probably a solution. But it sounds strangely bogus from what you've said already. The same person on two different devices should get the popup twice? But with two people on the same machine, the first person should get it only? It's hard to imagine a use case where you should go out of your way to ensure that.
I'm upping my security on my website, because some of my users were
questioning the security, but all I can say is no one can view your
password (dual hashed using SHA-512 and then md5), but they reply, but what if they get into my account they
can change my password and play around with my account.
So I'm going to up my security kind of like Steam's security where you can't login to a
new computer without them sending you a random key. I'm trying to think of a way to do it, so I've got it so it will store a little array in my database that will have all the computers that the user has logged in to with.
But I need some data so that my script can check it but I'm not quite sure what data, I was thinking of the IP address but you can't get it without an external source e.g whats my ip and other sites like that. I need some data that doesn't change with the same browser/computer.
So question is, I need some data that is unique to the browser he/she is using but it does change if he/she is on a different computer or browser.
It is possible to implement some security in your web application on IP level. As a matter a fact, for example, in the company I am working it's possible to log in with "Administrator" account only from the devices connected in company network - a given range of IP address.
If you want to implement this technique for each user, you will meet a lot of issues because your users can be behind some proxy server, that is changing their IP address on each log in or on given interval of time.
They are different types of proxies and you can detect when the user is using some of them, and then retrieve the real IP address of the user - check this HTTP headers:HTTP_X_FORWARDED_FOR, HTTP_VIA AND REMOTE_ADDR EXPLAINED and more specific this X-Forwarded-For one.
Any way, they are a lot of techniques to hide you IP address like proxy servers and applications like HideMyAss that makes the whole thing pretty easy.
Anyway, even your users send to you a specific set of email address that you will store in your database and check if the users are connected to your application using them, the same possibility for abuse, using your account (as the passwords) is faced again. The IP addresses will be just an other field in your database table. So, if anyone can change the passwords, he might be able to add an other new IP to the IP list that your are checking.
I think that the best think to do, is to implement such IP security only for your administrator account. Then, you and your clients will be calm that no one can join with it and change their passwords.
Don't know if you have many users, I never did this in a practical application but played with bouncycastle a long time ago. Had a similar problem with a 3rd party provider providing services to out company with IP filtering but Dubai offices were refused because some proxy gets in there that doesn't provide forwarded for and has a wide IP range.
Here is the option I was thinking of but never applied:
Making a self signed key for each/all/groups of client to import and and importing the public part of that in your server store, then do not allow anybody there unless they have a key that's imported in your server keystore.
Maybe if you serve companies that use a proxy you can have the proxy serve the key.
I'm currently in charge of setting up a polling system (using PHP).
Now for it to be as secure and objective as possible, it's important that a visitor can only vote once. I'm thinking of validating the polls by visitor's IP (there can be only one vote from one IP), and maybe throw in a captcha test to be sure that no bots can get in once they've passed the IP validation for some reason.
So there it is, unique-IP validation and captcha. But is this enough ? Is there a possibility that a single user can change his/her IP by using proxies or other ways I don't know of, and vote multiple times with unique IPs ?
Are there better ways to do this ? Preferably without the captcha.
Thanks in advance.
There is absolutely no way to be sure a user has voted once when it's a public voting system, where no login is required.
Checking the IP is not a good idea for several reason. As described in other answers, lots of networks are behind one ip, and users can just use an other pc with different ip and vote again.
OpenId
Use OpenId to identify the user and check if they have already voted.
Register users
Optionally you could allow users to register themselves if they do not have an openid account.
To implement a secure system, where session spoofing, and thus multiple voting, is made difficult read this
You can't create a 100% secure voting system.
If it's based on registration/IP/cookie, the user can create a new user/get an another PC/delete all cookie.
But you can try it with auto prefilter + administrator as postfilter workflow:
Prevent multiple voting with cookie (or IP / browser properties / etc.) filtering automatically.
On an admin view, the administrator can parse and delete votes by hand based on IP or subnet address. This is nor a perfect solution, but with some good query (same votes in the same time intervall from the same IP/subnet) the administrator can easily delete suspicious votes.
One big drawback of this solution is the need of an administrator. But - I think - there is no perfect solution.
Unless you're going to require identity verified by CA, there is no way you can be sure, that each person votes only once. This of course would be total overkill, so the real question is: how to make multiple votes more difficult.
email with verification code. IMHO overkill, but depends on how sure you want to be.
use session to check who voted. Obviously not 100% secure, but will stop 99% of ppl.
use cookie to check who voted. Like above, some ppl will know how do delete cookies.
use POST, ignore GET.
use combination of 2 or 3 of above.
If you're going to use IP for validation, do not use just REMOTE_ADDR, combine with whole X-Forwarded-For. This way you won't block people connecting through same proxy.
Don't go with the way of unique Ip. There are a lot of case scenario where a lot of users have the same ip (i.e. italian isp fastweb, large corporations, etc). Also, if user has dynamic ip it can change it's own ip address every time he likes...
One of the best ways should be using email address and cookies. User will be able to vote multiple times (you can't avoid this), but at least it will take them some time for each vote.
for a similar project i did 2 verifications ...
i placed a cookie and also saved on the server a hash from users ip + user agent.
this seemed to be pretty effective since even if there are more people that use the same IP the hash with user agent will be different most of the times since it differs for same browser depending on the operating system and other extensions installed.
There is no fool proof way for preventing multi votes. Checking cookie is anothr option.
Regarding Validatin the ip address. What if the user is from a net work which is used by many users?
Two types of users visit my website: registered users and guests. Registered users are tracked and retained by PHP session, cookies and individual logins. Guests I find trickier to manage so I give little to no authority to contribute content.
I want to open up editing for users (registered or not) to save favourites, shopping carts, vote in polls, moderate, tag, upload and comment. At the same time, protect the data from other non-registered users.
What are some options or best practices to determine a unique visitor from another and some security measures to consider when allowing them to contribute more? Should I work around their security/restriction settings to provide contribution service or should I expect them to meet in the middle and relax some of their settings to allow cookies etc?
IP Address - The IP is an option but only temporary. It can change for a user reconnecting to their Internet with a different IP, and for that matter another user may eventually share the same IP. IP can also be anonymous, shared or misleading.
PHP Sessions - OK for a session (and if enabled) but lost on closing the browser.
Cookies - Can store session data but is easily (and often) disabled from the client-side.
Header data - combining known details of he user might at least group users - ISP, browser, operating system, referring website etc.
Edit: I'm still having trouble getting my head around all the the key factors involved... we set up a cookie for a guest. Attach a bunch of edits and user history to that session. If the cookie is removed, the data floats around attached to nothing and the user loses their data. Or if the user logs in, the guest and user data should be merged...
I think cookies would probably be the best option here as it's the only way you are going to be 100% sure requests are unique. Of course, you could possibly add a mix: if cookies are disabled you might be able to try other options of identification such as the IP address method, but that could make it overly-complex.
As you say, IP address is liable to change and in some organizations there may be a group of proxy servers setup which make requests originate from different IPs. Of course, you could check X_FORWARDED_FOR, but they are still liable to change.
Header data is probably going to prove difficult to get good results on I think. If you've got an organization that has the same browser, OS, IP it is going to show people as being the same. Even people not in the same organization may still appear similar (i.e AOL users who get their traffic usually routed through proxy servers, the majority will probably be using the 'AOL browser' that gets shipped with it giving similar headers).
Out of those two options, the IP one is going to be easy to implement but obviously there are the problems I outlined. Checking for unique data in the headers will prove to be absolute pain I think.
Obviously as you say, sessions are lost on closing the browser, and it appears you want the system to behave as if they were a registered user so cookies seem a more obvious choice (especially as you want the 'favourites' to be persistent).
I would just go with sessions.
Your users could change IP addresses (prone to mixup behind NATs and proxies), modify/delete cookies (certainly possible), or change their header (easily through switching browsers).
There is no secure way of identifying a guest if they do not want to be identified. Just go with the standard: cookies/sessions.
You should use sessions.
Sessions id are stored in a cookie (or for users who doesn't accept cookie, stored in the url with the PHPSID argument)
They won't be erased when the user will close his browser, it just depends on how you set your session/cookies options.
You can set up the timelife of a session to whatever you want, so don't bother with this.
You should also tell to your user about this (enable cookie)
Concerning the data which could be merged when log in, it's your job, to merge it in a proper way, or even ask the user if the option should be saved or not.
You could use a combination of all of the identifying points that you can find, that are not likely to change, and are likely to be unique - looking at panopticlick you can gather a bunch of data such as installed fonts and browser plugins. You could take those kinds of more unique data points and hash them to give you an id, and then compare it against the less unique data like useragents and ip addresses.
But honestly, that's super complicated and sneaky. Use cookies/session. If the user doesn't want to enable cookies then they don't want all your anonymous tracking for a reason, and you should honor their decision.