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.
Related
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.
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.
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 was given the task of creating a registration page for an upcoming church retreat. Design-wise, it will consist of fields for name, sex, phone number, email, and grade. We need a way for the end user to put their credit/debit card info and have it charge them for the retreat.
After some searching I found that Braintree offers a good service (37 signals likes them). The down side is that I have no clue on how to implement this sort of system into my site. So we are going to apply for a merchant account using their service. I also found documentation on how to implement it with PHP.
My question is, do I have to do anything else? I've always heard of https but I don't know if that's something I should implement. What security measures should I put in place? Should credit card numbers be stored in a database as plain text or encrypted? Has anyone used Braintree and can let me know what to expect after getting a merchant account?
Edit: I was looking through the PHP documentation code and was lost at this:
Braintree_Configuration::environment('sandbox');
Braintree_Configuration::merchantId('your_merchant_id');
Braintree_Configuration::publicKey('your_public_key');
Braintree_Configuration::privateKey('your_private_key');
I'm guessing the environment is set to sandbox for testing but is a merchantId provided to you after you make an account? Also, I have no idea what a public or private key is.
Hire someone with ecommerce experience to do this. If you don't know what https is then you shouldn't be handling sensitive information like credit card numbers or processing payments. The implications of a poor implementation are huge and lives can literally be ruined from it.
Do not store the credit card information in a database. This is a bad idea for numerous reasons listed many places on the Interwebs. PCI Compliance being the most commonly cited one. It is a really, really, really bad idea.
Https, by the way, is the secure version of the http protocol and allows for http traffic to be encrypted between clients (usually a browser and server but not always). It is implemented by the installation of an SSL certificate.
Your best bet is to use a merchant account and a payment gateway service like Authorize.Net's SIM API which handles the order form for you. That way you hand the handling of sensitive data to them.
You may want to read Merchant Accounts 101 and Ecommerce 101 before proceeding. Disclaimer, I wrote those articles.
You should not and cannot store any credit card information in your database. Mostly any payments service like Braintree will handle entering sensitive data, HTTPS and all other things. All you need to do is to give correct request to payment gateway and process answer.
A second reason to consider a site such as Google Checkout, Amazon, or Paypal is because the big merchants charge a set fee by the month plus transaction fee. If this is a one-time deal, the registration fees aren't that significant, or you don't plan to use it year-round, it's likely not worth going this route, even with a professional doing the work. I do a lot of work with quite a few smaller non-profits and the only way they can afford to do merchant accounts is via grouping of resources...but that brings up several tricky accounting questions.
Even easier than doing all the work yourself, consider a simple online registration site such as Active.com (or many multiples of others out there--I'd bet there's even one specifically for church groups) Their business is online event registration, and they do this for hundreds of smaller parks and rec type registrations, so they certainly would have the capability to do something like this. Trust me, having built several registration systems, there's nothing worse than the first bug popping up that makes 50 registrants show up unregistered or charging someone 4 times.
Unless there's some good reason for you to roll your own, use a third-party service to handle registrations for you. Among the others mentioned, some of my friends who put on shows and improptu classes use eventbrite.com and brownpapertickets.com
Both will tack on a small service fee
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.