I want to reverse engineer what most mobile multiplayer games do with there login system and with that I mean the user is able to start to play immediately with a guest account and can later fill in a name and link with Google, Facebook or email/password. I think I need the following steps the moment the user presses "play immediately".

• Create a unique user name, something like guestXXXX and a password.
• Store Username and password locally. Encrypt password locally.
• Store the username and password in the database. Encrypt password with a unique salt.

Now when the player boots up the game again he will skip the login step since there are local credentials. The only problem I see here is when the user does not register an email, his own password or links with a social media account he will lose his account once he loses his local credentials, most likely with an uninstall. But I think it's very good to have the user play first before he commits with yet another username and password or link with Facebook. I can always throw in a warning when an account is not linked every now and then and give a small bonus when the user links it.

Am I forgetting something here? Are there other proven methods so the player can get engaged immediately?

• You don't strictly need to generate a password, since you can issue the user with an authentication token - just like when you return to a website after having logged in before, the cookie can get you in without it needing to contain the password.
• You don't 'encrypt' passwords with a salt - to encrypt means there is the possibility of decryption. You'd be hashing the passwords which is a one-way operation (or rather, using a key derivation algorithm, before the crypto folks complain about my terminology. It's important you don't just use any old hash algorithm. Ideal choices are currently Argon2, PBKDF2, or scrypt.)

Beyond that, I don't think there's anything you're missing (apart from the possibility of playing without an account at all, but I'm assuming that's not practical here).

3 hours ago, Kylotan said:

• You don't strictly need to generate a password, since you can issue the user with an authentication token - just like when you return to a website after having logged in before, the cookie can get you in without it needing to contain the password.
• You don't 'encrypt' passwords with a salt - to encrypt means there is the possibility of decryption. You'd be hashing the passwords which is a one-way operation (or rather, using a key derivation algorithm, before the crypto folks complain about my terminology. It's important you don't just use any old hash algorithm. Ideal choices are currently Argon2, PBKDF2, or scrypt.)

Beyond that, I don't think there's anything you're missing (apart from the possibility of playing without an account at all, but I'm assuming that's not practical here).

Could you elaborate on an authentication token? Wouldn't that be the same as a password? The issue is the user need to be able to return to his account after he re-installs the game. If I would store the token locally it won't be available on a different device.

And yes I meant hashing, should get that terminology right but I did use hashes for a website a couple of years ago. Any idea on what to use with Java? I understand that securing users credentials is important since most of them use the same password for everything.

But using a password like this I need to store it locally as well to automatically sign in. So I think I do need to encrypt it locally and then decrypt it on the server where I will check the password+salt vs the hash.

An authentication token is a client-side object that shows that the client is who they claim to be. The best example here is a browser cookie - once a user logs in, they might get a cookie that contains a user ID and an expiry time. If they supply that cookie, you know that they logged in previously (via password, or whatever). You normally would also cryptographically sign the cookie using a server-side secret key so that it's impractical for a user to forge one. This is sometimes called digital signatures.

Whether you use a token or a password, if you store it locally, they won't be able to access it on a different device anyway. The problem is exactly the same. Traditionally we use passwords because they're something a user can know (as opposed to something a user has, or something a user is) and therefore they do not need to be stored anywhere, but when you randomly generate them, that's out of the window. Storing it locally changes it to something the user has, but then you have to ensure they don't lose it; which is out of your control.

One major advantage of using a token is that you don't ever need to store any passwords locally, and therefore you won't have jeopardised the user's security if their device is stolen or otherwise wrongly accessed. When transmitting passwords that have been entered by the user, you should not be encrypting that yourself - use a tried-and-tested protocol like HTTPS to do that for you.

Ok, that makes a lot of sense. When the user loses his token he will be presented with the login screen again and if he registered/linked his previous account he can get his token back otherwise he has to create another guest account.

How does this token look? Is it just a "long" random char field that does not have to be unique since the username is already unique? And does this need to be encrypted or can I just store it locally in a obvious user settings file?