I am getting very close to finishing my first Unity game. I currently do not ask the users of my game to create an account when they first install and load the game (no need to enter a username and password).
I do create them an account in a database on my server. When they load my game for the very first time, I generate a random GUID and I get their unique device id (SystemInfo.deviceUniqueIdentifier) and I pass those values to the server. I add them to my users table with those 2 values. I then also store that GUID to their device in it’s persistent data.
Next time they load the game I pass both those values to the server to lookup their account in the database. The reason I added the GUID was because I was worried that a hacker would be able to impersonate other players by loading the game and passing random device ID’s to the server until someone account was found. With the GUID, they would need to know both. So it was just a layer of security
I’ll be honest… I have no idea what the industry standard is for logins. I just know if I put up a login screen asking for a username/password when the user hasn’t even tried the game, they might uninstall it right away.
And the reason for this post in the first place was I noticed if a user has played for a period of time… uninstalls the game and then reinstalls later… their account is lost (their GUID will be different). Also, if they every lost their phone, they wont be able to recover their account on a new phone).
I’d love to hear recommendations on how I should be handling user accounts and making sure people don’t lose all their hard saved work.
You’ll need to have some way of identifying the person, not the unique installation. But you don’t need to do it on the first day they play. Keep holding their newbie GUID-only account open on your server, just as you’re doing. In your game, you can offer a much less pushy recommendation that they can choose to create an account to maintain their score and loot. They can do it anytime they want, as long as they do it before they Uninstall your game, and if they choose to sign up then you can associate their GUID with a login/password at that time.
A couple finer points…
(1) If you get to the point you have many thousands of GUID-only accounts on your server, you may want to institute a policy where the GUID-only account will only be maintained for N months of inactivity but signed-up accounts will be maintained for years to come. You may need additional rules if you get wildly successful.
(2) If you deal with passwords at all, always salt and encrypt them on the user’s device in the Unity app, and compare the resulting encrypted form on the server. Never send a bare password over the network and definitely never save a bare password in a server database; if your server gets hacked, lots of people will be justifiably pissed at you. Smart users will not use the same password as their online banking, but there are many not-so-smart users and they will still be justifiably pissed if you actually can see what password they use. Not even your super-user administrator staff should ever be able to read what the user’s original unencrypted password was. (Another conversation explains a little more about the phrase “salt and encrypt” or more accurately “salt and hash”: [Cryptography] The usage of pepper )
(3) If you deal with online accounts at all, whether logins or GUIDs, you will need to deal with users trying out weird probing attacks to see how they can cheat. Logging in from two or more devices using the same GUID or login credentials, for example. Just be sure to think critically about how you ensure they play fairly, especially if there’s any part of your game which is competitive in scores or loot or rankings.
Ya, I like the idea of allowing them to register with just the GUID initially (like I do now), but in-game recommend they convert it over to a signed up account (which I assume I can give them the option to use google/facebook/etc to sign in).
And ya, I’d never save plain text passwords in the db
#3 is a good point. I’ll definitely have to handle those cases.
