I have been hired to work on an existing site built in Laravel, which is a platform for real estate agents.
There are two account types - the cheap "individual agent" account and the more expensive "enterprise" account which is meant to be used by real estate agencies.
Everything is generally working well, however it has come to my client's attention that some real estate agencies are exploiting the system by having one person sign up for an individual account and then handing out the username/password to all their employees, sometimes 30 or 40 of them.
This is cheating because the "enterprise" account type exists specifically for this purpose.
My question - is it possible to limit the number of simultaneous logins to the same account? For example, I would like to set the maximum number of concurrent sessions for an individual-type account to 2. Then, if a 3rd login to the same account is attempted, it is declined by the website with an appropriate message.
I've been looking for solutions online, however they are either based on IP checks or some convoluted Apache/nginx config which I don't think applies to this case. Note that the users may or may not be logging in from the same IP, so any IP-based checks are useless in this case.
I am primarily looking for a solution native to PHP/Laravel, if not possible then please feel free to suggest any alternatives.
Did you try to extend the sendLoginResponse method inside the LoginController? Do you have different models for your users? or are you using only the User Model with attributes? You could do something similar to this over here: https://laracasts.com/discuss/channels/laravel/restricting-user-to-one-session-laravel-53
I wanted to write a comment, not an answer but I'm still not able to. I'll help if you give me more information.
Related
The example scenario, to provide context here, is an app (iPhone, Android) that pays the user (using Paypal) to do certain tasks. It currently operates under the assumption every user behaves and has a single account.
UPDATE - To clarify how these tasks work. Each user can do a task once, but tasks can be performed by multiple users. This is why I need to make sure a user really is only doing a task one time.
Example Task
Your testing product will arrive in the mail shortly. Please use it for a week and then supply your feedback. Upon completion of your feedback, we will give you $2.50.
The issue comes up when a user makes multiple accounts, and then attempts to pay out on these multiple accounts to earn a lot of money quickly. So as a result, you can see this app needs some way to detect that a user is taking advantage it.
Right now our tools for identification are as follows:
Weak Identifiers - Things that are subject to change, and are easily faked.
First Name
Last Name
IP Address
Email
Strong Identifiers - Things that are more difficult to change or fake, but still possible to do so.
IMEI (Android only)
Paypal Account (only good after first payout, user could mass payout before it mattered)
Advertiser Id
Unique Device Id
Push Notification Token (for app notifications)
Based on these identifiers, and being completely ignorant of the processes used to link accounts together with them I am curious if anyone has advice for doing this type of matching. Also knowing that many of these things can be forged by a devoted person.
For emails, there are ways to fuzzy match but they are quite slow. I have ways of getting some of this done already but I want a best practices and experiences from others before I move further down this rabbit hole.
I am aware there is no 100% surefire way to detect duplicates, but all I want to do is flag the possible duplicates for review and give an administrator the power to review the accounts and either merge or disable them.
UPDATE - Paypal
Paypal is a good source, but it only works in very specific cases. To check for a verified account and get the account id back you must have the exact same first and last name on the account provided by the user. This is not always the case. Jonathan could be Jon, Christopher could be Chris, etc. Also, multiple emails can be tied to the same account. So a couple could be sharing and it makes little sense to force them to enter in someone else's name in order to submit their payment.
As for the payout return, this can be avoided by paying out all at once on many accounts. Thus there is nothing to detect until after the payment has already been made. I am not aware of a good way to cancel payments via Paypal so if there is a suggestion there I am all ears.
I wanted to follow up on this and mention that while I didn't get a solution for this particular item I did get an answer.
Bank accounts/credit cards (which translate to paypal accounts in this case) are probably your best bet at limiting multi-accounting. You will not cover 100% of the cases but its better than anything else. The second best are phone numbers. Other than that its a endless race between you and people who spoof device identifiers or reverse engineer your network protocol and bypass the app entirely. - #Vatev
Just to resolve this question, the reality is no matter how hard you try to fingerprint a device there are ways to get around it. The only reliable way is to have a lower level access to the phones, a level of access that Google and Apple do not provide and the only alternatives will get your app rejected for misuse of the service.
The website that I am currently designing has run into a bit of a snag - basically my client has mad it clear that he needs a one person = one account feature, now I'm not the best at analytic's (despite my programming background) so I could really use some suggestions.
We are programming in PHP, and I'm 100% aware that there isn't a solution that would 100% prevent the problem, but I need as close to the 100% as I can get and so far I have tried...
Placing cookies to the users browser. Workaround - Switch browser.
Tracking IP. Workaround - change IP, reset router etc. (Also, more than one user per IP is permitted).
Using analytic's to try and track actions such as Account A being logged out, then a minute later account B logging in from the same IP. (This seemed to be the most effective, but it took a few people to keep it going so I'd like to automate it as much as possible or if possible eliminate the need for manual monitoring.
The problem is that the users of my clients site will be paid depending on different actions and my client has already decided on a $10 minimum withdraw amount, and payments will be handled via PayPal.
So basically multiple account usage could cost my client a lot of money if the site goes live without these features.
I would also like to keep this back-end (possible cron-tab). Just to be clear.
Any help/input/suggestions at all will be massively appreciated.
Tah
PS- I have already checked out this question (Account verification: Only 1 account per person) which is where I got the idea for point 3 from.
The only way to really prevent a person from signing up for multiple accounts would be to ask them for personal information specific to them. I ran into this issue and ended up having to track social security numbers to prevent multiple accounts. Granted, the project I was working on was for a school and the school already had this information. Also, for a new user signing up, it wasn't unusual to them to give this information.
Reading some of the comments, I can say that even if PayPal had a way to track duplicate accounts, it is highly unlikely that you would be granted access to this information, even just to say "yes this is a duplicate" or "no it is not a duplicate".
I really think SSN would be your best bet.
AFAIK iovation uses a set of tracking methods, including Flash cookies and browser fingerprinting to track the users and the devices used. Although budget-wise it might not be your best option, you may consider the techniques themselves.
I'd suggest the business to create incentives for using a single account, which might pay off better than (costly?) fancy tracking software.
What is the best way to implement limits for users in applications like discussion boards, image hostings etc. ?
Let's say we want to set limits for StackOverflow. Anonymous users should be able to post 50 questions per 12h and registered users 100 per 12h.
I thought about creating a database and storing information about IPs/users and their posts. Data would be erased after 12h.
However, such solution can be easily hacked. A single IP shouldn't generate more than 100 questions, but what if one user create several accounts on the same IP? Every account has its own limit, so user could generate unlimited amount of questions.
I would have to limit number of accounts per IP (what with schools/other places with many users and single IP?).
I could write on this topic for months. This is a super hard problem that is not solved with a single silver bullet...if this is a real problem for you, you'll solve it over and over as you move forward.
If there is value in putting large amts of content on your site, as you get to scale, bad guys will discover this and get around your defenses. You'll need to look at what they are doing, adapt and attack the problem different. This is why the GMail spam team still exists. :) Deep pockets, smart gals/guys on that team. If it were "solvable" they would have solved it by now.
Doing something like what you describe above is a great start. I would also invest in instrumentation & push the data off to a platform where you can analyze it after the fact (ex: a Hadoop cluster). This way you can study the livesite traffic to see if you have a problem and, if so, learn about how they are doing it so you can adapt.
Welcome to the Hotel California...where you can check out anytime you like but you can never leave.
Most systems use IP based for non-authenticated users and per account on authenticated users. If people are going to sign up for multiple accounts to circumvent your security then you can either use captcha to remove bots and/or a cooling off period for new accounts before they are allowed to post or even use ip based until the account is at least 24 hours old.
You have already answered your question, if I were you, I would have done following things :
1. Limit number of accounts created per IP
2. Set a DB which maintains records or counter for content created in past 12hours
3. For guest, however could be tricky, you can use IP+cookies to track user's activity, however could be problem if there are many users behind a single proxy. For that, either you have to sacrifice your rules or be strict.
I have seen many website when I am behind proxy, they say you have already visited this site but I never.
This will not fix 100% of your problems and might bring some other in.
Instead of using completely anonymous users and registered users and check IP's, anonymous users should present a working email as verification and a temporary identifier (which will not be publicly shown ofc) each time they post a question.
As they post question it will be saved along with the email and they should receive question activation link in their mailbox.
If they click the link in email, question gets activated and published, so the email servers as a temp identifier instead of client IP.
Ok, it is still possible that some people might use like 10 different email accounts and spam you with questions, and it may even scare some people off.
So i am running into a problem with people making multiple accounts to make there account better with more resource in game.
So my dilemma is, Many users go thru proxys or NATd info so some legimated users would be banned if i only have 1 user per ip.
Is there a way (with Javascript and PHP) to Get a uniq identifier specific to a computer (without Hardware changes, computer hardware change probably would change the identifier).
Any idea or comments would be much appericated
(The following was revived from a response made by Paul, but deleted by another for being out of place.)
I cant change the client to much because its a browser based game so getting the hwid would be possible. But how with JS or PHP.
Adding timers and restrictions to prevent transfers are in place but doesnt stop them entirely there is an option to email for an IP exception. but that is slow an tedious. Im wondering if there is a definitive to generate a specific id or identifier for a specific computer (Not ip based) that would make it so multiple accounts cant be logged in from the same computer but can be logged in from the same ip
As we are talking about a different account, probably on a different IP and client, you cannot easily find out clone accounts.
You can go for two more heuristic and gameplay options
As suggested before (by #dqhendricks), divide your resources and implement your sharing etc in such a way that you can't easily help your other account with every new account. Make finding other accounts in the beginning hard/impossible, make shareable resources a higher level feature etc. Downside is that this changes the gameplay, it doesn't have to be desireable.
You can perform heuristics on behaviour. There can be specific behaviour that is unwanted: only interaction with 1 other account etc. You could tweak some of the variables etc, but you could easily see suspicious behaviour. Make some sort of 'balance' calculation. Most ingame interactions have some sort of balance. Ofcourse, better players may have a good deal because they know more, or the other way around: they make a bad deal to help smaller players. But when one player only gives and never takes, it's "helping" without acutally playing itself: that might mean it's a clone
Everything with ip-adresses or client-information ($_SERVER) etc is worthless in this case as far as I'm concerned..
You could prevent multiple logins on the same Account (username/password).
If the issue is that they make multiple accounts with many different email addresses etc... and new usernames and passwords then you might be able to do it with Cookies for example that use a unique hardware id and then you simple check that not more than one account is active at any one time based on this hwid. if the hardware changes it doesnt matter as it is relative.
To clarify if the HW id for the first login is 1234 then the second login with generate the same hwid. If you check the cookies or your database (doesnt matter where you store it) for the same hwid then you know its already logged in.
If the hardware changes it doesnt matter as they will still both generate the same hwid.
If they use two computers though the haardware id will be different and this will work.
{sharable resources} = {total resources} - MAX(({starting resources} - {spent resources}), 0)
make only non-starting resources sharable, or maybe make sharing resources an ability you don't gain until level x.
Preventing spoofed/duplicate accounts (while ensuring all legitimate accounts work) is a very difficult task -- for reasons laid out by others. In addition to trying to guard against concurrent multiple accounts, one must guard against non-concurrent multiple account usage.
The core issue isn't so much in determining where an account connected from, but being able to trust that a user only has one account -- and to this end the only "real" solution is to use a system which already provides this sort of information, such as a credit card or paypal account ;-) That is, simply prevent someone from creating a new account (although an account can have multiple aliases/profiles, but these can be trivially tracked) unless they can prove "uniqueness".
(Also consider that two people may have two different accounts on the same machine.)
Happy coding.
I run an online game server aswell. To prevent your dilema, either modify the game client to read the MAC Address, and only allow 1 account per computer. Or log the ip's and only allow the resources to be given to that ip twice.
3rd option: Don't allow transfering of materials from the same ip addresses
4th option: Add a timer on the transfering of resources, make them wait 10 minutes of gameplay before they can do anything like getting rid of the items for others to get
I am currently selling time based access passes to an online service at micro payment prices.
After payment the customer gets a set of credentials that is only valid for the purchased period. When the access pass expires the customer has to buy a new set of credentials.
So basically the credentials are one-time(period) use only.
I would like to offer a free-trial of x minutes to this service so potential customers can realise it works fine, possibly increasing total sales.
My question is, how would you stop abusers?
That is, people should only be allowed to try for free once, and if that is not possible at least make them go through a process/test which (as in shareware) is too cumbersome or annoying for them to keep trying it.
Obviously there is always someone who will bypass it. I am looking for a solution for the majority of people who are either not IT savvy, time constrained, or simply too lazy to bother abusing it, instead of simply paying the tiny fee.
I have some approaches in mind but would like to be inspired by other people too.
The service is developed with LAMP.
Put a cookie in their browser. Force a small delay before they can re-use your service, or make them go to the trouble of deleting the cookie. If they block cookies, politely ask them to allow them. You might have more business success if you allow several trials, with a minimum of hassle.
If you look around, everybody who gives out free trials binds them to a credit card - not to charge them, but to verify the user's identity. That's about the only feasible way to prevent abuse I can think of.
Any other idea will depend on the kind of service you are offering. StackExchange for example can offer a 45 day trial without a credit card no problem, simply because the effort to build a SE site is so huge, starting multiple trial periods (and having to configure a new site and build a new community every time) just wouldn't work.
Something similar could be unique login names that you can register during your trial period, and would have to give away if you don't convert it into a pay subscription, things like that. Really depends on the nature of your service.
The users who want to try your product again via a trial are highly convertible users because they already know the value of the product.
The challenge is detecting them and then converting them to paying users.
Detecting can be done using a variety of signals including:
IP
Cookies
Device fingerprints
Credit card or payment information
Email verification and validation
Each individual signal has its challenges eg. IPs can change and are legitimately shared among large audience such as via carrier grade nat.
SMS verification is good in most markets but adds friction and potentially cost for you and your users.
Something like Upollo.ai solves all the hard parts for you so worth a look for people facing these problems in future
I ended up using the smallest possible payment amount for a short time span, but enough to get the user satisfied at very low monetary risk.
In the time past since I asked I actually seriously considered using Flash cookies which very few people know (even that they exist) how to remove.
The other simple (although not-free) is using a SMS confirmation option which binds the user's mobile phone number. As a mobile phone number you just do not throw away like you do with email addresses then this is also a safe limitation method.