Combo lock and Safes/Lockbox crack possibility (1.0.4.2)

[m3nda]

After typing/setting code on lock/safe you can use ESC button to leave, if code is correct, option to open appear (so you can bypass limitations and speed up safe/lock cracking, combined with macro app its a real threat).

Problem is in dayz_combination and DZE_Lock_Door vars, you need to set a temp var while typing/setting a code (for combo locks i think it is in player_changeCombo), and set this vars only after unlock action or whatever.

Sorry for my english,

Sorry if it was here already, im new to github.

[JoSchaap]

that would completely defeat the purpose of using github.. issues should be fixed. not camouflaged..

[Namindu]

There was a video that was removed (not sure if the video was on this or not) but it had a link to a download, which uses a program to run a script to unlock codes.

[Darklordd]

also cheaters spawn vehicles with keys

[Markokil321]

I doubt anything can be done about the cheaters, except having alert admins and strict filters to catch a few.. However i do see this thing with the ESC menu to be quite game breaking.

[Darklordd]

I agree with u, but there are cheats that show codes for everything, thats why I wrote about cars with keys. It will be great if devs somehow rewrite code...

[RimBlock]

Two suggestions.

3 sec delay between code entry. Should slow down automated entry.

Randomise number button position on the keypad. Keypad position wwould then not equal the number entered. Easy for a human to work with, less easy for automation without some image recognition built in.

Possibly spawn a server side function to generate an array of numbers and the buttons they relate too. The clinet side then sends the input code and the server side validates it [yes/no] without ever passing the code to the client. Not sure on the feasibility of this one though.

[m3nda]

Server admins can add delays even now, there is no need to add it as "global feature".

Randomised button positions are not a solution, almost every screen capture lib has function for geting hash code of pixel region.

Server side function for hidden validation is always a best option, for better flexibility data like that should be in database.

[RimBlock]

I have not dug in to the combo lock / code pad code so bare with me ....

A delay can be set in the init.sqf variable ?.

Sure server side validation would be prefered but is there any encryption functions available in ARMA that are secure or would the Epoch team need to incorporate an encrypion suite as an addon .dll.

The current hive structure is also very limiting without adding in something like ARMA2NET.

Hmm, a 4 digit code could be brute forced in just over 2.7 hours based on 1 code / sec.

Firstly there would need to be a 5 attempts and then permlock requiring an admin to unlock or an alternative automatic verification and reset.

Secondly a players chosen code should be manipulated based on a server side defined value derived from the first logged playerUID (first run) and then re-encoded weekly using a randomly selected PlayerUID.

The server side value would need to be local to the server and manually entered after re-encoding but keeping this value out of the database could potentially stop the client having access without custom tables.

If the players playerUID was stored in an extra field (under inventory possibly) then it could lead to owners resetting their code if they forget it as long as the playerUID of the person requesting the reset matched the safe owner PlayerUID value.

The week point is that anyone looking for a way to decrypt the code will have the source files on how it is encrypted as it will be part of the server distribution. Data available in the hive is available to both cleint and server AFAIK.

[swiftplague]

Why not just do a simple if playeruid and safe code then unlock else !playeruid and code not unlock. would make safes player specific but would allow for total safety till a better solution could be found.

or set a sleep timer you can only use the lock once per 10 minutes if a player screws up on the combo he has to wait 10 minutes to unlock. the second solution wouldnt stop it but make it harder.

the other solution would be set a if playeruid then no need for code if !playeruid check for code if the wrong code is entered more then 3 times change the code but allow the player who placed it to change the code and also check the code with action menu.

this would make it easier on the player and more secure

[madrigo64]

this issue related to #963 also there I wrote how to fix the problem

[RimBlock]

@ Swiftplague,

Where would the playerUID be stored ?.

There is a _claimedBy variable linked to the object but have not dug through enough to see how its initial values are set and where they come from.

A 10 minute wait will be pretty harsh for legitimate players.

The third solution is again easier but relies on the playerUID being stored.

@skynetdev

Yes it is related but this also covers safes (vaults) as well. I have put a comment on the other issue report regarding locked doors.

I also have a thread on epochmod for discussing possible solutions although it is more aligned with encrypting the codes to stop scripters accessing them and being able to unlock items. It can be found at http://epochmod.com/forum/index.php?/topic/11507-request-for-interest-safe-lockables-key-encryption/

[m3nda]

Temporary fix (for safes):

add this to mission init:

http://pastebin.com/1kYv5LkC

side effect: player need to input code everytime he move cursor from safe/doors

[oiad]

@icomrade @ebayShopper

[icomrade]

@onnlinetool What is this file?

[oiad]

I'm guessing it's a spammer.