[Info-vax] What to do with my VAX.....

[seasoned_geek]

On Sunday, November 15, 2020 at 7:08:10 PM UTC-6, Alexander Schreiber wrote:
> Dave Froble <da... at tsoft-inc.com> wrote: 
> > On 11/11/2020 6:56 PM, Alexander Schreiber wrote: 
> >> seasoned_geek <rol... at logikalsolutions.com> wrote: 
> > 

> Would it be too much to read up at least _some_ on encryption? One 
> fundamental property of a _good_ encryption algorithm is that it stands 
> up to Kerckhoffs Principle: even if the attacker knows everything about 
> the design of the cryptosystem, it is still secure as long as the 
> keys are not known to the attacker - which is a derivations of Shannons 
> "the enemy knows the system" principle. 

The real problem with reading up on it is it leads people to be lulled into a false sense of security. That there really is a one-and-done solution. It also leads to people chanting the mantra "no known security vulnerabilities".

> Good current algorithms like AES have this property - brute force cracking 
> (trying all keys) takes an entirely uselessly long amount of time and there 
> are currently no know weaknesses that reduce this time to something useful 

Bingo! <to quote Dave>

Again, see the very long response to Arne.

Every false sense of IT security is based on the false belief that a hacker needs or wants absolutely everything. One of the re reasons CC fraud is so rampant is that belief being patently false. They have progressed to the point of charging a few hundred dollars and moving on.

It doesn't matter how perfect the algorithm seems on paper. Compiler optimization introduces issues. AGILE (and by definition low quality) developers fail to understand said algorithm and implement something that only passes the tests they write. Maintenance developers, like the Ubuntu maintainer who decided to "help out upstream" by getting rid of a compilation warning reduce a critical variable to 32-bits in size.

All of this makes the grand assumption the attacker is trying to get in and the even grander assumption they have to know everything because they don't know what they are looking for.

When they are just sniffing packets (collecting echoes really) of authorization request packages being routed to a merchant/cc processor, they are just looking to crack _some_ of them. Fraud investigators try to identify breaches based on shopping patterns of the victims. When they are scattered around the country at different merchants it makes it really difficult; especially when the forensics of the Merchant/CC processor system turn up clean and everyone working there passes a polygraph.

The big business of CC fraud has simply backed into the answer they need like mathematicians back into answers to problems they cannot solve. Instead of saying
"I know the SALT and I know it is an XML packet, but I can't solve for X (the password)" like most gullible enough to believe encryption is secure they appear (at least in my thinking) to have taken the pragmatic approach.

1) "<?xml version=" is at the beginning of every packet I'm interested in.
2) I know the rules for the passwords so it is not every permutation of 32 characters, rather it is a significantly limited subset. Most will be the minimum 8 and definitely under 20 because people hate typing as well as coming up with new passwords. Many people end their passwords with "_n" where n is a number because far too many financial institutions make them change it every month or 60 days so this way they can just increment a number.
3) If I can find a time frame where the generated SALT is a lot less random I can build a rather complete database over time.
4) If I happen to be one of these bot-nets:  https://themerkle.com/top-4-largest-botnets-to-date/   my only real problem is the storage I/O. 6+ million bots generating 100 entries per hour each will fill a 32TB NAS up pretty fast. I will need 20-30 of them scattered around the globe. Gee! I guess I will buy them with a stolen CC or 40!

Brute force has gone off-line and high tech.