3 ms·
that's a shame but we're used to it these days I guess. if you want to do backdoor probably should do it better, something like port knocking to start with at
by ausjke 11y ago
that's a shame but we're used to it these days I guess.
if you want to do backdoor probably should do it better, something like port knocking to start with at least.
- stcredzero 11y agoif you want to do backdoor probably should do it better, something like port knocking to start with at least. Come to think of it, backdoors are fundamentally "security by obscurity". Or insecurity through obscurity, depending on your POV.
- roywiggins 11y agoKnowing the Juniper Dual_EC_DRBG constants were fiddled with doesn't help you actually snoop, since working backwards to the generating constant is computationally unfeasible. Similarly hardcoding someone's SSH public key isn't going to help anyone else gain access just by knowing it's there, is it?
- Someone1234 11y ago> Come to think of it, backdoors are fundamentally "security by obscurity". Or insecurity through obscurity, depending on your POV. This one is. But they aren't always. For example, if a manufacturer put in a support/recovery backdoor, documented it, and utilised a secret that only the end user and manufacturer should know (e.g. something on the physical label), then that would be a backdoor while not relying on any obscurity for its security (or no more than a password does). The biggest difference between a "good" backdoor and a "bad" one is if it is documented. If the manufacturer is too scared to document it then it likely sucks and they know it.
- matt_wulfeck 11y agoAlso if you look at the complexity of the code, you'll know something like port-knocking would have had no affect (probably just an extra line in the custom handler). People that discover these these types of exploits each machine code for breakfast.