How to ensure users can't sign up for multiple accounts?

Question

I'm working on a web app right now which users will normally have to pay to use, but I want to also offer a short demo period (haven't settled on how long yet, but somewhere between 1 day and 1 week).

In order to prevent them from repeatedly just using this demo, I need some way of identifying them that they can't trivially get more of (IE, it's trivial to get more email addresses through gmail. If you own your own domain, you can have a catchall email address at the domain.)

Possibilities I've considered are:

• Phone Number
• IP Address
• Credit Card Number

The pros and cons I've thought of:

Phone Number

• Pro: I don't know of an easy way to just get more of these. You'd need to buy more numbers, but the numbers cost more than my service do so I can't imagine anyone actually doing this.
• Possible Con: Would asking for this disturb users? Will I end up with fewer signups because they feel like this is too private information?

IP Address

• Pro: I can utilize this without even letting the user know.
• Pro: There's no way they'll forget it.
• Pro: Similar to phone numbers, getting more IP Addresses costs more than my service does.
• Con: Multiple users sharing a single internet connection can't sign up.
• Con: Users can't log in if they aren't at home.
• Con: Cell users can't sign up/log in if they're on cellular internet.

Credit Card Number

• Pro: I need to get this sooner or later since I'm going to be charging them for this service when the trial period is over.
• Pro: Similar to the above two, getting more credit cards isn't particularly easy.
• Possible Con: Asking for this would definitely disturb some users, since it would disturb me. When I'm signing up, I have no idea if this is a legitimately useful website. For all I know, it's just a phishing attempt where they just steal credit cards.

So I want to know - what is the best way of letting people log into my website? Since I have the trial period at the start, I want to ensure that there's a small, finite amount of logins they could possibly have (ideally, they can only have a single login).

Has anyone ever had to do this? Does anyone know of other ways I could do this?

Oh, one other thing: obviously I want to make sure that all possible customers can sign up. Besides just being disturbing to ask for, Social Security Numbers wouldn't work since those are mostly US only. My potential customers are anyone with an internet connection and a means of paying.

Answer 1

This is a tough issue that I'm not sure anyone has really solved yet, but here are my thoughts for your 3 solutions.

Phone number

Yes this might be a bit personal or creepy but I feel like it's becoming less so since people are actually using their phones less and less. You'll want to be clear that you're not selling their phone number to a marketing agency or they won't be receiving any solicitations. Also for this to be effective, you will have to verify that this is in fact their phone number meaning a text message confirm or something to that effect to prevent people from putting in some random phone numbers they don't own.

IP Address

The cons for this are pretty big issues so I wouldn't recommend this. What I might recommend for this is to use the IP address + private email domains to alert you to suspicions of a multiple accounts in which you can investigate. Obviously working with the threshold of this would be useful.

Credit Card number

CC number is complicated... you generally do NOT want to be storing CC numbers since it creates a huge liability for the company. As such you normally use some sort of service which provides a token, and suddenly thing become very complicated. Unless you need to set this up anyways for payment of your service, this can be a lot of work. That being said, CC is not a bad idea if you really want to only have people who are a bit more committed to your product to actually go and give it a try. Also to increase comfort levels, you can potentially not ask the for their CCV (i'm not sure if this will screw up validating the authenticity of the numbers).

I honestly don't feel that having just email will cause absurd amount of freeloaders to continuously use trials. Also someone who's doing that will most likely never buy your service anyways (or is not the kind of customer you want), however without knowing what your service is exactly it's hard to say. Out of the 3 you have here I probably recommend phone number.

Answer 2

If you are providing a valuable service/product there will always be people trying to "cheat" the system and get in. Providing a free trial period is an industry norm and over time users may sign up for more than one trial but that will get old fast.

I would worry less about ensuring authentic users and focus more on providing that great content. If you're doing awesome work then most of your users will appreciate and pay for it.

Another thought would be to limit the amount of content someone can consume even on a trial. Maybe they get 50% of the content or 80%, or maybe you can find some other value add to give paying users.

Answer 3

Consider using federated user authentication from some social network like Facebook or Twitter. You can suggest to your user that your use of social credentials is a service to them, saving them the hassle of remembering and maintaining a different username/password set for your site. Should they change their password on the social network, your site would automatically respond only to the new password. Look into OAuth as a method for accomplishing this.

As a side effect of using a social network as your security user-base, you get the freeloader protection you are looking for. Most people only have one account on each social network. The social networks already use most of the techniques you mentioned above to avoid their own freeloader issues. You will still need to track which users have already received a free week, but you can offload the freeloader detection issues to a social network for free.

As an additional side benefit, you can also get your users to advertise for you. i.e. "Let us post a comment about your using our software on your facebook wall, and we'll give you a week of free use."

Edit to Reply to Comments

Some oAuth hosts, such as Microsoft Live Accounts have not advertising outlet and have a more professional, business-like feel than the consumer social networks. Admittedly, getting multiple Live Accounts however is pretty trivial, so there is a trade off.
I'm not sure how trivia getting a second FaceBook account is. I think they ask for and test a phone number during the registration process.

I've got another idea that might help you, but this answer has already gotten very long, so I'm going to start another answer with the new idea...

Answer 4

Honestly, a valuable product. You are not the first one to offer trials.

You would scare more potential customers off than you would save through fraud-detection processes. If your customers like what you do, they will pay for it. If they use your software on a regular basis and still create a new account each time, they can't or don't want to afford it.

Instead of encapsulation you could try to bring them in. E.g. by providing special offers for students, free usage for testing, translating or opinion leaders, ...

Answer 5

Right now, you should not be solving this problem. Not only is it a problem you do not have, but solving it too early may mean you will never have the problem. Lemme splain.

Lemme sum up. The more you try to reduce the % of fraud, the more it costs to prevent each instance of fraud. This cost is in the time you spend directly preventing fraud, the customers lost as false positives, and the extra effort legit customers must go through for your fraud protection. At a certain point, it makes more sense to instead allow some fraud, reduce the cost of fraud, and try to convert the fraudsters into legit users.

This is a brand new app and you have no customers. You need users and you need them to find your service so valuable they want to pay for it. You need to be focusing on...

• Getting the word out
• Features that people want
• Features that people want to pay for
• Easy sign up process
• Easy upgrade/payment process

All the extra checks you proposed to prevent people from abusing demo accounts (IP address, text messages, credit card imprint) are the opposite. Your users don't want those features and they make log in harder. They reduce the number of new users trying out your thing in a period when you need as many new users as you can get. I don't have numbers, but it would make an interesting A/B test!

This is what I like to call the "what happens when I have a million customers" problem. Solve it when you have it. Until then, focus on having that problem. Because it's a good problem. It means you have tons of potential customers and are so useful that people want to cheat to use your product.

You're trying to solve the problem of how you uniquely identify a single person on the Internet without making the account creation process too involved or invasive. This is a problem nobody has solved and it's one the Internet is incredibly resistant to (I don't mean just the people, I mean the design). Unless you have a walled garden (Google Play, iTunes Store, Steam), the industry and customers have settled on email validation as a compromise. Everything else is either too much work (credit card, SMS validation), has too many false positives (unique IP address), or excludes too many users (credit card, SMS validation).

Let's look at credit cards. First problem: not everyone has one! And I don't mean just 14 year olds, 30% of people in the US do not have a credit card. Second problem: not everyone wants to give it out just to get a free account just to find out if they want to pay for it. Third problem: it complicates the account creation process: credit card number, expiration date, CVV, address, real name... this on top of the usual email address, password, and email validation. Fourth problem: 35% of people in the US have three or more cards and can easily circumvent your protection.

When you have a problem that can't be solved, it's time to think about the problem. "Ensure Users Can't Sign Up For Multiple Accounts"... how does solving that aid your business? They're "stealing" something from you, right? That must be bad? Unless those demo accounts are costing you a lot of computing, storage or customer support, they're not stealing anything. What do you really want? You really want those users who are abusing the demo accounts to pay for an account. "Entice users to pay for an account rather than make multiple demo accounts". Bingo. That's the problem to solve.

These people like your product so much that they're willing to go through the effort to circumvent the system to continue using it for free. These aren't criminals to be punished, they're enthusiast cheap-skates. There's several solutions to the problem...

• Increase the effort to make a second demo account.
• Decrease the value of a demo account.
• Increase the value of a paid account.

Make it not worth the effort to cheat the system by working at both ends. If the user gets a lot for $5/month they'll be less likely to take the effort to create multiple email accounts to keep renewing demos.

• If they're a low percentage of your users, ignore them.

They don't want to pay? Fine. Don't try to get blood from a stone. Just make sure you're not spending much resources on those demo accounts.

• Make the free users valuable to the system.

This is exemplified by the freemium model where a very small percentage of the users pay most of the money. Everyone else plays for free. Free users "pay" by providing content for the paying users. This works best in social applications and multiplayer games. TechCrunch has a good break down.

• Make the transition from free to paid subtle.

Instead of cutting the user off and demanding money at an arbitrary time or feature limit, coax the user deeper and deeper into the system and provide them with soft limits they can eliminate with money. For example, in Rift, a Warcraft-like MMO, instead of having a level limit free users have limited inventory and can't use the Auction House. Freshbooks, an invoicing site, limits free customers to only three clients. These limits allow the user to get invested and decide when they're read to eliminate them.

The UX hump is getting the user's payment information. Once it's in your system, they can buy things with just a few clicks and the barriers to spending money have fallen. Spending just $5 in Rift unlocks a lot of small but important features, like the Auction House. In Freshbooks, if I have a lot of clients I'm making money so paying for an invoicing system seems natural.

Answer 6

I think that there's no real solution to your problem. That might be hard to hear, but there's no way to gain any security without sacrificing your user experience. Instead, we just need to pick the "least-worst" choice.

Using a phone number or credit card number for anything is grounds for an immediate bounce from most users. If you looked at a study, you would balk at the sheer number of users who don't give their phone number out (and rightfully so; there's nothing like getting hourly text message spams from random numbers in 3rd world countries.)

Using an IP address is completely unfeasable; you won't gain any security even after sacrificing the user experience. Any idiot can change their own IP address in under a minute, without even talking to their ISP. And the technically savvy can use proxies and VPNs.

I would recommend instead that you limit the trial in some way, while still showcasing the full version's benefits. Lots of websites and applications do this. There are Stack Exchange ripoffs that only allow you to read the first paragraph of every answer, there are lots of video processing programs that only allow you to process the first 60 seconds of the video, file download sites only let you download 1 file every 30 minutes, etc. Even this method would annoy your users, but much less so than the other options.

Answer 7

We use phone verification that limits duplicate accounts. We ask them to text the number they see on the screen.

Note, we don't ask them right away but we do limit pro features that require verification. We noticed good conversion rate of users and also less duplicate accounts (since most users have one cell number :)

One funny thing we noticed is that the verification went down when we put in privacy sentence stating that we don't sell or share your number (blah blah). Once we removed the text and simply said for more info click here, it was restored. This tell us that users get spooked when they see such text.

Answer 8

The best protection will probably be a combination of methods.

For a first line of defense, use cookies (and/or some sort of supercookie). That will protect against people who use their own device and don't want the hassle of reloading their browser. Basically, once someone has logged into the service on a particular browser, don't allow them to create a new account.

IP address isn't a good automated restriction. As others have noted some users might get a new address each time they connect. On the other hand, there might legitimately be multiple users behind a proxy or NAT. It is something you should log and monitor for abuse, however.

For ".edu" domains, you probably can assume that one user belongs to one address.

For Google/Yahoo/Hotmail, perhaps there's some way to insist that the account has been open already for a certain amount of time, or that it is published as the user's contact e-mail in some public place.

For other domains, allow only a certain number of trial accounts at a time per domain.

Answer 9

The ideal is to make the "means of identification" be the information stored in the account itself. Easy example, if your app has significant social functions, then a free user isn't going to want to have to go through a process of re-friending all their friends using their new account every week, losing the ability to see/edit stuff generated by their previous account, and so on. They'll either pay to keep their account or they'll leave.

Of course you can't bolt social features onto your real service afterwards just to dissuade free users, because they simply avoid the social features. But you should think about everything your service can provide that gives paying users a benefit from continuity.

Another less social example, World of Warcraft. Ignoring social functions, the benefit of continuity is your saved characters. Don't pay at the end of your trial, you'd have to start from scratch in your new account. Problem mostly solved. At least, until you need 2-factor authentication anyway to secure the user's finances!

If your app is just an information feed, and there's no benefit to users in storing any information in it all (not even favourites, subscriptions, or personalised settings), then you have no leverage here.

One thing to consider is to have a trial of the trial, in which you just allow free users to create more trial accounts. Yes, they've got one over on you, clever old them. Check your records to see whether you see serial account creation one a week from the same IP addresses (or even from the same cookies)[*]. If you find that 95% of your users are repeatedly creating free accounts, change the terms of the free trial then. If you find that 1% of your users are repeatedly creating free accounts, OK, let them. Insignificant cost of doing business.

Anything you do (that users know about) will put off some users from the free trial. Just the fact you have to sign up will put off some people who would otherwise have had a look around, but I assume you're set on that. So don't start putting them off further, until you know what you gain from it. How many repeat free users are there for you to force to either convert or leave? It might be a non-problem, at least to start with.

[*] Of course, as with all user logs, ensure that you're handling data in line with whatever laws and regulations apply to you.

Answer 10

The way Netflix seem to do it is simply asking for your phone number on sign-up, and then running a script at a certain time every day (unsure which time it actually is) to cross-check accounts. If an account seems to be a duplicate of another a flag is raised on their system and a human manually checks it. If they determine that the account is a duplicate, they place the account on hold.

This is a reliable method but does mean users could potentially be scared away by asking for a phone number.

If you're ever considering a computer program to go with your website, you could do it by taking a serial number of something (such as the hard drive); if the serial number matches another, you know you've got a duplicate and you can place the account on hold.

Answer 11

My answer isn't a straight answer for your question, But could solve your problem.

Lets consider the problem in a different way. You provide access to full capacity of a system but only for a period of time. It's similar to giving a very delicious food to a hungry person for two weeks. Suddenly after that two weeks you say: OK, there is no food. neither delicious or normal food. And you leave him hunger. No matter what he has money or not, he will try to acquire that food again and if it be possible to gain it for free, why should pay for it? It's the start of a continues war and for sure you could not be the absolute winner. None of your mentioned options could save you.

I offer you a better way.

Similar to Dropbox, Google, Microsoft and act. You can provide a basic service for free and for life time (Not a certain period of time) to your users. and if they want more capabilities you offer them to upgrade their account to premium. In this way you have a list of real users that can't cheat you at all but are happy with your premium or free food.