As part of risk analysis you need to figure out who is likely to attack, what and how they are able to attack, and what they can find inside the treasure box when they succeed.

First, what is in the treasure box? What do the attackers get when they successfully break in? In some cases they find a list of millions of valid credit card accounts, or usernames and passwords, or other extremely valuable information. In other cases the most valuable thing a successful attacker can gain is a collection of salted email hashes and salted password hashes, along with a simple high score table and absolutely nothing of value. Make sure the treasure box is as empty as possible when the attackers arrive.

Then I look at what and how they are able to attack. It looks like you are most concerned about someone hijacking a computer. Sadly in that case you have no control. If a client's computer is fully compromised then they are fully able to act and behave as an authenticated account.

There a few common attack vectors. One of the simplest and most common attacks is man in the middle (MitM) attack. Someone simply intercepts the message, modifies it, and watches what happens. Because this attack is trivially easy to perform, you must assume your entire communications protocol is known. Assume the attacker knows exactly what you are sending and why, so be prepared for garbled data, invalid data, and intentionally wrong data. Be prepared for this data to come from every user; when you are expecting the name of the player be prepared for an attacker to send an entire executable in the hope of a buffer overrun; when you are expecting a motion coordinate be prepared for the player to send a coordinate that jumps across a wall or boundary; when you are expecting credentials be prepared for an attacker to start at "00001" and test every value through "99999". Validate all data that comes across the wire. Another extremely simple and common attack is the replay attack. The attacker records the session, replays the username and password and other values, and gets logged in. The key to defeating it is to ensure data is invalid across sessions and that a unique session is established each interaction. Fortunately this has industry-standard solutions, and simple encrypted channels like SSL (also called TLS and HTTPS) can help limit the damage of replay attacks. Since an attacker can only replay the values from machines they already own they cannot spy on others. The third most common attack is the Human/Machine Interface (HMI) attack. In games these are hacks that change visibility of walls, or add outlines or markers to indicate otherwise invisible data that the player normally wouldn't see. These attacks can be much more difficult to overcome, and tools like PunkBuster can be licensed to help in that fight.

There are many more attacks, as many attacks as your attackers can invent, ranging from the $5 wrench (just hit the person with it until they reveal their password) to social engineering, to extremely complex technical attacks, to attacks that haven't even been invented yet.

Ultimately it is up to you. You need to figure out the value of the treasure chest and how much money, time, and effort you are willing to invest in protecting that chest.

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.

The fact that you're asking this suggests to me that you're rolling your own security. If so, my advice is to stop right now, use a third-party security provider, and use the facilities they have available - pick a Google account, an OpenID, a Microsoft account, anything but rolling your own. Bottom line is that you don't know enough about security to do this yourself; hell, I'm a top-level network admin and I don't know enough about security to do this myself.

When programming a network game every programmer must consider security in their code. Every code review must consider security.

Quite a few of the games I've worked on have had network play. There are surprisingly many ways that non-network code can still impact other players.

One such bug was a disc scratch or malicious user issue.

At the time, Sony required that when a disc read failed you must continuously retry the reading. (It never made much sense to me, it wasn't like the disc was miraculously going to become un-scratched or un-fingerprinted.) In any event, QA discovered you could press down on the lid of the PS2 slim, which in turn pushed down on the disc forcing it to stop. We couldn't follow any of the other protocols such as disc eject because of first-party requirements; the disc was still in the drive and we needed to follow their requirements. The game would then stall as it continuously attempted to re-read from the disc.

However, this became a critical network play bug. If the user was on a network game the other players would expect network packets. Because the networking thread was still alive and running it would keep sending keepalive packets and otherwise act as though the game had stalled. (Again, this is because we were forced to assume that disc reads would eventually succeed.)

Suddenly we had a case where something that seemed completely unrelated to network programming introduced a critical 'grief' behavior, a malicious user could keep the game hijacked forever until the other players forfeited the match through quitting, giving a DNF to their tournament records.

When you write a networked game, EVERY programmer must consider network integrity in their code, even if they aren't directly working on security or communications code.