The org sells to a very niche luxury market and distributes a native application at a high price. The execs at this company are extremely perturbed by the appearance of cracks of the software that appear sometime after every release. The issue is that our present architecture as a native application means the attacker already has root and we cannot protect any key, there are also domain specific reasons why some users will always need to be remote at some point. While I want to encourage the org to eventually move to a client-server architecture we could protect, the need to provide the remote copies means all we can do is create puzzle boxes via security by obscurity, that are cheaper to unlock for an attacker (in terms of their likely hourly rate) than for us to create.
I believe they are over-reacting to the emergence of these cracks by pushing the dev team to introduce more checks into the software and thereby harming productivity and potentially even stability of the software while also failing to solve the issue. To give you an example of my fear; I was talking to one of our devs recently about a dependency issue where some extra license checks had been baked into the UI and I was encouraging better composition to extract these sorts of checks to a specific layer instead. They replied "but if we put all the license checks in the same place, won't that make it easier to crack?".
I appreciate this is probably a red flag and I should run but I believe myself to be a convincing person and I would like to try. They are a little old-school, so I feel like a gentle approach is necessary. For the most part I am wanting to attempt to reframe the issue from a "tech problem" to a "social problem" and focus less on adding more security by obscurity and more on tracking down where the leaks are coming from where consequences can be enforced via license agreements.
So I appeal to you all to help me with this endeavour. I imagine some of you have been in this sort of situation before, and have experience I could draw from, or might have knowledge of various sources I can use. The one that springs to mind for me is the issues that big online gaming companies have with aim-bots or other cheats in markets where the value of the hack is close to the zero and the resources of the engineering department trying to defend are high; to demonstrate the futility of the approach. However I worry a little, that given the old-schoolness at play that gaming might not be an example they will be receptive to.
Conversely, if anyone has any counterpoints or suggestions about low hanging fruit, outside of simple obfuscation and/or hardware dongles, this would also be appreciated, as it might help if I can also suggest something from their angle that beats the typical curve of severely diminishing returns.
v5v3•3h ago
Who hired you? Have you spoken to that person?
>I was talking to one of our devs recently
He or she isn't your dev, they are your clients. You are a temp.
bad_boomerang•2h ago
Its a little awkward, the chain of command is a little ad-hoc. So lets say the person who hired me is one of these execs. They were quite excited to hear about my knowledge of security which was dampened when they realised I was more talking about auth and securing endpoints as opposed to smth like DRM.
> He or she isn't your dev, they are your clients. You are a temp.
that particular detail is intentional noise. So sadly that advice doesn't apply.
Like I said, the attitude is so pervasive that I worry that it will interfere with the successful delivery of the product. That part, regardless of the noise remains pertinent.