I have been considering the problems arising with user authentication, using sessions/cookies and the security risks that come up with session hijacking. I understand that using a secure https:// is the most effective method, as well as regenerate_session_id() and using a random string for validation (amongst numerous additional procedures).
My question is this: is there a possibility to incorporate a method that forgoes sessions and cookies, and uses just database held variables?
Here is how I would set it up:
-Have a column in the user table that can hold an IP address, and one that would be a Boolean.
-When the user 'logs in', set the current IP address of the user into the database, and sets the Boolean value to false (if the user doesn't want to be 'remembered') or true (if they do).
-On page load, it checks the current IP address with the one stored in the user database. If it matches, the user is considered valid.
-On window close, the script would then clear those values and the user would be 'logged out'.
-If the user wanted to 'stay logged in' (which I know is a huge security risk) then a toggle (the Boolean value) would simply deactivate the log out script and the IP address would stay stored for the user.
What would be the fallbacks to such a method? Is it even possible?
IP addresses are simply not an accurate and reliable way to uniquely identify a user. The IP may change during the session, and more than one user agent may be using the same outbound IP.
Sorry :-)
I saw this kind of IP check on a system recently, and it was causing numerous problems with users being randomly disconnected all the time (whenever their dynamic IP changes). Just don't do that, IPs can changes so you cannot rely on them.
Most likely, you should take a look at existing authentication methods and try to implement that. Keep it simple.
The existing answers saying "dynamic IP is an issue" are absolutely correct. Consider a mobile device connected via 3g. each time the user walks into range of a new tower their IP changes...
Related
I have a table temp_views which stores temporary views (for an hour) based on the ID of a post, the IP of the user and their user agent string.
SELECT COUNT(*) as viewed
FROM temp_views
WHERE showcase_id=:showcase_id AND ip=:ip AND user_agent=:user_agent
Both the IP and the user agent are stored in the table as simply TEXT. (Should I be doing that another way?).
If viewed is 0, then it adds a view - otherwise it does nothing.
What I'm wondering is, can this be "gamed" at all? If the IP matches but the user agent doesn't, then it will add a view. Can the user agent be spoofed easily or something? (A view is added asynchronously with Ajax as the user scrolls down the page).
Additionally, is this slow/inefficient or is it okay?
There's actually no 'for-sure' way to check for unique views.
For IP Addresses, users can modify their IP Address using VPN, proxy server, etc.
For User Agents, users can define their own user agent, usually in Developer Options. Even in iOS, there's a Request Desktop Site in Safari.
For storing Cookies, users can also delete the cookies thus each page visited will result in 1 view count.
Thus, there's no foolproof way to detect unique visitors.
One way is to store a Cookie in the user's browser, thus if the Cookie is found, the IP will not be recorded. Even though users can delete the Cookie, usually people won't do that. It would be more accurate than using IP only.
The only way to distinguish different users that can't be spoofed easily is by requiring them to authenticate.
The usual way to track users is with a cookie. Users can delete cookies, so it's not perfect, but they generally don't.
When the user connects, check whether the tracking cookie is set. If it's not, generate a random string, set this as the cookie value, and insert it into the database. If it's set, search for a row in the database with this value.
You should not rely on user agent, it is sent by the client, it can be defined by the user in the browser, the cURL client, etc. One user who would like to increase this counter may perform an infinite number of requests with random user agents, even from the same IP address, and fill your database with fake data.
For example it can be done with a Firefox add-on.
I suggest to use only the IP address in order to distinguish visitors. It's much harder to change the IP address (using a VPN is not easy) than change the user agent. The numbers will be close to the number of actual visitors.
On Monday, I thought I had solved the session hijacking security issue by setting the session as the user IP, until I logged in. I had two users with the same IP (myself and a test user) and it kept switching between the two. Is there a way to prevent this and allow two users with the same IP register on my site?
Thanks in advance,
Terry.
You may have been reading advice about storing the user's IP in a table along with the session id (not in place of). You'd then check to make sure they're coming from the same IP on subsequent requests, otherwise, force them to login again. This method has problems as well a user's ip can change as often as every ten minutes depending on their ISP!
Use the session id provided by PHP as it's unique and difficult to guess. Require it to be read from a cookie and never from the URL.
SSL the entire site if it is a concern and apply a short cookie time out. The ssl will encrypt the cookie and transmission so it can not be sniffed off the wire. A short time to live will make the cookie useless soon after it has been taken from the "logged in" computer if they have direct access to the system. So in short get a security cert and go on as normal with a normal php session.
I take it you're looking for the user's information in the MySQL database, using their IP? That is wrong. The only way to be truely unique is with a primary key field.
Either store the primary key as the session and pull their data, or store relevant information in the session and only pull anything else when it is needed.
I want to keep track of a user so they don't vote twice in a poll. I don't want to use an IP address because the application I'm creating is targeted towards a campus and many people will have the same IP address because the wireless network uses NAT. Also, I don't want to use cookies or Session ID because those can easily be deleted.
How can I do this? Or am I out of luck?
I've looked at this question: How to identify unique user?. There are some answers that say that browser fingerprinting could be a way that Urban Dictionary prevents multiple votes. How would I accomplish this?
EDIT: One thing I certainly can't have in this application is user login. It defeats the purpose of the app.
I'm going to assume browser fingerprinting is reading the user agent string, which is not reliable as the user agent string can be changed in most browsers these days.
If you're wanting to uniquely identify a user, then only allow voting by logged in users, and if it's targeting to a campus only then all students will have an email address, i.e. first.last#schoolname.sch.uk or whatever your domain is.
Individual techniques may not be powerful enough, but combined, they could be very useful.
For example, you could say:
if IP is the same AND browser is the same AND operating system is the same
OR
cookies are present
Then disallow voting. Obviously, There are many more techniques that could be used in conjunction with this (such as browser fingerprinting).
Another option would be to simply require users to be logged in to vote, and ensure that each has a distinct email address.
I would like to make a voting system for my site. I need to check whether a user has voted already. Do I need to store the IP of the user or do I need to store a cookie in the users computer, then make validation if the IP is already used for voting or a cookie is already stored to the user's computer.
Neither of those will give you a flawless script because the user can still clear the cookies or browser a proxy to revote. However I would use both cookies and ip-adress in case the user have a dynamic ip adress or clearing the cookies.
I would suggest do both, as an IP can change and a cookie can be deleted.
Also if you want more accuracy, you can use Flash's LocalSharedObjects also known as FlashCookies to store whether a person has already voted or not. Much less people could/would delete these on regular basis.
i think the best way is have a user registration system to store user information like polling and etc.then you can easily check that user voted already or no ? this way is more secure than others.but for other option that you can consider,you can store user's mac adress.the mac adress is better that ip and cookie.but storing all information help you to have a good vote system.
What is the best way for storing users IDs or usernames so they will not have to login every time?
I want to forward user to the members page if the stored ID or username is compared with the one stored in database.
Is is safe to do it using cookies and how can I do that?
Don't store their username or password in a cookie. Always assume that everyone on the internet can see every cookie on a person's computer. What you should do instead is save the session_id and the IP address they accessed from to your MySQL table, then save the session_id to a cookie. Most browsers will clear session variables when you close the window, but they will not clear cookies. Therefore you first check the session (are they currently logged in), and if they're not logged in then you check the cookie (were the logged in before, and more importantly- was it from this IP address?)
Of course if they have a session_id but they're not at the proper IP address, make them log in. They could just have an ISP with dynamic IPs, or they could have been listening to network traffic and they're trying to get into the admin user without a password.
This feature should be optional to let people log in from internet-cafe and such, not leaving their data open to everyone.
Yes. a cookie is the only possible way to mark a browser.
You have to store some uniqie and unpredictable value there. Generate some hash out of user's data, store it in the database along with other user data and set it as a cookie
The safest way is to require a valid SSL certificate from the browser, and validate the user-agents certificate server sided. However, in any browser I've seen installing such certificates is a big enough pain & hurdle for users that it's probably not suited for a public website. It can however sometimes be seen in intranets.
I just wrote this solution for anyone else who is interested.
http://rabbie.id.au/my-elegant-remember-me-solution-using-php-mysql-and-cookies/
With my sites, I use a custom written Session class. This stores a sess_id and sess_hash in a cookie, which is unique for the current user. An IP address is also stored in the database, and checked against the current IP to verify it is the same computer, but that is not the main authentication mechanism. Data is then stored, serialised and base64'd in the database. I would advise against using PHP Sessions, because they can be accessed by any user with the ID. Someone posting a link to something with the PHPSESSID in it, can, for example, let them log into their account.