[Request for interest] Safe / lockables key encryption.

[RimBlock]

This is a request for interest / discussion on a mod I am considering which will encrypt the safe / lockbox codes.

 

Currently there are utilities people can use to crack safe codes and admin tools / hack scripts which can show the characterID values (where the codes are stored) to a player.

 

Based on an automated utility entering a code every second, a 4 digit code could be cracked in under 2.7 hours, a 3 digit code in under 30 minutes.

 

I am lookig for ways to encrypt the code value stored in the DB and to make it decryptable only by the server.

 

Goals

1. Stop automated cracking of lockable codes.
2. Stop hacker tools seeing lockable codes.
3. Minimise sever perfomance impact of implemented solution.
4. Automate the process as much as possible (within ARMA II engine limitations).
5. Allow player self service to reset their own lockable items codes.
6. Implement a max tries function before unlock required by admin or self service.

 

Current ideas are

• Encrypt the key chosen by the player based on a static value stored in a server side variable.
• Base the variable number on the first PlayerUID in the database (converted to numeric).
• Re-encrypt all codes on a weekly bases with a PlayerUID chosen at random from the character_data table.
• The code validation would be server side with only a true or false being returned.
• The variable would be stored in server side files (possibly variables.sqf) so no custom DB tables needed.
• The variable would be stored in server side files so no client side access.
• If the inventory field of the safe / locakable had a sub array added containing the builders PlayerUID then the builder could reset their own code (validation check based on stored PlayerUID and requestersUID).
• The auto owner reset code function could also enable a 5 tries and it is perma locked until rest automation taking load of server admins.

Challenges

• The server variable would need to be changed manually with the new playerUID after the re-encrypt and the server rebooted. 
• Validation that the serverside variable could not be accessed on the slient.

My knowledge with scripting is limited but growing daily.  I am very happy to collaborate with others on this if anyone wants to help and these are just a first round of ideas so please chip in if you see any issues or have better ideas.

 

I am currently working on my so will not be starting this for a while but now is a good time to get the discussion going to thrash out any issues and a fairly robust framework / structure for this mod.

 

Collaboration is the key so please get involved and let me know your thoughs / alternative solutions.

[SilverWind252]

This is a damn fantasic idea! I'll be watching this closely. 

[hambeast]

While an interesting concept, I have a couple of problems with this as an admin.

 

1. A hacker will be able to bypass this pretty easily if they can execute scripts.  why wouldn't they just animate the door open instead of entering the code?

2. As an admin, it is helpful to have a key to tie an object in the in game world to the database.  While a 3 digit code is extremely limited, it is still nice for me to be able to look it up and change it at the database level on one factor alone.

3. Server impact.  Making a server-side system to handle door codes will just put more stress on the server.  Servers with large object tables area already slow enough. Having a server side handler for door code generation/validation might not put too much stress on the server but there will obviously be some overhead.

4. How are players going to enter codes?  Are they going to have a key fob that generates a random sequence for them based on the time?  Are they going to just get in with their characteruid?  Say I have 10 doors in my base, I use a spreadsheet to track them, now the values are going to change randomly, how do I keep track of this?  how do I keep my group updated with the new codes?

5. New Hive DLL.  Do you have the sourcecode for the latest hive? If so can i have it :).  Unless you plan to use the existing character_id column and its limitations, you'll need to implement something new to work around this.

 

Here's how I "solved" this problem.

 

1. Added 3 strikes rule.  After 2 unsuccessful tries, the user is given a warning that if they continue they will be slain.  On #3 they are killed

2. Logging:  Any time a door code is entered, it gets logged either unlocked or a bad combo log.  When an unlocked door is opened this is also logged.

3. Implemented a rule regarding not accessing doors in bases you don't have permission to acceess.  With logging, it is easier to see who did what here.

 

Rule #3 is mostly a catch all.  I hate making arbitrary rules but we have people exploiting glitches to bypass the anti-brute force methods we have in place above.  At least with logging, we can see who got in and how.

[RimBlock]

While an interesting concept, I have a couple of problems with this as an admin.

Good points addressed below.  Got me thinking about authorised parties.  Thanks for the reply.

1. A hacker will be able to bypass this pretty easily if they can execute scripts.  why wouldn't they just animate the door open instead of entering the code?

1. How do you prevent this and why could the same technique not be used to prevent it as part of this suggested solution ?.

2. As an admin, it is helpful to have a key to tie an object in the in game world to the database.  While a 3 digit code is extremely limited, it is still nice for me to be able to look it up and change it at the database level on one factor alone.

2. You can tie back to the object in the DB by objectID and you would have access to the encrypted key which would be the same in the DB.  The difference is the method of authorisation being controlled by by a server side function to validate, not just on matching a client side number to a DB value.

3. Server impact.  Making a server-side system to handle door codes will just put more stress on the server.  Servers with large object tables area already slow enough. Having a server side handler for door code generation/validation might not put too much stress on the server but there will obviously be some overhead.

3. I can foresee 2 server side functions accessible whist the server has players on it.  

• The first will take the player entered code and object (most probably cursor target).  It will get the stored encrypted code from the object data and perform a simple decrypt (to make it simple lets say it will minus the server side value).  It will then compare the result with the player supplied code and return true or false depending if there is a match or not.
• The second will take the playerUID (characterID dep on server setup) and validate the player as the safe owner and then re-encrypt the key (for simplicity sake lets say it will add the server side value to it).

The strength comes in the fact that the server side value is randomly generated on a weekly / bi-weekly basis and the keys are re-encrypted using the new value server side during a restart when no players are logged in.

4. How are players going to enter codes?  Are they going to have a key fob that generates a random sequence for them based on the time?  Are they going to just get in with their characteruid?  Say I have 10 doors in my base, I use a spreadsheet to track them, now the values are going to change randomly, how do I keep track of this?  how do I keep my group updated with the new codes?

4. Same as they do now.  The solution is completely transparent to them apart from the fact they will get a self service option to reset the code if they are the owner of the item.

5. New Hive DLL.  Do you have the sourcecode for the latest hive? If so can i have it .  Unless you plan to use the existing character_id column and its limitations, you'll need to implement something new to work around this.

5. No hiveext.dll changes would be needed.  The inventory field will have another subarray embedded (the same as the tagfriendly does in the character_date -> current state field).  The field is longtext allowing over 4 billion bytes so is not an issue at a DB level.  The data can be accessed in the same manner as the tagfriendly system gets the data from the currentstate field.  There would be no requirement to convert the varchar playerUID to numeric for the characterID field meaning there is no risk of the result of the conversion being non-unique.

 

Current Inverntory field structure = [[Weapon][quantity],[ammo][quantity],[backpack][quantity]]

New inventory field structure =  [[Weapon][quantity],[ammo][quantity],[backpack][quantity],[ownerID][encrypted lock code][permalock],[authorised access playerUIDs]].

 

If permalock is set then the item would need a code reset (owner or authorised parties self service).

 

A one time alignment would need to be performed for lockables as part of the install and from there onwards the code will add the new subarrays when the items are built. 

 

The lock code is never in the clear on the client side or DB so hacker tools scanning the object data will not reveal the lock codes.

 

The security lies in the server side value changing regularly and hackers only getting 3 or 5 attempts before lockout.  The only manual step at this time would be for an admin to change the server side value in a config file unless someone has a way of doing so automatically.  Maybe a batch file randomly selecting a character_data playerUID then inserting the value in to a new variable (new_code_value).  If new_code_value <> current_code_value then run the re-encode function on server start then change the new_code_value to current_code_value and clear the new_code_value (probably via batch file again).  If the code change in the config files is not manual then some thought would need to go in to automating it.

Here's how I "solved" this problem.

1. Added 3 strikes rule.  After 2 unsuccessful tries, the user is given a warning that if they continue they will be slain.  On #3 they are killed
2. Logging:  Any time a door code is entered, it gets logged either unlocked or a bad combo log.  When an unlocked door is opened this is also logged.
3. Implemented a rule regarding not accessing doors in bases you don't have permission to acceess.  With logging, it is easier to see who did what here.

Rule #3 is mostly a catch all.  I hate making arbitrary rules but we have people exploiting glitches to bypass the anti-brute force methods we have in place above.  At least with logging, we can see who got in and how.

The logging is clearly needed in any solution.  The management seems very admin intensive though.  How does the admin know who the owner of the lockable is or do you keep a list of all lockables álive' on the server and compare when they get an unlock request ?.

 

There seems to be no mechanisum for non-owners but authorised parties to request a code reset.

 

The solution relies on the player having to get hold of an admin to change the code.  That may be fine for your server if you have a number of admins available over a 24*7 period but for others who do not, a more automated solution may be better.

 

Log files will still need to be checked and activity flagged as is standard with any decent setup but the amount of admin cerntric work is likely to be a lot less.

[RimBlock]

Ok, so having an ideas back and forth with OtterNas3 and we got to chating about this problem.  From that discussion I think there is a fairly viable way to secure the safes and other lockables codes without encryption.

 

The codes would be stored in a serverside array on object load and not sent to the clients (the characterID variable attached to the lockable will be 0).  The client will send the code to the server for validation.  Nothing changes in the data stored in the DB for the object.  The code is still saved in the characterID field where admins can view it.

 

Adding the animation for unlocking (good old medic anim) and the ability for the owner to reset the code via self service and we should be good.

 

I will be having a look at this very shortly (maybe start the design and coding next week).

 

RB

[hogscraper]

Seems a little like over kill. We use a script on the server I play on that gives a player (random 4)+3 chances to get it right or it teleports them to the middle of the ocean. Funny that over night we didn't hear about bases being mysteriously invaded in the middle of the night any more.

[RimBlock]

I tend to prefer to run a more realistic (ok, where possible) server so shy away from teleporting, banning etc unless the person is doing something that would not be possible in real life. 

 

Sitting there trying multiple combinations is valid.  It can be done in real life.  Speed dialing the combinations via a keypress simulator is not and so introducing the medic animation between tries will help to close that problem off without putting in a limit to the number of tries.  TBH if someone wants to waste their life trying all 999 combinations over X hours (ok, only 2.7 hours max with a 10sec delay between tries) to get in a door in a computer game then at least it keeps them off the streets ;) .  So all you people with padlocks with only three tumblers, a thief could get it open fairly quickly just trying the combinations in sequence.

 

Safes can quite reasonibly have a valid number of tries before needing a reset.

 

People using various scripts / tools / hacks can look at the codes for doors / locks and this is what this enhancement is designed to stop.

 

If you are going to teleport them then maybe make it entertaining.  Zombie pit at Stary with broken legs and they respawn on death as an undying zombie.  I hate respawning as a zombie :) ...