Post by Arne VajhøjPost by seasoned_geekALL
ENCRYPTION is security by obscurity. Period.
Security by obscurity has a very specific meaning.
It is when the security depends on the algorithm being kept secret.
You need to search for and watch a very short George Carlin video discussing the18th century definition of the f-word. It's on You-tube.
"tap with a stick"
To people who are asked by clients to look at this stuff "Security by obscurity" means chanting the mantra "no known vulnerabilities" and bragging about the size of the forest you are about to hide a tree in.
It depends on people not knowing truth and wanting to believe something is true. Poke around in the "Hidden Brain" podcasts for the one covering how people are more apt to believe something completely false without ever verifying it if it supports something they already believe to be true or wish to be true.
People don't search for truth, they search for things that support their opinion. On rare ocassions they ask someone like me to blue-sky how their opinion screwed them.
Post by Arne VajhøjYou can open any text book on encryption and see the algorithms
for AES, RSA etc. and they are still prohibitively difficult
to crack.
And honestly, that has less than zero to do with this conversation than you are capable of realizing.
This entire conversations started what now feels like a lifetime ago in my Qt circles on TLS/SSL. People on PC platforms are even more gullible when it comes to believing in one-and-done security than midrange. People chanting they were "secure" because they used SSL/TLS.
https://www.cloudinsidr.com/content/known-attack-vectors-against-tls-implementation-vulnerabilities/
I'm not going to put an extreme search effort into it, but if you poke on-line you will find a link explaining how a Ubuntu "maintainer" helped out the upstream developers cleaning up a compilation warning that then limited all values to 32-bit. What is printed in the book, doesn't matter.This was out there a long time. It impacted every YABU distro, many of which are used for servers in financial transactions.
Prior to life really changing this year, I purchased a 4TB WD black drive to set up a database on because it looked like, testing with the command line tool, there was a severe TOD sensitivity on Ubuntu 18.04 as well. I did not get around to writing the code to generate the database.
I wanted to prove the TOD sensitivity then we could dig in to see if this was introduced by AGILE software development, inept programmer (which AGILE pretty-much indicates) or a compiler introduced issue. Here is a really long and boring read on some of the compiler introduced vulnerabilities.
https://arc.aiaa.org/doi/10.2514/1.I010699
Post by Arne VajhøjAES 256 bit has a 256 bit key. That is 2 power 256 possible keys.
That is a big number.
Size of the forest where you are hiding a tree. Completely ignoring the fact the tree you are hiding is a Redwood and the forest you are using is in Wisconsin.
Not in today's world. Not for people who are asked to think about such things. Not for someone looking to hit a single specific target.
Myth #1 of security: A hacker needs everything
No. You don't. If you want to avoid getting caught the longest you can, you well and truly don't want everything. All you really need is "sniffing" access along a feeder and some general public knowledge.
Before you try and spin this into one of your academic imaginary worlds where only you exist, I haven't thought about this in a long time. Winging from memory rather than bothering to look up. The scenario was, as I recall,
1) published XML standard being used
2) single message containing the short XML transaction (like a CC request for authorization)
3) SALT
There was some other piece here that is in my notes on another machine and archived in a long discussion elsewhere.
You know for a fact the message starts with:
<?xml version="1.0" encoding="UTF-8"?>
to be safe you can stop with just: <?xml version="
When the SALT has a TOD sensitivity such that between 2pm and 4pm local time only the last 5 really change (what I had stumbled into with some casual testing) you now only need the password. You know, that's not as difficult as it sounds given the helpful pages like this:
https://help.pearsoncmg.com/rumba/b2c_self_reg/en/Content/b2c_signin_guidelines.html
scattered all around the Internet and most certainly there will be one for your target. On that page you will find a section worded much like this:
======
Password
Your password:
Must be between eight and 32 characters long.
Must include at least one number or special character and one letter.
Can contain any letters a to z and any numbers from 0 through 9.
Can contain some special characters, including @ (at sign) . (period) - (hyphen or dash) _ (underscore).
Cannot contain spaces or non-English characters (such as é).
Is case-sensitive.
Must be different from your first name, last name, and username.
======
I now have all I really need to put my little BOT-NET to work generating entries for a PostgreSQL database. Each table will be named based on the SALT value. Each BOT is given a very simple task.
"Take this list of 100 valid generated passwords using this SALT value and encrypt <?xml version= returning the result for each."
That's it. Once per hour each of your hundreds or thousands of bots gets a tiny packet, possibly less than 1K in size. It does an imperceptibly small amount of calculations and returns, possibly 2K. If you have identified that between 2-4pm the generated SALT will only very within the last 5-digits you now just have 99,999 tables. The password rules mean you don't have all permutations of 32 characters, just a severely limited subset. You are searching for the pre-amble of __exactly__ one known message. The side effect is you _can_ now decrypt every other single XML packet you happen to sniff.
Operation one just builds the database. It gets better over time. How much time depends on how many BOTS you have and how heavy you want to load them.
Operation two is the sniffer. It wakes up near 2pm and shuts down near 4pm. Btw, there was nothing magic about 2-4pm, it was just what I was trying. You could most likely use 7-9am if you wanted people buying coffee, gas, etc. on the way to work.
Operation three receives the sniffed packets and does a partial keyed hit of the encrypted data to the table for the SALT. Upon match it decrypts the packet and routes it to another step that does some more verification before involving a human. If you are low budget and low tech, perhaps you send it straight to a human?
This is very doable today I believe. I simply have too much going on in life to devote a bunch of non-billed effort into it. Storage is certainly getting really cheap - assuming you don't want to pay some hosting service for a 100 TB you can get a "portable" (perhaps with two guys carrying it) 32TB NAS for under $2500.
https://www.newegg.com/p/14P-001N-00010?Description=32tb%20nas&cm_re=32tb_nas-_-14P-001N-00010-_-Product&quicklink=true
Each "record" in each table only has the VARCHAR password and the VARCHAR target encrypted output. Given the previous example that means 32 or fewer characters for the password (many probably closer to eight). What? At most another 32 characters for the target which will be the alternate key? You don't even need a big BOT-NET, just time.
The database can even be "rented out" to evil doers. If the packet has a pure XML message started with the universal beginning and has a SALT within range, it has a high probability of cracking it with a single keyed hit.
Now. I have spent far too long on this. I really have to get on with what I'm supposed to be doing today.
Far too many people in IT try to hide a Redwood in Wisconsin.
Believe it or not; a large number of transactions on the Web are just one XML object in a "secured" packet.