What Frob said, plus
(A) what is stopping someone else logging in from another computer
(B) how would you lock only that computer to that account,if the players ip is not an static ipddress
(A) is usually harmless, and it's something users expect to work. It is most irritiating when it doesn't work.
Google does that kind of thing, and it pisses me off every time I go on holiday. Every time I'm trying to read my e-mail in the hotel, they're telling me that I'm doing a suspicious login (sure enough providing the correct credentials on the first attempt is suspicious?!) and prompt me with my recovery question.
Recovery questions ("what is your favorite color?" -- duh... blue? red? green?, yellow? got you...) are the probably most insecure feature you can add to a system. If there is one certain way to break an unbreakable system, add a way to reset passwords using a challenge system for which the average user will have only 5-6 possible answers.
Needless to say that I've entered something like "pöikeghadlökaöweetatgadsdcdvgljlll" to my recovery question, and needless to say that I can't reproduce it myself! Which means that thanks to this overzealous un-security stuff, I'm not getting to legitimately access my mailbox during vacation, and I get to write a hate-mail to customer support every time I come back from holiday.
Google probably doesn't care an awful lot whether or not they piss me off. If you're starting out as indie developer, on the other hand, you probably do care a lot not to annoy your customers.
The only thing you want to prevent is someone (presumably the same person) logging in from another computer at the same time. That's both to prevent one person from sharing their subscription with 15 of their friends (which not only loses you revenue, but is also a CS nightmare) and to prevent one person from logging in an entire army of clones. Preventing multiple logins is quite simple, just keep a record of who is logged in at the server.
(B) is made somewhat obsolete due to (A) being harmless, but if you insist on such a thing, one easy way would be to store some kind of token (such as a per-user random number that you also store in your database) on the user's harddisk. Another one would be to generate a kind of "hardware id" from the computer, by e.g. reading the network card's MAC or the harddisk's or graphic card's serial number.
None of these are really tamper-safe, but they can be made reasonably safe insofar as they will not stop a malicious user or an identity thief (for example, a MAC address can be changed on most cards, and you can hook the API to query your harddisk or graphics card's serial number, and malware can steal that kind of information from another user's computer, etc etc). They will, however, prevent Joe Average from logging in from another computer, and they will allow a skilled identity thief to steal 3-4 accounts per hour, instead of 3-4 per second.
But think twice before doing that. Better think thrice. It does not buy you a lot, but it can cause great grief.
What do you do if the user's computer gets stolen or destroyed in a fire? What if the user upgrades his graphics card? Suddenly the game doesn't work any more!
If you now tell your user "Yeah, you paid for a 6-month subscription, bad luck for you", you're in serious trouble, and not only because you've just lost one paying customer and because they'll likely sue you.
As Oscar Wilde (who was demonstrably not a business man) put it: "The only thing worse than being talked about is not being talked about" -- you can be certain that you'll be talked about, on every forum and blog. And no, it won't help promoting your game. There is such a thing as negative publicity.
Edited by samoth, 29 October 2013 - 04:51 AM.