With a topic like account recovery, you are opposing two things: On one hand, you want to ensure availability for your customer, on the other hand, you want to ensure confidentiality of the account.
There will be situations, in which you as a system designer have to prioritize one over the other. Specifically, if a customer is in a situation, where they have lost access to the account, but cannot sufficiently prove that it is indeed their account. You either risk locking them out of their account, or risk giving unauthorized third party access to the account.
Before implementing such a system, it's helpful to write down goals and implicit assumptions about the authentication system:
- New users should have as little friction as possible.
- Users should be able to recover access to an account, even if the original device is no longer available (lost, stolen, broken, etc.)
- Users may not want to use third-party services for authentication
- Users may not be very technically adept
There are several ways such systems are implemented in the real world. One very common example is that users initially are tied to some device ID, so they can simply start playing. Let's call such users guests. A guest may not even be aware that they have created an "account", which is good for non-technical users.
Guests should then be told to register a "proper" account, in case they lose access to their device. This could be as simple as an e-mail address, to which a one-time link is sent. They click the link, confirm ownership of the e-mail and now they have a proper account registered to the user. To register a new device, merely entering the e-mail address is enough. A one-time link is sent again, which confirms that the user has access to the e-mail address.
The upside of this scheme is that it's very easy to use. It requires very little technical knowledge aside from "What is my e-mail address?" (which admittedly can be a challenge for older users). The downside is, that access to the e-mail address is indeed the only then authenticating the user. No password, no second factor, etc... This would indeed make it easier for people to impersonate the real user and claim they have lost access too their e-mail account. (I personally had a similar thing happen once, where I forgot which e-mail address I used for signing up, and in the end support would let me transfer the e-mail address of that account to one of my e-mail addresses. This could have caused me to lose access to my account if it had been an attacker).
It also has an additional characteristic of offloading the responsibility of account access to the user. Didn't sign up properly and lost access to your device? Too bad! This would swing the other way, leading to disgruntled users not getting their accounts back. As I said before, you really have to pick your poison here.
For more technically apt users, you can also allow setting a password, setting a second factor (SMS, TOTP app, FIDO2 key, etc.). While this increases complexity on your side, it has the advantage of enabling technically apt users to secure their account from third-party access. (And making it more likely they lose access to one of their factors).
In order to prevent social engineering, you can also ask users questions about their account, which they should be able to answer:
- When did you last play?
- What device did you play on?
- How often did you play?
- Who is your most-used character?
- When did you last spend money on the game? If so, can you send us a receipt of that purchase?
For example, I would be able to answer you all these questions for a mobile game I am playing. For an attacker, however, these would be quite difficult to answer.
An exception to this is streamers, who stream most of their gameplay. As their viewers would of course see when they would play, how they would play, etc... Although in such a case, support may have good ways to deal with people trying to steal "popular" accounts.
Other Authentication Schemes
For the sake of completeness, I'd like to discuss some other authentication schemes I have come across:
Guest Account Only (Device ID bound)
There is no way for users to "register". Their account is tied to their device and if they lose access to the device, they lose access to the account. Not ideal, but I thought I should mention it.
Guest Account Only (File-based)
Similar to the above, but the "ID" is written to a file on the device. It could be a private key, but most likely it's just a really long random string. By backing up that file, users back up their identity. While this "works", it is basically impossible for non-technical users. Your users are also only one oopsie away from permanently losing account access if they don't back up their accounts.
Username + Password Sign-Up
The classic username+password combination. It's widely understood by the vast majority of users. Pick a username, pick a password and optionally enter an e-mail address in case you forget your password. The advantage is that most users understand how that works, but with the downside of people generally picking really bad passwords. Like, how often do you think the name of the game will be used as password? A lot.
"Transfer Code" + Password
Very popular in certain Japanese gacha games, users receive a "transfer code" upon request. A random string looking like
BF62-HS01-GG52-OP87, together with a password set by the user. The idea is that users keep that transfer code safe (writing it down or more likely sending it to themselves via e-mail) and if they need to access the game on a new device, they enter that code and their password. For the developers, this works, because it's minimal overhead, while for users it's clunky and there's always the fear of what if you lose your transfer code?
Also very popular in the mobile game sphere, authentication can just be offloaded onto the OS provider. For example, Google offers a "Sign in with Google Play" option on Android, and I am certain Apple offers something similar. It's very likely users will already have such an account, so authentication is rather easy. However, some users may be unwilling to connect any game to their Google or Apple account, so you may have some resistance from users.
Defrauding Account Sales
Most ToS explicitly forbid sales of accounts, so it's usually not in the best interest of developers to make account sales easy. In fact, the more dangerous for buyers it is, the less likely there is a market for game accounts. If anyone could easily defraud you, you likely won't spend money.
There is no silver bullet. You have to weigh account availability against confidentiality. You can offload some of that to your users by letting them decide how secure against third-party attacks they want to be.
Asking players for information only they should know could be a good idea against account theft.