I am trying to block a user's PC permanently from using my website. Until now what I did is banning the IP address and setting a cookie which will automatically ban the IP address, if it changes. However some tricky users are nevertheless deleting the cookie and resetting their router, so they can write harmful comments on my website. Is there any other way of banning a user, other than with IP ban and cookies?
I read this question: https://stackoverflow.com/questions/3159160/how-to-definitively-ban-a-user-from-my-website-or-almost but it is not what I am looking for.
You could use evercookie, which is a lot harder to get rid of, but identifying individual PCs with certainty is not really possible, and that's a very good thing because it would be the end of privacy.
No, there isn't. Any method you put in place can be worked around. You can identify a previous user by:
IP address - which changes automatically, and can be changed manually with something like Tor
Cookie - which can be deleted easily, as you said above
Login details - which would require you to block commenting for non-registered users, and blocked users could register with new details anyway. You could require pre-approving accounts.
Note that this is a very difficult thing to do. Even the biggest sites struggle with this - StackOverflow included. Ultimately, it's a trade-off between making it easy for good users and difficult for unwanted users - you, as the site owner, has to decide where the optimal experience lies.
One other option is to pay for comments moderation with something like Mechanical Turk or Freelancer.com.
Obviously, 100% authentication is impossible, aside from anything else someone could just go to an internet cafe or use a friends computer. But you could try making a few changes to your site if you have a big problem with this:
You could make users sign up to post, and even go so far as have new users comments not show up until they are approved, either by yourself or other trusted users.
You could try hellbanning, which means you flag a user as hellbanned, they can still log in and post etc. but their comments only show up for them no one else.
You could try automatically scanning posts for certain offensive terms (or whatever is relevant in this case) and then automatically delete or hold them until approved manually.
Spam intentional or otherwise is a tricky problem and anyone who completely solves it will likely become very rich.
One idea, often seen in phpBB like systems, is a role approach. You assign different abilities to guest or visitor users, from registered users, from trusted registered users. A basic scheme for it would be like this.
Guest
Requires CAPTCHA
Requires moderator approval
Registered users
Requires moderator approval
Trusted Registered Users
Can freely post comments
Your CMS affects the way this would be set up. The simplest (assuming it doesn't already support this) would be storing a few extra bits in the database indicating the role and checking that when posting.
Just get bastard's region with GEOIP functions and set some restriction for this region (for example premoderation/captcha/etc).
Also You can use "protection" from another services, which is more powerful. For example: connect Your site accounts with facebook acc and allow to comment only after getting facebook_id. It's pretty easy to ban user by facebook_id and hard+slow for bastard to create accounts for every Your ban ;)
Related
I have a security problem with a user who we've banned over and over. They continuously re-register to the site and use proxies to get around the IP Ban.
We use Phpmyadmin and sql databases for the user table and already have everyone that registers automatically set to "0" which means they are registered by not an admin.
I was wondering if there is a way to dynamically set this person's user level when they register a new screen name - because they use the same email address every time. We have most of the site protected so that they are required to login and have a set permission level to see things. So if possible, when they register another login name it automatically sets that specific user ONLY to whatever number I designate and identifies it by the email address they are entering.
Anyway to do that, or anyone have any better ideas?
One idea is to do what craigslist does to people. It is called ghosting. It is a good thing to google. Basically a user thinks they are posting, but no one else ever sees their stuff. When they go to the listing, wow it is there. When they go to the category, it is there.
I realize that CL is quite different than say a chat forum. And the user would be wondering why no one took offense to them calling someone a fatso, live. But for non-interactive, non-realtime environments, they would have no idea they are ghosted. Well, I shouldn't say that. Maybe their friend tells them they can't see it.
If they can pull off the proxy thing, creating a new email address would be a piece of cake. Don't tip them off to the ghosting, let them continue to do their thing, isolate, and ignore (if it is even possible).
good luck
Is it at all possible to retrieve user information that can be used as a unique identifier between domains?
As a quick example of what I am trying to do (not exactly this but the theory is the same) say you had a main website at UK-news.com. You also had three other sites - England-news.com, Scotland-news.com and Wales-news.com, all hosted on the same server.
All 4 sites will share the same database and each would just pull the relevant info out of it. If a user becomes a member of one of the sites, they will also be given the option to become a member of any or all of the others. If a user signs-in to one of the sites he is a member of, and then goes to another how can I get that site to recognise him from the one he signed-in on so he is automatically logged in?
My theory was to store some user information (IP, USER_AGENT, browser, screen resolution, computer name, OS) in the database via PhP and then check against all of those as the user moves between sites. however, even checking against all of these, I am sure it will be possible for two different people to have exactly the same details.
Are there any truly unique identifiers that will guarantee that a person is recognised between domains?
Thanks
Steve
I dont know what is the configuration of your server, but. If one site is under something.domain.com, and another something2.domain.com, and the domains England-news.com and Scotland-news.com are only links to those sites, you can use url overwrite, and cookies sharing over subdomains option in php. But I think that this is not the case. So...
There is no 100% sure user recognition. And this is great, imagine what will happen if there would be. You can NEVER trust user data, and headers data, while sometime you can not even trust $_SERVER array. So there is no option to recognize the same user over few domains.
1) The only answer that is useful is to suggest you to share the user mysql table, and make all the logins and passwords same for each site. IN that case someone can login into another site using the same data.
2) You can try to rely on second hand services like google acount or facebook acount to verify users on your site. But you must remember that there are people without gmail and facebook, and availability of such a site will be reduced.
3) Use a serrvice like forever cookie, or something like that, but this is also not 100% sure. It is using html5 storage, flash objects, and everything to verify if this is the same user. But as far as I know, everything can be ommited, if you are patient enough.
Best regards!
I've been asked to leave passwords and user names aside since most of the site visitors are stop-buy-come-back-several-months-later-kind of visitors, and the motivation was somewhat along the lines "they would forget there passwords any way and have to request new ones".
I suspect there is no realistic way for me to do this thinking IP:s probably change and browsers get updated, cookies are cleared and so forth.
Or do I have any options?
(not that I'm looking for code but rather concepts and pseudo but the language in the project is php/js coupled with an apache server)
Use OpenID.
Let Facebook, Google, Wordpress, or even Stack Exchange handle the authentication for you, and people wont have to remember another password.
Alternatively:
Many users understand the "forgot my password; check my email" routine by now, so why not just short-cut it by having them input their email and send them a login url with a randomly generated token to log in with.
Once they're logged in, keep them logged in for as long as you deem secure.
We do the following in our e-commerce solution:
We use email as a unique identifier.
When a customer makes a purchase using the same email, the order will be attached to their existing user. You don't however get any address details or stuff like that, but have to enter it manually.
The customer will receive an email with a generated password if it is a first time buy. If it is a second time buy, they will just be instructed to log in. This can however be combined with a url and a login token. Likewise for logging into the site, you could just have them enter an email to receieve a login url token.
Combine this with a long living cookie and/or the browsers datastorage to remember the customers details (address and stuff like that).
Another option would be to have them entering something about themselves that they would always know, but others wouldn't. However it is hard to have an internationally workable solution for this.
You could use so-called supercookies, which is offline storage on the client side. Either through html5 offline storage, or plugin like flash to restore deleted cookies. Although, these cookies is likely to be banned at some point, since they're mostly hidden for the user, and very hard to get rid of. (Not recommending this approach, just saying it's possible)
Authentication credentials break down to three options;
Something you know - passwords
Something you have - physical keys, cards
Something you are - iris, retinal and other biometrics
The best you can do is use cookies I think. Or...I guess you could have them download a file, and upload that file as their access credential - same idea as a cookie but unlikely to be deleted. You would have to think carefully about what to put into the file however - their user id isn't enough, as it would be easily hacked. A random long string would do, one that is saved into the database on their account. Nothing that can be predicted, and nothing that can be used to guess a different account's credential.
A couple of options come to mind:
Use a persistent cookie, but only do this in conjunction with SSL (so it simply can't be sniffed off the wire)
Another option is OpenID like you use here - therefore vistors can use an account they use often to log into your site.
It seems to me that your only option is giving them a forever cookie and hoping it doesn't get purged between visits.
You can read about them here.
I am trying to figure out a way to stop account sharing on a site that requires a login. To solve this I would want to base it on an individuals machine or ip. I know I could base this on a cookies, which could possible be deleted or an ip which could possibly be dynamic. Is there something that I am not thinking of? As of now I am thinking I would have to base it on a cookie that can only be rewritten so often with an ip.
Is this the only way to handle it or can someone point me in the right direction.
I would spend time looking into a system detecting account sharing instead of preventing. Not only do you not harm your average user logging in on a few locations, but it's also less time consuming and let's you be able to take more accurate action.
You can use your login / visit log for detection. More then one login in 5 minutes with distinct ip(s), the ip(s) used to login are from broad ISP's etc. etc.
Well, don't hobble your site without considering the consequences. The same person could be logging in from work, school, ips can change because of dynamic addressing, etc...
You could force each id to be logged in from a unique location (e.g. record each login in a table where certain fields comprise a unique key, and look for insertion exceptions). A login from a new location while the old location has been recently active could be set either to (a) fail at the new location, or (b) cause a failure at the old location, (c) inform the alternate location, (d) log somewhere. Also, providing a table of where you've logged in from, shown to the user in fine print, together with a blurb on the policy might aid in compliance among "honest" people.
What is the best way to allow a member to delete their account if they wish to not be a member of our community? Should I simply have them click a delete button on the site? What other measures should I use?
There are a fair few good answers already, but I will add my bit here to be sure that the couple of points I want to raise are covered off (or opened to discussion).
User Actions Required to Terminate Account
As has been pointed out by other respondents, you want to make the process of terminating an account as easy, and yet as clear/safe as possible. Having a button in the Account/Profile Settings section of your site is the best place to have this function (as it tends to be there for almost all sites). And, when the user elects to terminate an account, be sure to have a confirmation message before completing that action (nothing worse than "accidentally" killing an account).
If you are interested in user retention, having an optional quick exit survey can give you a good insight into the reason why some users may be terminating their accounts, so incorporating this into the confirmation action may be useful.
Site Actions after Termination
A practice I have seen used in a few instances (and I quite like), is for an email to be generated to the User's email account when they terminate a user account.
It allows you to try and "save" the user, if retention is an issue, again, you can offer them a way of giving feedback regarding the site, and generally let them know that their contribution will be missed.
If you use the suggestion of flagging an account as "Inactive" (but retaining their data), you can advise them, in that email, the steps they can go through should they decide to return and want their old account back.
Handling of User Data after Termination
There are a few solutions here, dependent on the kind of site you are running, how much of the content is user-generated, the terms of your user agreement, etc.
General Recommendation
The simplest, easiest, and most mistake-friendly way to handle a user termination is to have a field in the user table which allows you to simply mark an account as Active/Inactive, and, when the user terminates their account, switch that to Inactive.
This allows you to recover the account, should they change their mind, run statistics on your retention rates, etc.
Sites with alot of User-Generated Content
Simply deleting a user's account when they leave can cause you problems - links from comments/articles/other content which would normally be associated with a user will break. In these instances, and so long as the User Agreement allows for it, I would recommend that you flag their account as "Terminated"/"Inactive", so that some aspects of the account can be switched off, but still retain the details required to make the rest of the site operate OK.
Sites with User-Generated, but Private, Content
In this instance, if you are planning to delete the user's details from your databases/files, you will also have to have code which will remove anything associated with that account from wherever it may be - for instance, deleting any pictures that user uploaded, any comments, etc. they entered, etc. Anything which JOINs with the user table will need to be systematically erased.
Generally, sites make you jump through hurdles to close an account. It is frustrating for the end user.
What I would have, is a Close Account button somewhere, which takes you to a page that asks you to (optionally) leave a comment why you are closing the account. This will be helpful for you, so you know why people are feeling it necessary to close their account.
Then send them an email with a unique string, that they must click to close their account.
This prevents people who may have left their session logged in from having their account closed :).
For the technical side of things, you may want to simply DELETE in MySQL from all tables their relevant data, and clean up any file based data (such as uploaded images, user specific caches etc).
First of all, you should know if you want to keep their data (for some time at least) for if they want to recover the information.
If the anser is no (much simpler). The just add a php script that when a button is pressed (in their profile) deletes the mysql (or what ever) database...
EDIT:
Measures: They should go their accounts, go to configure settings (or similar) and then delete account, they should definitely have ONE warning page
This question is very broad and is more of a general business question (potentially) rather than programming specific question. Your options are limited only by your brain power. Really, you don't have to let people leave your community at all (probably a bad idea). What services does the user receive from being a member of your community? When they leave do these all cease? How does the user's information affect you? Could you still use it even after they have left?
These are questions that only you (and your manager) can answer. I agree that it is generally pretty frustrating to cancel some accounts. Many sites don't even give you the ability to cancel at all, but they may have a mailing exclusions list or some such.
My suggestion would be to have a flag for users in the DB. When a user quits, set the flag. Once you know that user is flagged, you can manipulate any data with respect to them in any way you see fit. Want to run a report on only active users? No problem! All inactive users are flagged. You keep their data for however long and use it as you wish, and if it was a mistake and they never wanted to leave, you take 5 seconds out of your busy day to unflag them.