This applies to all kinds of user interaction.
It's a lesson that I've learned, the hard way.
I've seen things, man...
Nobody Cares About Security
41–50 of 93 posts
Re: Nobody Cares About Security
#42I've been saying this since at least 2009 when the company I worked for was sending credit card info from card readers across the network in plain text and they dragged their feet to fix it even though they knew we were violating some serious SOX policies. At another company in 2015, I discovered we were sending user credentials for a large hospitals in plain text across the network and need to fix this ASAP. When I…
> I came up with a nice write-up for both our company and the hospital IT groups on how to secure our infrastructure with certs and whatnot and they still half-assed it with self-signed certificates.
What's the problem with self-signed certificates? Did they not know each other?
Re: Nobody Cares About Security
#43I've been saying this since at least 2009 when the company I worked for was sending credit card info from card readers across the network in plain text and they dragged their feet to fix it even though they knew we were violating some serious SOX policies. At another company in 2015, I discovered we were sending user credentials for a large hospitals in plain text across the network and need to fix this ASAP. When I…
Until they are fined 10% of yearly revenue. That's why you need a strong government.
agree in spirit. better federal laws to hold companies accountable
Re: Nobody Cares About Security
#44I have over 6,000 hours of on-site data breach consulting experience.
Companies do not give a sh*t...
When we have GDPR style laws in place in the U.S., companies will start to care..
4% of a companies annual worldwide turnover is a tremendous deterrent..
Re: Nobody Cares About Security
#45There are many common software tasks that are just hard to do securely, and there is an incentive to keep it that way. Security is a huge industry mostly filled with people who check boxes and memorize obscure trivia. Consider TLS, the "industry standard" for connecting two processes securely over the network. There is a huge amount of complexity just to accomplish something that should be secure by default. Certific…
Reminds me of homomorphically-encrypted cloud-computing efforts. Apparently, there is a fully functional, RISC-like virtual CPU (built out of Boolean gates) that C can compile to and that one can use for processing your secret data on untrusted machines [0]... and a very, very beefy Amazon instance can emulate it running at ~1 Hz clock. No, not 1 kHz. 1 Hz.
At which point I just had to stop and re-evaluate the problem again. If I have such a small amount of data that I am find at processing it at single-digit IPS (micro-MIPSes? geez...) then surely I could just process it locally, and much faster (and cheaper to boot)? And if I have an amount of data large enough to warrant using cloud resources, and important enough to justify paying astronomical sums... surely I could just spend that kind of money to simply buy lots of hardware and, again, run it locally, and much faster (and cheaper to boot)?
Re: Nobody Cares About Security
#46Earlier quoted context omitted.
Sure, now you just need a way to validate the public key and IP address genuinely belongs to the claimed identity. Could use a certificate?
The IP address is just a hint in that example because we don't yet have robust identity based networking. It's actually meaningless, either I successfully authenticate with the public key on the other end, or I don't. I don't care about getting the wrong IP address, worst thing that could happen is that I bother the wrong process and it can't establish a connection with me. You must be a TLS expert because saying we…
TLS (as in https for websites) solves a different trust issue than wireguard. The case you present was two trusted parties (or one party ) set up a VPN between two hosts. It assumes there is some pre existing secure channel to exchange the public keys. If you were to simply exchange those over telnet, you're open to mitm attacks.
With https this key exchange mitm aspect is acknowledged and that is where most of the complexity comes in. Since a client typically connects to a website without prior keys, we need a trusted third party like a CA or trust chain to verify were connecting to the domain we intended to connect to.
Not staying tls isn't bloated, but to be fair, it solves a more complicated problem.
Re: Nobody Cares About Security
#47Earlier quoted context omitted.
Sure, now you just need a way to validate the public key and IP address genuinely belongs to the claimed identity. Could use a certificate?
The IP address is just a hint in that example because we don't yet have robust identity based networking. It's actually meaningless, either I successfully authenticate with the public key on the other end, or I don't. I don't care about getting the wrong IP address, worst thing that could happen is that I bother the wrong process and it can't establish a connection with me. You must be a TLS expert because saying we…
The public key can be linked to an identity only if the client already own that mapping (identity public key)
For the vast majority of use cases, this cannot be done, hence certificates (with CA)
Re: Nobody Cares About Security
#48Earlier quoted context omitted.
The IP address is just a hint in that example because we don't yet have robust identity based networking. It's actually meaningless, either I successfully authenticate with the public key on the other end, or I don't. I don't care about getting the wrong IP address, worst thing that could happen is that I bother the wrong process and it can't establish a connection with me. You must be a TLS expert because saying we…
TLS (as in https for websites) solves a different trust issue than wireguard. The case you present was two trusted parties (or one party ) set up a VPN between two hosts. It assumes there is some pre existing secure channel to exchange the public keys. If you were to simply exchange those over telnet, you're open to mitm attacks. With https this key exchange mitm aspect is acknowledged and that is where most of the c…
I don't think these use cases are as separable as the TLS "experts" would claim. If something is giving me the IP address, why can't it also give me the public key? We just don't have a convention of passing those things around together, security came after the fact. We didn't design for security.
In a lot of cases the IP comes from a configuration file. That's assumed to be secure. In some cases it comes from an authority. If I'm trusting the authority for the IP address, why can't I trust them for the identity as well? I have to trust a different authority for that? That is twice as complicated as necessary.
DNS should really be about which identity owns a name. We are starting to get there with DNSSec, once that's sorted out we could easily return `@` entries in authenticated DNS records. The root server (transitively) claimed that this public key represents this domain name, and it was last seen accepting connections at this IP and port.
Re: Nobody Cares About Security
#49I've been saying this since at least 2009 when the company I worked for was sending credit card info from card readers across the network in plain text and they dragged their feet to fix it even though they knew we were violating some serious SOX policies. At another company in 2015, I discovered we were sending user credentials for a large hospitals in plain text across the network and need to fix this ASAP. When I…
Financial companies (and companies providing financial services) are protected by auditing and the law around finances, not infrastructural security. This is a major best-practice breaking point between two ecosystems of software service.
In the banking sector, you can still, to this day, try to get away with stealing money by forging a paper check and hoping the bank honors it. And they may let you walk away with the cash! What protects the system is that when the fraud is detected via auditing and resolution, actual law enforcement will come find you.
The early web never had such legal protections ("Wikipedia's database was hacked? What even is a wikipedia? They got their facts disrupted? What does that mean?"), so they were forced to grow infrastructural protections or be consumed by attackers. But there's a case to be made that the costs inherent with hardening infrastructure like that are unnecessary to bear when the law will actually show up to stop the criminals messing with your infrastructure. It's counter-intuitive for those of us raised on the "You can only rely on yourself; everyone else is a potential attacker" side of the fence, but it's a way to be.
Re: Nobody Cares About Security
#50I've been saying this since at least 2009 when the company I worked for was sending credit card info from card readers across the network in plain text and they dragged their feet to fix it even though they knew we were violating some serious SOX policies. At another company in 2015, I discovered we were sending user credentials for a large hospitals in plain text across the network and need to fix this ASAP. When I…
> I came up with a nice write-up for both our company and the hospital IT groups on how to secure our infrastructure with certs and whatnot and they still half-assed it with self-signed certificates. What's the problem with self-signed certificates? Did they not know each other?
IME when people start using self signed certificates they trust anything that is presented, with no pinning. That means that so long as you MITM it with something with it's own self signed cert it will work just fine.