Logins and Passwords

	Author:	“No Bugs” Hare  Follow:
	Job Title:	Sarcastic Architect
	Hobbies:	Thinking Aloud, Arguing with Managers, Annoying HRs, Calling a Spade a Spade, Keeping Tongue in Cheek

To navigate through the book, you may want to use Development&Deployment of MOG: Table of Contents.]]

Login is one of those topics which everybody thinks to be obvious. However, when implementing logins in more or less reasonable manner, they quickly become a Quite a Big Headache 🙁 .

On Back-End Logins vs Player Logins

CSR Customer service representatives interact with customers to provide answers to inquiries involving a company's product or services.— Wikipedia —One of the first questions which we need to answer before starting to implement logins, is the following: do we want to have our Back-End Logins in the same space as our Player Logins, or separately? In other words, should the login in our back-end system (for people such as CSRs, security team, yourself) use the same mechanism (residing within the same database tables etc. etc.) – or should be completely separated?

In general, I prefer keeping player logins completely separated from back-end logins. Having player logins completely separated allows to improve security quite a bit, allows to implement different things differently (for example, performance is rarely an issue for back-end logins, while permission system tends to be MUCH more elaborated), and also allows to avoid unnecessary clashes between back-end tools team and game-development team. Even more importantly, it simplifies the integration of 3^rd-party social logins (which SHOULD NOT be applied to back-end logins).

TL;DR: While the sky won’t fall if you implement player logins and back-end logins on top of the same DB table – usually it is better to keep them separated.

BTW, one more note about back-end logins: if you’re processing credit cards yourself, you will probably need to make your back-end logins (as well as LOTS of other things, BTW) compliant with so-called PCI DSS (see [[TODO]] Chapter for discussion); while PCI DSS also applies to Client to certain extent, requirements for PCI DSS are MUCH stronger for the back-end. For now, let’s just note that if you’re processing credit cards – it is yet another reason to keep your back-end logins and player logins separate.

Player Logins: 3^rd-party Social Logins

First, let’s discuss Player Logins.

[[TODO (ref’d in Chapter I): in-app browser vs “open URL” for social logins (move discussion on it from Chapter XVIII); mention different nature of this choice from the choice of in-app vs “open URL” for internal stuff]]

[[TODO (ref’d in Chapter I): implementing social logins (Facebook for sure – including “device login”, maybe Twitter?)]]

“I STRONGLY recommend to provide an option for your players to use 3rd-party “social logins”When it comes to player logins, I STRONGLY recommend to provide an option for your players to use 3^rd-party “social logins” (such as Facebook/Twitter/Google+). This has quite a few advantages:

• the simpler the sign-in process is – the more players you have. And it is next-to-impossible to beat Social Logins on simplicity-to-log-in field (saving for not having login at all)
• they provide quite a bit of the all-important real-life information, which indicate, in particular, “how real the player account is” (see discussion in “Duplicate Accounts” section below). While 3rd-party social logins do NOT guarantee against duplicate accounts, they DO create a substantial barrier against them – and simplify identifying such accounts too.
  • I can assure you that your marketing/monetization teams will LOVE this real-life information too.
• all those questions such as “how to hash stored passwords” and “how to recover the passwords” are not your problem anymore 🙂 – well, at least for those players who have their accounts via social networks.

“If your game client is browser-less, then things become more complicated but usually still doable.To allow apps such as games to implement player logins, social networks usually provide some mechanism based on OAuth protocol. Integration with them is usually trivial as long as you can use  browser for this purpose; i.e. it is easy when either your game client IS browser-based, or you can run browser WITHIN your game client. If your game client is browser-less, then things become more complicated but usually still doable. In particular:

• DISCLAIMER: things DO change fast in this field, so YMMV greatly.
• for Facebook, you can use their “Login for Devices” as described in [Facebook.LoginForDevices]
  • the idea is to have a certain “authorization code” obtained from Facebook, showing the “authorization code” to the player. Then player goes to facebook.com/device and enters this “authorization code” (nothing else, kudos to Facebook for this)
  • you’re polling Facebook to see that player has entered the “authorization code” and to get “access token” if/when she did
  • DON’T forget to store the “access token” within your Client. Otherwise, on each player login you’ll need to repeat the “authorization code” procedure once again.
• for Twitter, you can use “PIN-based authorization” as described in [Twitter.PINBasedAuth].
• for Google+ sign-in (Google Sign-In to be precise), you can use their OS-specific services such as Google Sign-In for Android [Google.SignInForAndroid] and Google Sign-In for iOS [Google.SignInForIOS]. No idea whether it is possible to implement Google+ sign-in for desktops or consoles without integrating browser into your client 🙁 .
• Last but not least – you can use Steam login too.

“BTW, you MAY want to be bold and say “hey, no social login – no play”. In this case, you’ll get an all-important advantage of having that real-life information about ALL of your players.BTW, you MAY want to be bold and say “hey, no social login – no play”. In this case, you’ll get an all-important advantage of having that real-life information about ALL of your players. This real-life information (or lack thereof) Really Helps to deal with cheaters – as will be discussed in Vol. 3 (tentatively Chapter XXXIII, the one on Cheating), and to identify duplicate accounts (as discussed below).

Overall, whether to have 3^rd-party logins (and whether to have ONLY 3^rd-party logins) is a GDD-level decision (as discussed in Vol. 1, Chapter I), and it should be decided by the whole team, including (but not limited to) marketing and monetization teams. Within this book, we’re not going to tell whether you should take this or that GDD-level decision (3rd-party logins included); instead, we’ll just discuss the ways to implement features if you already decided to have them.

Players: Internal IDs, Visible IDs, and Login IDs

As we’re speaking about the games which are inherently multiplayer, most likely you will need some kind of ID for your players to allow them identify each other. Let’s name these IDs “Visible IDs”.

On the other hand, you need some kind of the way to identify the player internally (within your DB and to CSRs); let’s name it “Internal ID”. And on the third hand ;-), you need your player to enter something as ID during DIY login; let’s name if “DIY Login ID”. Of course, there is no law saying that all three should be different, so let’s see how they may be combined.

“First of all, you MAY use the same ID as all three IDs; i.e. you can make your Internal-ID == Visible-ID == DIY-Login-ID.First of all, you MAY use the same ID as all three IDs; i.e. you can make your Internal-ID == Visible-ID == DIY-Login-ID. It makes things simpler for CSRs, and is very straightforward (of course, it implies that Visible ID is absolutely unique – including being unique after the account is closed). OTOH, such an approach has some drawbacks too. First, renaming an account becomes a problem; however, if you do NOT provide the player interface for renaming (which is rarely a good idea, as it kinda defeats the idea of Visible ID as an identifier to other players), such approach MIGHT still work. While renames-by-CSRs will be necessary regardless of how adamant on prohibiting renames your GDD is, you will also need to handle unauthorized multiple accounts (to be merged later, but preserving all the history etc.); to support the latter you’ll need to implement a concept of a “group of accounts for the same player” anyway, and this concept will also cover renamed accounts, so it won’t be TOO bad.

Another option is to have your Internal ID artificial (known as “surrogate key” in DB world); in other words, in this case your Internal-ID will be just a meaninglessly looking number. This approach is more “clean” from classical DB point of view, but it is a bit less convenient in practice. However, it will also work. On the other hand,

2FA Two-factor authentication (also known as 2FA) is a method of confirming a user's claimed identity by utilizing a combination of two different components.— Wikipedia —Yes, I’ve heard that it improves security, but as a player, I am still firmly against it. My logic in this regard goes as follows: if security is a Real Concern – use 2FA (which will be described in  Vol.3, tentatively Chapter XXX on Advanced Security), it will provide MUCH more protection. Otherwise, requiring the player to remember yet another meaninglessly looking string of digits is IMO way too much for such a marginal security improvement 🙁 ; it is generally MUCH better to concentrate on other security-improving techniques as described below.

If using an artificial ID as your Internal ID – you MAY want to work with Visible ID for your DIY logins; another popular option is using e-mail as a DIY Login ID.

TL;DR: in most cases, I see the two following options as the most viable:

• DIY-Login-ID == Visible-ID == Internal-ID. Has certain issues with account renames, but otherwise is rather straightforward and workable.
• Internal-ID is artificial; DIY-Login-ID == Visible-ID, or DIY-Login-ID == e-mail (or DIY-Login-ID absent at all, if you’re sticking to “3^rd-party login ONLY” policy mentioned above).

Visible IDs and censorship

Having Visible-IDs (which are selectable by players) raises the question about somebody using foul words as a part of their Visible ID. Which, in turn, raises the question of censoring them (of course, it is a GDD-level question whether you want such censorship, but rather often you do).

To implement censorship of Visible IDs, from what I’ve seen, the following policy (of post-censorship for visible IDs) tends to work reasonably well:

• DO prohibit the most obvious patterns when they choose their ID.
  • “DON’T count that you’ll be able to filter EVERYTHING automatically; in the creativity battle between human and machine, humans still tend to win.However, DON’T count that you’ll be able to filter EVERYTHING automatically; in the creativity battle between human and machine, humans still tend to win.
• After creating account and choosing Visible-ID, the player may start playing right away.
  • However, IF Visible-ID is “suspicious” (has too many words, or too much punctuation, or too many changes in capitalization) – it is sent to a queue where such suspicious Visible-IDs are approved manually by CSRs (and the censored accounts are banned). Yes, it means some effort by CSR team, but if you actively don’t want foul wording associated with your game – after some optimizations of filters and CSR tools, the effort is not that bad . In practice, given the right tools, one CSR can easily process 10-20 “suspicious” Visible-IDs per minute; it is 5000 “suspicious” accounts per day; with percentage of “suspicious” accounts being in low single-digit percentages² – it means over 100K of new accounts per day per CSR; not too bad if you ask me).
  • Relying on complaints is usually NOT reliable enough 🙁 , and may lead to Visual-IDs having outright foul language (which, depending on your game, may or may not be a good thing)

Avatar Censorship

While we’re at the issue of censorship, let’s also mention a little bit different beast – player-uploaded avatars. As it has been observed, player-uploaded avatars DO have a potential of being a valuable addition to your game, but they DO need to be censored (and from what I’ve seen and heard, the rate of offensive stuff going to avatars is MUCH higher than that of the Visible-IDs).

“While Visual IDs were subject to manual post-censorship, for avatars it is almost-universally better to have pre-censorshipMoreover, while in the schema described above, Visual IDs were subject to manual post-censorship (i.e. CSR reviews IDs after player can play and the others can see it), for avatars it is almost-universally better to have pre-censorship (i.e. CSR needs to review user-uploaded avatars before anybody else can see it).

This process is not TOO time-consuming (50 pics/minute per CSR being very possible), but if you’re concerned about the costs – you can always say that ability to upload avatar is one of the features available only to users with some amount of “points” (whatever the name and meaning of these “points” can be).

DIY Player Logins

Even if you, as suggested above, have implemented 3^rd-party Social Logins for players, you still may want to have your own system for player login. As noted above, “whether to have DIY Player Logins”, is an important GDD-level decision, which we won’t be dealing with here (phew :-)).

From the technical point of view, however, implementing DIY player logins creates a lot of certainly-not-a-rocket-science but rather mundane work, with quite a few different things to be implemented. NB: if implementing DIY player logins, you need to implement BOTH items listed in this “DIY Player Logins” section, AND items in “DIY Logins (both player and back-end)” section.

DIY Player Logins: Registration Form

One of the big drawbacks with NOT using social logins, is that before your potential player can log in, she needs to fill in your Registration Form. One problem which is still widespread – is asking for too much stuff to register (just recently I’ve seen a form with 10+ fields, though it is better from 15+ years ago, when a 20-field form was not so rare). While this is not a purely-technical decision and comes from marketing etc. – still try to fight these things. They DO make your game less popular 🙁 .

“it is usually a Good Idea™ to request only that information which you Really Need at the moment; however, note that “Really Need” here should be seen not from your side, but from the player’s side.It is often a Good Idea to have more than one registration form, so player is required to fill several smaller forms at different points in account lifetime (instead of filling One Huge Form when registering). In particular, it is usually a Good Idea™ to request only that information which you Really Need at the moment; however, note that “Really Need” here should be seen not from your side, but from the player’s side ;-( .

For example, when the player just wants to start playing, he’ll probably realize that you DO have a good reason to know his Visible-ID and password. In addition, USUALLY mandatory e-mail field (with an explanation that this is to restore the password in case if he loses it) won’t be seen as “too much” here (though you MAY want to keep it optional for the time being). Asking for the stuff such as address and (even worse) credit card number usually qualifies as a Pretty Bad Idea at this point.

Then, when the same player wants to buy something – he will be much more comfortable to give away his credit card number and address (though asking for full address is often unnecessary, and you might be able to get away with just ZIP code – more on it in Chapter [[TODO]] on Payment Processing).

P.S. My apologies for telling obvious things, but even in 2016 I still see the games and web sites ignoring these simple principles…

DIY Player Logins: On Client+Web Logins

One further thing which I actively hate as a player – is forcing players to use BOTH in-client login AND web-based login. When this happens, usually gameplay login goes via the game client, and “other stuff” (such as purchases, account management, history, etc.) goes through website.

“do everybody a favor, and DO NOT make your player login TWICEAs it was noted in Chapter I from Vol.1, it is a GDD-level decision; however, I should note that such dual logins are usually pushed by development, and as a developer, I don’t see it as necessary. If you want to re-use web infrastructure for your “other stuff” – it is often fine (for example, you can run an instance of the browser within your client), but do everybody a favor, and DO NOT make your player login TWICE, as logging in TWICE has several rather negative implications:

• Players hate it (I can testify about it myself ;-))
• It creates quite a bit of confusion and unnecessary questions
• It creates a feeling of a half-baked product
• From security perspective, it tells that passwords can be entered not only into the client app, but also into web site (which is a security weakness by itself, as it tends to increase success rate for phishing significantly)

In short – DON’T do it.

DIY Player Logins: “Remember me”

One thing which you’ll probably want to implement for DIY player logins, is “Remember me” checkbox in your login dialog. For most of the players out there, it is a Good Thing™ to have (though it still has certain drawbacks, such as players forgetting the password almost inevitably).

Question “whether to have ‘remember me’”, belongs more to the GDD realm; my job here is to say “how to implement it” if you decided to have it.

Of course, the password needs to be stored locally, but whenever you hide it (in Windows registry, in a protected file, wherever-else), an attacker (such as “somebody who sent a phishing e-mail to your player) can easily steal it. Therefore, storing passwords in plain is not really a good idea.

Scrambling

“Encrypting” (actually, scrambling) the password with a fixed-key-embedded-into-the-client is a bit better, but if your game is popular enough, you can count on that fixed-key being public knowledge among the hackers 🙁 , and on tools being easily available to descramble it.

“stored-password is encrypted with a key, which key is obtained as a mix (for example, using some SHA hash) of certain parameters, these parameters being specific to the system where the Client runsOne game which I’ve seen played in this regard, is that stored-password is encrypted with a key, which key is obtained as a mix (for example, using some SHA hash) of certain parameters, these parameters being specific to the system where the Client runs. This means that for attacker it is no longer sufficient just to take the password from the player’s computer, but is also necessary to get a whole bunch of parameters (which parameters are not so well-known³).

Such parameters may include stuff which you yourself have put to the system (such as random-number-stored-somewhere-far-away-from-stored-scrambled-password), and/or stuff which is inherent to the system but is not likely to change (at least until OS is reinstalled). For some examples of such things – see “Identifying Client Device” section below.

Note that whatever we do in this regard of “encrypting” (actually, “scrambling”) the stored passwords, is (by definition) Security-by-Obscurity which can be broken; all this trickery just raises the cost and complexity for the attacker “somewhat”. Which means “if your game routinely involves THOUSANDS OF DOLLARS – DON’T store passwords” (and/or use 2FA as noted above). However, IMNSHO, for quite a few games out there such Security-by-Obscurity is well worth the added convenience for players (in other words, players will be willing to pay the price of the risk in exchange for convenience, and after all, it is them who define what we need to do).

DIY Logins (both player and back-end)

Even if you have policy on using ONLY 3^rd-party logins for players, it (almost)-never makes sense to rely on 3rd-party logins for your back-end system (the ones for CSRs, security team, developers etc.). And if you do implement DIY logins – there are several things you MUST remember about. NB: if your CSRs can access your system ONLY via internal LAN (which you SHOULD if you can), some of these requirements are not THAT critical, but I still suggest to implement them, especially as your company grows.

DIY Logins: Weak Passwords

The first and most obvious security feature when implementing logins yourself, is related to weak passwords. A few things you SHOULD do when allowing player to choose their password:

• “DO impose a lower limit on password length.DO impose a lower limit on password length. For back-end, I strongly suggest at least 12 chars, for players – well, chances are that you’ll need to settle for 8 (DON’T go below 8 though)
  • BTW, upper limit on password length should be Really High (1000 symbols will be good enough). NB: if transferring password in plain, you DO need a limit on length to avoid crashing your server with 1GB password string; if you’re using Client+Server hashing as described below, there is no security-related need to have any limit at all (though practically, 1000-char password will still do quite nicely ;-))
• Run player-password against several dictionaries of well-known passwords (can be found, for example, on [SkullSecurity], [KoreLogic], or [OpenWall]). Hint: some of these dictionaries are huge, but may (and SHOULD) be kept to the server-side.
• Run player-password against the password entropy estimator
  • Pick a Reasonably Good One. Personally, I tend to prefer pattern-based entropy estimators such as [zxcvbn], to rule-based ones such as “unless your password has at least one special symbol, it’s bad” (BTW, if this rule applies even if your password is 20-char long, it doesn’t make any sense security-wise). However, as we’re not about to protect Really Sensitive Info with just password – it doesn’t matter TOO much.
    • DO run it not only on the client, but on the server too(!)

DIY Logins: Rate Limits and Lockout

Prohibiting weak passwords is important, but rate limiting your logins is at least of the same importance. This is necessary to prevent so-called “brute-force” attacks, when somebody tries all the passwords in a certain space, until he founds the right one.

“weak password detectors and login rate limits work shoulder-to-shoulder to prevent brute-force attacksStrictly speaking, weak password detectors and login rate limits work shoulder-to-shoulder to prevent brute-force attacks: weak password detectors ensure that the search space for brute force is large enough, and rate limiters are preventing search space from exhausting too soon.

That being said, for all the practical purposes, limiting login rates for one account to 1 login per second, is sufficient.

Account Lockout

When dealing with rate limits, a question of “account lockout” due to subsequent failed login attempts, tends to arise.

Personally, I do NOT like policies like “lockout after 3 logins”; these are WAY too restrictive for usual business- and game-related stuff (and once again, if security is REALLY critical – use 2FA instead). Personally (and until any regulation issue arises), I prefer the policy of doubling the delay for each subsequent login attempt for the account. In other words – while the second login attempt can be done in 1 second, the third one will require to wait 2 seconds after the second one, and so on. By 8^th attempt, we’ll be in the range of over a minute, with any chance of brute force attack being effectively thrown away.

BTW, while we’re at it: specific numbers for rate limits mentioned above are for one account but accounting for the logins across the whole system (i.e. NOT when you count limits on per-server basis). While enforcing security with per-server accounting for rate limits, MIGHT be possible, I STRONGLY prefer to have them counted for the whole system (and stored within one single DB).

“somebody who hates player A (or doesn't want him to play in an upcoming tournament), can simply try to login (using 'A' as a DIY-Login-ID) 5 times; bingo! player A is locked out and won't be able to login at allOne thing which comes hand in hand with the issue of account lockouts – is potential of DoS attack on such accounts. It MAY be particularly nasty for the player accounts (especially if you’re using DIY-Login-ID == Visible-ID). For example, if you implement lockout after 5 failed login attempts, somebody who hates player A (or doesn’t want him to play in an upcoming tournament), can simply try to login (using “A” as a DIY-Login-ID) 5 times; bingo! player A is locked out and won’t be able to login at all. For this reason, for player  logins it is probably better not to lock players out (and not to increase the rate limit delays for them above, say, once every minute).

DIY Logins: Forced Password Changes

[[TODO: NO forced changes per Schneier]]

The next thing you’ll need to think about when developing DIY logins, is forced password changes. In theory, you should ask even your players to change their passwords on regular basis (though relatively recently, the wisdom of doing it has started to be challenged, see, for example, [StackExchange] and more importantly, [GCHQ]).

In any case, I didn’t see any game (besides stock exchanges) enforcing this policy for their players, and THIS IS A GOOD THING (here I mostly agree with the arguments in [GCHQ], though arguments along the lines of “not causing burden on users” to avoid password changes and “users should report logins which are not their own” as an alternative are self-contradictory).

As for back-end – well, it is up to you whether to implement such a policy. I won’t say it is “obviously harmful” or “obviously beneficial” (the game here is different, and balance of pros and cons is not that obvious as for players). One case when you certainly should do it – is when it is a part of some regulations (and there are still plenty of such regulations out there). Other than that, my current line of reasoning goes as follows: for those accounts which REALLY security-critical – you SHOULD use 2FA anyway, and the whole question of password-changing becomes quite different there; in particular, arguments against making user’s life more complicated (causing passwords sticked to the monitor), become much more convincing.

If you’re about to force password change – usual forced-password-change period varies between 3 and 6 months. One more thing in this regard is preventing to re-use old passwords by the same user; to do it, you’ll need to store hashes of N recent passwords per user (with typical values for N being from “5” to “infinity”).

DIY Logins: Password Hashing

Whenever you implement DIY login, one thing you SHOULD do, is password hashing. The subject is quite complicated (see, for example, discussion in [NoBugs]); here I will just provide a very brief summary for password hashing:

• “Password hashing aims to deal with the Ultimate Doomsday Scenario - when your whole password database is stolen.Password hashing aims to deal with the Ultimate Doomsday Scenario – when your whole password database is stolen.
• DO use password hashing
• DO use the following hashing model (“Client+Server Hashing” one):
  1. User enters password P
  2. P’ is calculated (still on the client) as:
     client_slow_hash(SiteID||UserID||P)
     where SiteID is unique per-site string, UserID is the same ID which is used for logging in, || denotes concatenation, and client_slow_hash() is any of the intentionally slow hash functions discussed below.
  3. P’ is transferred over the wire
  4. on the server side, P” is calculated as:
     server_slow_hash(S||P’)
     where server_slow_hash() may be either the same as or different from client_slow_hash(), and S is a “salt” which is a crypto-quality random number of at least 128 bits long, generated for each user(!) and stored within user DB for each user.
  5. P” is compared to P” stored within DB. P’ is never stored in database.
• As client_slow_hash() and server_slow_hash() DO use special (intentionally slow(!)) password-hashing functions such as scrypt or Argon2.
  • “Calculation times of 0.1 second (on the slowest of your target Client devices) for client_slow_hash() and 0.001 second (on one single server CPU core) for server_slow_hash() is not a bad starting point.Make sure to select cost parameters for these functions to keep reasonable balance between (a) server load due to hashing being acceptably low on the one hand (while you’re at it – make sure to consider scenario of massive disconnect of all your players with a massive reconnect-with-relogin just a few seconds later), (b) login for user being acceptably fast, and (c) cost for the attacker being acceptably high. What this “acceptably high” constitutes, is a different story. Calculation times of 0.1 second (on the slowest of your target Client devices) for client_slow_hash() and 0.001 second (on one single server CPU core) for server_slow_hash() is not a bad starting point. The former is good enough to keep your players reasonably happy, and the second is good enough to process logins from 100 of your players (which is usual number of players per core) within 0.1 second. On the other hand, 0.001 second on the server side will improve attacker’s costs to break your hash at least 1000x-fold compared to cost of breaking password hashed with SHA-1; in other words, these days costs of breaking 8-char password will be in the range of tens of thousands of dollars (that is, after stealing your password DB); if your target devices are not browsers – you’ll further increase attacker’s cost by at least 10x more by using client_slow_hash() with calculation times of 0.1 sec. If this is not enough – I suggest to require longer passwords (increasing minimum password length by one gets you about 50x increase in search space), but probably once again, with attacker’s costs going into hundreds of thousands of dollars, it looks as a job for 2FA.

DIY Logins: Password Recovery

“you can be sure that as soon as your game is alive and kicking - you'll need to implement password recovery for your players.One thing which you will be forced to do at least for players – is password recovery. No matter how strongly security team will object (and no matter how many times you were promised that “sure, we’ll never ever have a mechanism for password recovery”) – you can be sure that as soon as your game is alive and kicking – you’ll need to implement password recovery for your players 🙁 .

Overall, password recovery is a complicated subject by itself, but I will try to give some ideas:

• If security is at least of some concern – DO try to have password recovery settings on per-account basis. In other words, DO provide your user with a choice what exactly they want
  • One option will almost inevitably be “sending password reset link to e-mail”
    • It inevitably means that “whoever controls player’s e-mail – controls her account with you”
    • You MAY want to try asking security questions before sending this password reset link, BUT it requires asking them in advance, which is rarely a good idea for most of the games (unless it is optional – see above)
  • Another popular option is for player to provide you with their phone number, and you sending them a “password reset” code via SMS.
• In any case, NEVER EVER send newly generated password (or Schneier forbid, an old one⁴) to your player in clear; send password reset link instead.

Back-End Logins: On Access Permissions

One issue which is very common when implementing logins for your back-end, is “how to organise permissions for different people within your team”? In this field, I’ve seen quite a few rather overengineered approaches (like storing a tree of arbitrary depth within an SQL table – ouch!)

In practice, I’ve seen the following simple model to work pretty well as a start (and to be extensible enough later):

• your software has a set of “actions” which may be made by back-end users. These “actions” may be anything from “accessing e-mail system” to “seeing an unmasked credit card number”.
• there are “groups” a.k.a. “roles”
  • these reside in a special table in DB.
• each “group”/”role” has a list of allowed “actions”
  • it is implemented as “many-to-many” table linking “actions” and “groups”/”roles”
• each back-end user may belong to one of the “groups” (or to have one or more “roles”)
  • this is implemented as an another “many-to-many” table linking “users” and “groups”/”roles”
• “Answer to the question 'whether user U is allowed to perform action A' becomes very obvious (and very simple to implement too - it is just a simple SQL join)that’s pretty much it. Answer to the question “whether user U is allowed to perform action A” becomes very obvious (and very simple to implement too – it is just a simple SQL join)
  • Of course, as your system grows, you’ll need other stuff (including nested groups and negative rights), but these won’t be TOO difficult to add on top of the very simple schema described above.

Player Logins: On Loginless Spectators

[[TODO: move higher?]]

Last but not least, there is yet another login-related question in the context of games:

As in was noted in Chapter I (from Vol.1), it is certainly a GDD-level decision (i.e. “not the one developers can make themselves”), I just want to mention that from what I’ve seen, allowing people to watch your games without logging in, seemed to have a positive impact on number of players. The idea here is that if you allow people-who-came-to-your-site to watch your games before logging in, and before going through registration, you’re replacing One Big Step of downloading-your-client-PLUS-registering-and-giving-their-info with two smaller steps (one being downloading-your-client, and another one being registering-and-giving-their-info). Of course, it is even better to allow observing/spectating without installing at all (see discussion on web-based spectating-only clients in Chapter VI from Vol.1), but this is a separate issue (and to be efficient, it also requires loginless spectators).

If I’ve managed to convince you about supporting loginless spectators, the next question is: well, how to do it? Actually,

In other words, if you build your game with a clean separation between “ability to view” (which corresponds to the concepts of “published state” and ”state sync” discussed in Chapter III) and “ability to act” (which covers pretty much everything else) – making your observers loginless should come rather naturally. However, if you start to intermix these two things without giving it a thought (which BTW is a Bad Idea which will hurt you in the long run regardless of spectators) – adding it later will become a Big Problem.

Or from a bit different perspective: DO keep your “view” data separate from your “action” data, it will make your code cleaner and your project better. As a nice side effect, you’ll also be able to implement loginless spectators/observers if desired.

[[To Be Continued…

This concludes beta Chapter 15(a) from the upcoming book “Development and Deployment of Multiplayer Online Games (from social games to MMOFPS, with social games in between)”. Stay tuned for beta Chapter 15(b), where we’ll continue our discussion into questions related to dealing with duplicate accounts, identifying client devices, and ways to implement bans.]]

Don't like this post? Comment↯ below. You do?! Please share:

Acknowledgement

Cartoons by Sergey Gordeev from Gordeev Animation Graphics, Prague.