Open FinalForEach opened 7 months ago
Any reason in particular you want to authenticate on the client, rather than use a cloud-based authentication server?
Any reason in particular you want to authenticate on the client, rather than use a cloud-based authentication server?
I am weighing all possible options here, if an account system is superior, I will go with that instead
Okay then. I could be missing something here, if so please correct me.
It's a bit strange that you're defaulting to re-inventing an auth system on the client. Usually in these scenarios, games use an authoritative third-party auth system. They're extremely cheap and don't charge you unless you have a considerably high amount of player traffic each month. I'll use Microsoft PlayFab as an example.
How this works is that the client logs in by providing a username and password, which are then sent to Microsoft's servers via the free and publicly available PlayFab REST API. These services also provide features like F2A, if you're interested in enabling that. The server responds with a success or failure message. The success message contains everything you might want to identify a user, and you can then request application-specific data, player statistics, etc.
There are also sign-in options that take a user's Steam ID, Itch ID, or some other platform ID depending on which launcher the player is using to launch the game. These different platform IDs are stored in the player's auth profile on Microsoft's servers, allowing them to be linked across platforms. This means that players can log into their account on any device or launcher without storing any data on the client. This seems to solve at least one of the two potential problems you listed. The other one is a security problem, which may or may not be relevant to these third-party systems, I'm not sure.
Does this sound like it's headed in the right direction for this particular game?
User can log in from 2 different devices as long as device ID was not used for hashing password and hash is not stored on user device... You just need to generate password salt and have it stored server side, it would be safer to have server generate secure connection for sending passwords(possibly via ssl) and have it store user password hash on server cause server is less likely to be breached than user device.
Storing password on user device could be done via password protected file or password protected string, where password to unlock it is set of device unique data... Example from library called DeviceID I once used to get password for user device
DeviceIdBuilder().AddMachineName().AddOsVersion().AddMacAddress(excludeWireless: true).AddUserName().ToString()
Then you can encrypt password locally with 2/3 different encrypting codes, to decrypt you would need to run it in reverse order.
So called Account "black market"
would be per server... cause people in theory can steal/sell their accounts when they are bored with X server...
There is stuff like social engineering and etc...
You could have server give out basic API for users to create server websites for handling auth and user profiles.
it could fix issue of hashA
being stolen if server has implemented all stuff correctly on their end...
It would be best to have DB be something simple, I mean something like mysql/mariadb(PMA) or mongodb, I recall they both have available fairly easy db management panels... There is project called Pocketbase I think it is great little DB, mainly having admin dashboard in mind... Also remember you have healthy modding community, I bet even if you didn't do that there would be people coming up with solutions for it. I recall in mc if you lost your pwd you would go to server preferred communication platform and ask admin for help, then most of the time admin would give you couple questions and if you passed they would reset your password, also if you were friend with admin they would just go and do it without questions...
my idea on this is to use a blockchain,
any domain may have is own blockchain to keep records of user's account that been created. players that are starting up their game will tell their domain to login & provide player's IP address & account for server authentication. servers/players may op in to any domain to use their blockchain to auth users, servers may also extend from a block that hold info about that user if they were ban/op etc. blockchain may be cache onto the servers that has op in.
This allow people and server owners to auth their own players if something were to happen to the main domain or the community manage their own domain for the public or for their own server. as well for server extend block is a way to show history of an account. lastly this show who own an account, allows same name to be use, and give information on non-legitmate(hackers) players.
depending on the the licensing this could be use to forces centralize auth domain.
A possible system would be users sign up for a name server , and can login to any server as for example user#nameserver.com , while other users can join the same server using an account from a differnt nameserver.
Pros: Decentrailized (no username black market, no single person / group in control) Cons If a nameserver goes down, everyone cannot login anymore
An account system may not be needed, if authentication is per-server instead.
Usernames are required for servers to store player information server-side, which can be important for servers that don't allow cheating.
Possible system:
hashA
hashA
and salt is made for every server connectionhashA
, now calledhashB
hashB
to the server via encryption, so that only the client and server know abouthashB
.hashB
with stored value ofhashB
, made during first connection, and if matching assign the username to the player, otherwise disconnect. If no value was stored, grant the username and store the value ofhashB
.Pros:
Potential problems:
hashA
is erased, how can the original player sign in again?hashA
is stolen? How can the real player invalidate it?