I am developing an iPhone/Android game app. Currently users must register USERNAME (3 chars min, letters only) + PASSWORD (8 chars min, ascii only) before allowed into the game.

Testing shows some users fumble with this, especially the password, and we are afraid we will lose users because of this.

I'd like to hear elegant ideas from app developers of creating the simplest possible registration process that even 300 grannies will pass.

The game server data contains little "sensitive" information as such, so there's not much to gain from hacking an account.

The following methods are not applicable:

  • Social media login
  • Auto-generating passwords
  • 4
    Why are social media login and auto-generated passwords not applicable? – Gilles Jan 2 '13 at 9:39
  • 2
    Your threat model is a little obscure, can you clarify exactly what you are protecting against with the password? I'm not aware of any games on my iPhone that require this, so you presumably have some special reason... – Graham Hill Jan 2 '13 at 9:46
  • And further to Gille's point, are you counting e.g. OpenFeint in your list of banned social media login? – Graham Hill Jan 2 '13 at 9:48
  • 1
    So long as social media logon is off the table for unstated reasons, there is no real way to answer this question. There are unstated constraints on the solution set. If you have a sincere question, please state the requirements clearly. – Mark C. Wallace Jan 2 '13 at 11:46
  • 1
    Your list of unacceptable solutions without a reason is weird. – Ramhound Jan 2 '13 at 13:19

Password security is a trade-off between usability and security. The more "complex" a password is (i.e. difficult for attackers to guess), the harder it gets for the user to remember and type it correctly. You can try to shift the balance a bit with some tricks, but you have to accept that if anybody can use the system without fumbling, then some passwords will be guessable.

Among the possible tricks to make passwords more secure while keeping them usable, you can try the following:

  • Enforce strict limitations on login rate. For a given user account, you shall not accept more than one login attempt per 10 seconds; possibly, increase this delay after each failure (but don't lock the account permanently, otherwise it becomes too easy to lock other people's accounts).

  • Use a graphical "alphabet". A password is nothing more than a sequence of symbols, which the user remembers and then "types" by pressing the right buttons on their smartphone screen. Letters and digits piggyback on an ability which most human users learned through years of training, namely reading. However, humans are good at other things than reading. Your app could display a "keyboard" with colourful symbols, which users then use as "letters" for their password (thus, they remember the sequence "cat-plane-cake-chair-tree-tree-rabbit" instead of "u8n.ffi"). With pictures, users will find it easier to build a kind of "story" around their password, which will make it easier for them to remember. (Add colours, but don't use them as a discriminant, since there are colour-blind people.)

  • Bind the device to the account. For instance, in an HTTPS context, push a random cookie into the client browser. When the user comes back but does not show the cookie, enforce stricter verification rules (e.g. "security questions" or simply longer login delays). This will make life harder for attackers but not for most of your users (people who switch smartphones will experience the longer delay, unless they use some kind of synchronization to transfer their cookies).

  • Don't overdo it. You state that there is little value in hacking an account. Therefore, you do not need strong security. Risk analysis is paramount: use protection efforts which are proportionate to the value of what you are trying to protect, but no more.

  • Make the users responsible. In your case, your most valuable asset is your reputation; what would be most damaging in the case of a successful account hack is the idea that your system is "hackable". Therefore, try to proactively blame the user: the user must be convinced that if his account gets hacked, then that's his fault, not yours. This is done by providing the right tools: allow the users to enter strong passwords, and add a visible warning on the registration page ("the user is responsible for choosing a strong password, which is not easy to guess"). This is not a nice thing to do to your users, but everybody does that (beginning with insurance companies: if you do not lock your car door, then you will never be refunded for whatever was stolen from your car).

  • Offer a non-compulsory password generator. A simple button that the user may push if he decides to get a randomly generated password. Some users will use it, and these, at least, will get strong passwords (and, more importantly, passwords with a known strength).


If your purpose is simply to identify the same user when they log in more than once and security isn't a terribly concern, is there a reason you can't simply use the device ID? It wouldn't allow for someone to access their account from more than one device, but it would let you uniquely identify a device. You could then have a username and password option for if someone want's to use their account on more than one device.


Use the camera on the phone to take a picture of the users face and use it for id. There is an app that does this but I forget it's name. Why must a user log in at all, why not store all data required by the app locally on the phone?

EDIT: another thing I've seen is using pictures, for example choose 5 pictures from a list of 10 to authenticate.


Best is to use the gaming account that modern systems have. Google Play Games and iOS Game Center for example. This is the standard method, user simply need to click Yes on the prompt screen. Your users need a Play account/Apple account to download your games from the Play store/App store anyway, so they must already be logged in on their device, as for people who downloads outside the regular app store, well they're not your typical granny.

If you for some reason don't want to do this, make the registration optional and passwordless. When user decide to register, let them enter email and send a confirmation key to that email message, user have to click on that key for the sign up to complete. When the user sets up a new device, ask them for their previous email and send another confirmation key to link the new device with the account. Behind the scenes, you issue a unique token for each device that's linked to that device and account.

Your Answer

