Good reason for this:
Verify op with a password the server owner only knows. If the password isn’t entered in time, the player is not given op. -Feature 1
Verify a user’s account security by having an extra layer so that hackers can’t bruteforce into an admin’s account - Feature 2
Lock your account’s op privileges with a password if you’re lending your account to someone YOU know in REAL LIFE or someone you TRUST! -Feature 3
Authentication plugin doesnt , and cannot validate a lot of things that the auth servers do. ‘Literally the only thing changed is connection to the authentication servers’ It checks if the account is valid and gives you a UUID. This is needed for multiple things such as actually banning a user from a server, making sure a user name cannot crash your server, preventing impersonation, and, actually supporting username changing.
As well, as you know, having people actually buy the game they are playing.
@Lokio27
Dont give /op to anyone but the server owner. No one else can /op.
If they can bruteforce your MC password, they can bruteforce your auth password. Make your password strong.
Why are you giving someone else your account? You say you trust them yet you are locking your permissions. Sounds like you dont trust them and they should use their own account.
2 Likes
Still, this plugin will have its uses, but at the moment there isnt too big of a reason.
UUIDs broke offline bode, as far as I’m concerned.
I turned a testserver into offline mode and every user that connects has the same “nulled” UUID. It’s just 0000 etc.
So i guess the UUID’s broke offline mode but in my opinion this can be workarounded with assigning each connecting player a UUID that matches his name via UUID.randomUUID() and save it somewhere so it can be retrieved later. This would break of course when you turn it later into online mode.
I wouldn’t do UUID.randomUUID(), but create an md5 sum from the player name. Awkwardly enough it contains enough characters to make an uuid. I used that in my UUIDcache service for playernames that don’t have a valid uuid (for example: “[BuildCraft]”).
Just have a special entry for offline-mode users so that their labeled by username instead of UUID if that is never fixed.
backwards compatibility between legitimate users and “cracked” users should be taken under consideration.
If the server’s in offline mode, the players, if enforced by the owner, set a password on inital join.
Doesn’t the server generate the UUID based on the username spoofed by the client?
But it’s a version 4 UUID.
With API:
When a player’s data is saved, serialize the player to a custom location based on their auth’d account.
Then delete the default saved data to prevent dupe bugs.
When a player logs in they newly spawn in a dimensionless jail, able to do nothing until auth’d then they get replaced with the data of the player you serialized.
Without API:
Use a UUID that does NOT match the range of UUID’s that offline servers use (or online servers for that matter)
When a player joins, take them to a jail/unusable world. remove chat, and all join notifications.
When a player auth’s “kick” them and “reconnect” them to the game with a new UUID that belongs to the auth’d account, save like normal.
With BungeeCord or similar:
Take players to a lobby server where they need to auth with bungeecord, bungee then gives the connection to the game server and provides a fake UUID for the server to use for that player.
In all honesty brute forcing a password is the worst way to go about gaining access to somebody’s account. It could potentially take years to do not to mention be very taxing on the setup running the actual brute force. Personally a dictionary attack or phishing email linking to a “mojang” login site is more efficient.
If somebody really wants access to your account that badly they’ll get it.
Brute forcing minecraft authentication (usually using dictionary based attacks) has certainly happened in the past before Mojang rate limited the API properly.
But necro was referring to brute forcing the auth password, not the mojang account password, which unless it has a similar cooldown restriction or captcha may end up being easily hacked.