[PR] Airlock packet protection, take two

[github_bot]

PULL REQUEST DETAILS

[balance] [input wanted]
About the PR
Packets controlling an airlock now need to contain an `access_code` field that matches the door's internal access code.
This code can be found out by either bruteforce or by unscrewing the access panel and looking at a tiny display inside.
Currently the code is randomly generated number between 1 and 32.
The code has a chance to get scrambled when pulsing the AI control wire.
Providing incorrect code has a chance to make the door beep and blink red.


Why's this needed?
Currently packet hacking is a bit too powerful. Arguably easier than wire hacking, possible to automate, possible to do remotely, fast, impossible to detect after the fact and hard to detect as it's happening.
This PR forces you to either bruteforce it which will make the door blink and beep a bit and will take some time. Or you will need to unscrew the access panel to get the code that way which means interacting with the door manually.

I'm considering making the 1-32 range different for different "importance" of doors or maybe straight up not having the display visible on the unscrewed access panel on some doors (armory? head-level acces?). Let me know what you think of that.

Changelog

Code:

(u)pali
(*)When using packets to hack airlocks you now need to provide access_code. You can either guess it or read it from the wire panel.

PULL REQUEST DETAILS

[moonlol]

I like this, a reasonable nerf and only really impacts the automatic door openers

[pali6]

Alternative idea: have the access code be binary, something like 10101010 and depending on how important the door is you might have some of the binary digits obscured so you'd see 1010*10*1* on the armory door for example.
I'd like some way of making different tiers of security like this.

EDIT: Nevermind, that'd prevent mechcomp hacking compeletely and I don't like that. Maybe important doors not providing *exact* number but just an estimate?

[jan.antilles]

Agreed, this seems really great. Very targeted and reasonable.

[Varali]

For the different Security tiers, maybe you could have the 32 number range "shift" up and down and the panel only tells you the 32 number range that the code is in? For example, you open the Armory panel and it says "22-54" while the code is 45. That way you can't hack important doors without first checking the panel to see where the range is? It'll stop bruteforcing though, unless you want to cap it to like 128 and have people test every single number, making a bunch of noise that makes it obvious what's going on.

[aft2001]

I very very much so enjoy adding SOME kind of network security and this is a nice and simple solution and would be happy if it were merged! I'm sure it's well known but packet hacking is both too fast/strong and also just boring. It's just copy/paste, follow the same instructions, and boom you're done. It's stupid and bad.

I would also like some puzzle-type stuff, like Pali suggested with the missing characters, that would allow you to more quickly brute force things, if you can get the RegEx and MechComp systems for it working unless you wanna do it manually.
On a similar note, could there potentially be some other puzzle-locks? My first thought is to jump to mathematics, possibly with some form of numerical encryption that would make bruteforcing much harder as you'd have to process it all either manually, or with a MechComp system able to perform a function calculation, somehow. I'd *love* to be able to sit and piece things together, solve for variables, and/or do other nerd puzzle math shit to hack open things.

If the math route is chosen, then I propose the following probably-crap-but-maybe-workable idea:
An airlock would require the access code to open. The access code is, as per this PR, randomized and must be brute-forced. But, an airlock could, if provided with a specific keyphrase (probably netpass_heads), return a couple numbers and characters. It's harder to explain what I am getting to without an example, so here is one. The airlock would return a string saying "C 92 5". In this context, C refers to a Function, C(), in the mathematical sense. The function that is C is stored somewhere, along with A, B, D, E, and F or however many functions you want. The actual functions themselves would be pre-made, but their label is randomized. Say that C(x, y) = yx^2 - (y+x). The airlock is thus requesting the value of C(92, 5) before it will unlock. An airlock's function and values would be randomized on roundstart and whenever the access code is reset.

The purpose of this is to allow for contactless silent hacking with the caveat of requiring a lot of existing effort and time investment in order to achieve. Additionally, for an added security measure, the functions' labels should change at random. Hell, maybe don't even store the functions somewhere, have people have to figure them out by hacking a door and trying to bruteforce it by trying the existing several functions. Unfortunately this would require the netpass_heads to be more difficult to acquire to make secure.

[Studenterhue]

Merged just yesterday. Barring a minor rename of a define, it's about same as described in the original post: hacking doors via packets now requires sending an access code. It can change when the AI control wire is pulsed, and for now it's simply a random number between 1 and 32, rather than the math ideas.

Pali has said on the PR discussion that he's willing to make access codes on important airlocks more difficult in some way so please make a thread or direct feedback his way if you desire such.

I think I'm gonna try this version and maybe increase difficulty on important airlocks later based on feedback for this.