Unique Identification

[Chaos13]

Is there a way to get a really unique variable from client which cant be easily changed? IP banning \ adminframing \ identification is unsafe because of dynamic IP addresses so the var unique to each player is needed!

[Bane]

for bans your best bet is probably comp name. It can be changed easily in most situations, but it should be able to catch at least a few people with dynamic IPs who don't know how to/are too lazy to change their computer name. IP address is honestly the hardest thing to change that can be used to forcibly identify someone. I've heard that some people can ban based on MAC address, which can't be changed without getting a new ethernet card, but there's no variable in UScript for that so I have no idea how they do it, if they can and aren't just bluffing.

If you're trying to identify people for admin purposes (I assume that's what admin framing is. Not familiar with the term), the admin password should be enough. If it's getting leaked, you're misplacing your trust in people. If it's getting stolen, tell your admins to not join other servers with the password field filled in, or however else it gets stolen (if keybinds are being read, storing the password in a .txt file and logging in by execing it works, while still allowing the login to be bound to a key). A final option for admin-restriction is to make clients need a non-downloadable client-side only package. That's how my adminmag works; All of the clientside code, including all of the exec functions, is stored in a file that is not present on the server, making it so I'm the only person who can use it, even if others have admin in my server.

[TCP_Wolf]

Computer Name alone should not be used under any circumstances. Many OEMs preinstall customer PCs and they all have the same name. Also, many lazy people even use identical names by accident such as HOMEPC, or just PC. In effect you will get a lot of false positives... "a lot" being relative of course.

[Chaos13]

"Admin login framing" means limiting admin login to a predefined variable (like IP, ID, w/e) and i can easily change my network address by just running Registry Editor... only @#$%s buy a new card just to change MAC... anyway i heard some gametypes generate 3-4 unique IDs for each player... wtf :question

[Bane]

IP would be the best and easiest way to do the admin framing. If you;re hosting the server on the same machine and only want yourself to have admin access, then you'd just have to limit it to 127.0.0.1 and always join your server that way. Otherwise just set up a list of allowed IP addresses and modify login in gameinfo and any exec commands to only allow players to become admin if they're on the IP list. This would, of course, be a problem if your admins have a frequently changing dynamic IP, but it isn't as bad as banning a dynamic IP address because they obviously won't deliberately try to change their IP. Since you do seem to have that problem, though, all I can really think of is adding a randomly generated number/string to some config file for every player (see something like ScoreRecovery for an example), and use an allow list for that. Honestly though, it'd just be another password, only one that couldn't be guessed. If your admin is getting stolen or leaked then it will not solve the problem.

Another approach I've seen done in multiple usernames and admin passwords, but I've personally never found a use for it. My method of putting all clientside admin code into a separate package could help, but it'd be a pain to make it restrict anything other than custom admin commands, so the use is quite limited.

The problem is that IP is the only thing I can think of that players can't (always) change on their own. Banning based on something that a player can arbitrarily change is obviously worthless, and giving admin based on something they can arbitrarily change is just another password.

[Chaos13]

Well DCoop already uses UInfo system:

Code: Select all

struct UserInfo
{
var() config string UserName;
var() config string PassHash;
var() config bool   bFrameIP;
var() config string FramedIP;
var() config bool   bFrameID;
var() config string FramedID;
var() config int    UserLvl;
var() config bool   bActive;
};

[glow=yellow,2,300]*Notice that it uses MD6 hasher and stores password as hash rather then normal password - password stealing impossible because password->hash is transformed server side AND my MD6 algorithm has Anti-Bruteforce protection (all shortcut brute algorithms dont work on MD6 and there is no bruteforce program for my MD6)[/glow]
Anyway WOLF said that many computers can have stupid predefined identical names what do you think should i just disable Admin ID framing in UInitUserCreation [ID] [MaxLevel] and Banned ID framing in BanID [ID] [optional int TempMapChanges] (just use IP Ban and allow IP ULogin Framing)??? I am starting to think more and more that i should refuse to use IDs generated on computer name, i need some more reliable method to generate Unique ID :exclamation :exclamation :exclamation

[Bane]

Personally I don't see the point of admin framing. Maybe your circumstances are just different from what mine have always been, but I've never had to restrict admin access through anything greater than the admin pass. I don't even use strong passwords (used "qwerty" for about 3 years), but that's never mattered because no one has ever once tried to brute force it or anything. I only give it out to people I really trust to not leak it. If you have a problem with passwords being stolen; how are they being stolen? My experiences with password theft come from people reading the ?password= line in serverlogs and scanning keybinds for login commands (TONS of accusations of that in INF servers using UProtect a while ago). Hashing the password wouldn't help there because it'd be plaintext in the binds/password field. Are you having trouble with packet sniffers or something?

Anyways. For admin framing, it looks like you added a var to turn off the IP check for a specific user. You could just always turn it off for anyone with a frequently changing IP address and leave it on for everyone else. It wouldn't be ideal, but it would be somewhat better than completing leaving it off, since you seem to want the feature so much. For bans, IP range bans are always a possibility. the unreal community is small, so the chance of banning a second person accidently is pretty small if the range isn't huge. Again, I don't know of any better way to identify a person other than their IP, and no one else has said anything so I'm guessing there just isn't one.

[Chaos13]

Nice idea about bans and framing, Bane, and Lol at your qwerty... I think 227 should have protection against remote 'get input' commands! I mean 'get input' commands which are executed from functions which are replicated from server to client :exclamation :exclamation :exclamation

[Bane]

adding 'get' as an alias will do the trick. There's rarely any need to use get in the middle of gameplay unless you're testing some stuff by yourself, so it shouldn't be very harmful. Storing passwords in text files, or better yet not binding them at all (I do both. manually typing 'exec login.txt' isn't hard) will stop passwords from being read and there's rarely anything else of interest. I highly doubt there'd be any way to actually detect if consolecommand() was called by the client or by a replicated function from the server

[Chaos13]

Well i can do that get thing with ability to use it... MConsole's function bool ConsoleCommand(coerce string S); will disable get alias then exec super consolecommand then put it back ... This will defly tell clientside miners to GTFO including your adminmag and i will be still able to do get commands (i think i gonna use my own extended get command which does shitload of native rerouting )

Edit: tbh i think i should do same thing with Set

[TCP_Wolf]

adding 'get' as an alias will do the trick. There's rarely any need to use get in the middle of gameplay unless you're testing some stuff by yourself, so it shouldn't be very harmful. Storing passwords in text files, or better yet not binding them at all (I do both. manually typing 'exec login.txt' isn't hard) will stop passwords from being read and there's rarely anything else of interest. I highly doubt there'd be any way to actually detect if consolecommand() was called by the client or by a replicated function from the server

Both EDM and UTF have client side menues that allow players to configure extra keys. Generally disabling set/get is not the way, but "set" already is restricted to set input anyway for online play... The UTF keychecker even DISPLAYS the set console commands being executed to the player if you use the key menu. I figure other mods like Infiltration probably use similar methods in their menues to set ammo reload keys etc...

I'm pretty sure the Unreal engine can distinguish if a function using the consolecommand was called remotely or locally but sounds to me like another can of worms honestly.