Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Don Y Newsgroups: sci.electronics.design Subject: Re: German state gov. dicthing Windows for Linux, 30k workers migrating. Date: Mon, 8 Apr 2024 08:53:11 -0700 Organization: A noiseless patient Spider Lines: 154 Message-ID: References: <5qb31j9c2ia9a6h2fr50onqa2vp4d4bsfm@4ax.com> <3hf31j9d0uq5b9imcq94b495c3hclbjv79@4ax.com> <1qrnmxu.99joma1j6s84iN%liz@poppyrecords.invalid.invalid> <1qroud8.1ot9y7y1yrh1ywN%liz@poppyrecords.invalid.invalid> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 08 Apr 2024 15:53:17 +0200 (CEST) Injection-Info: dont-email.me; posting-host="8be94720f6ad45a0802650285e910a01"; logging-data="3780788"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+kltNYScCi/ExuUaHHj7ns" User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Cancel-Lock: sha1:L0XnnDDS7mWvinLIrIF6vCAuNsU= Content-Language: en-US In-Reply-To: <1qroud8.1ot9y7y1yrh1ywN%liz@poppyrecords.invalid.invalid> Bytes: 8934 On 4/8/2024 1:38 AM, Liz Tuddenham wrote: > Don Y wrote: > >> ... It costs relatively little to probe (and fingerprint) >> every accessible IP. Then, throw a set of exploits *already* deemed LIKELY >> to compromise such a system at it and note the results. The process can >> be automated (and likely would be given the sheer number of potential >> targets!) > [...] > > I was thinking of a slightly different approach from the usual one. > With automated coding and decoding it is a relatively simple matter to > concatenate various processes such as: > > Direct encipherment > Rearrangement by character or block > Insertion of dummy characters > Codes > Languages > > Each of these could be broken individually, but used in succession they > become much more difficult. This would be a system that was suitable > for small organisations where the daily arrangements could be > distributed by a separate communication -- for instance: > > Today: Shift by 5 letters - Reverse each block of 11 letters - Insert a > random character every 3rd and 17th position - shift back 7 letters - > Represent every 19th letter with it's Vail Cipher equivalent - Arrange > letters on a 12 x 12 grid in rows and read them out by column. > > Tomorrow: Double a character every 7th position - Arrange letters on a > 10 x 19 grid in rows and read them out by columns -Represent every 13th > letter with its ASCII equivalent -Reverse alternate blocks of 11 > characters - Shift back 3 letters - Add a random character every 12th > position - Arrange letters on a 9 x 17 grid in rows and read them out > by columns > > Anyone trying to break into the system, even if they could guess at some > of the elements or intercept one of the distributions, would be faced > with a lot of work for very small returns. The elements could be > changed around and new ones added to the repertoire quite easily. Where is the cleartext version stored? Or, are you perpetually re-recoding the data (so the cleartext never exists on the store)? Are you relying on some third party in any way (in which case, his system expands the attack surface). What happens if I hack your system and mirror your display elsewhere? What if I coerce some staff member to telling me something they shouldn't (by claiming to be someone's little old grandmother who forgot his phone number, birth date, etc; "Could you please give it to me, Deary?"). Or, some stupid staff member who doesn't realize that it's NOT a good idea to send around a memo to the department staff with a list of every employee's birthdates. (SWMBO had to intercept a memo that listed every department member's SSN! What idiot thought THAT was a good idea?) Is there a way to pass information OUT of your organization? How do you ensure that cleartext is always re-encoded before being distributed to other parties? After all, the people who consume that information need to see it in its unencrypted form... Plus, security is more than just protecting your secrets. What if I prevent you from accessing that store -- by deleting it, encrypting it (with MY key), or simply eating up the bandwidth that you need to access it? Or, the early days where the adversary's goal was just to crash your system or render it unbootable. Clearly, these aren't activities that you would WANT someone to be able to undertake; you would want to *secure* your system AGAINST them! [Hard to imagine anyone NOT running a web browser and using "web apps". How secure is that option? (Firefox is ~20+M SLoC!) MULTICS was considered "bloated" inspiring the creation of "UNIX". MULTICS was ~300K SLoC; Linux is ~50M SLoC! How many millions of lines of code are involved in your accessing this USENET post?] I've protected my *switch* from folks wanting to impose "lightning strikes" on the "exposed" network drops. Because failing to include such protection would mean a key component (the switch) could be subverted from a single attack point. My neighbor's alarm system is completely wireless (selling point: no nasty wires to run through your home). But, I could (illegally) subvert it with an RF jammer. Of course, the legality of that jamming wouldn't bother me if I was already intent on breaking the law to steal from him. >> Can you enumerate all of the potential security vulnerabilities that >> you *have*? Today? Tomorrow?? > > No, but I can make life very difficult for would-be hackers in the hope > that they will turn to easier targets with better rewards. For some "Standing out" is one way to get hackers' (i.e., individuals) attention. "Why is this person/entity going to such lengths to make their systems/data so difficult to access?" You won't fall to a boilerplate attack but may merit a *focused* attack by someone who looks at you as a "challenge" (and, possible harbinger of new defenses to which they will have to adapt). Being different also sacrifices anonymity (presumably, privacy has SOME value to you). When I had a non-stealth server, I did my best to hide its configuration by changing all the banner messages, etc. Of course, that made it stand out -- because it WASN'T one of the (relatively few) known system characterizations at the time. [I also learned that these obvious changes don't prevent the system from being identified as there are all sorts of characteristics that can be profiled/fingerprinted to deduce what's running, there] > years I have had to store databases of personal information on computers > that are connected to the Web, so I have given the problem a lot of > thought. Without access to the decoding programs (which are in an > obsolete format running on an obsolete OS) there is little chance of > anyone else decoding the information. So, what do you do when *I* encrypt your encoded data? Or, bring down the (remote) system that is hosting it? You also would be surprised at how much information "leaks" from naive encoding strategies. E.g., if you know (or suspect) the format of the content, you can often deduce the coding algorithm. E.g., sign up for your service and then watch to see how you store my information "remotely". Now I know what that information maps to. Or, go hunting for something that I know (or suspect) is already encoded in your data. And, I know the distribution of letters/words in prose, names, etc. History is littered with failed encryption/security algorithms that seemed to be unbreakable. Because people rise to the challenge of subverting them! ("That's where the money is" -- Willie Sutton) Who'd have thought of breaking into a vehicle's CAN network (by forcefully removing something easily accessible -- like a headlight!) to impress the "Unlock doors" command on the bus? Gee, maybe you should design the system so it doesn't blindly assume every message is legitimate?! Intentional reprogramming of pacemakers? (Why would anyone deliberately do that?) Airline flights? What are the chances "one of many" solutions has addressed all of the vulnerabilities that affect its implementation?