> if you are certain the software you use is secure
The entirety of the problem is that you can't be certain the software you use is secure.
The entirety of the problem is that you can't be certain the software you use is secure.
Most people doesn't give a shit, they pull down or introduce dependencies and think "wauw that was easy and fast".
Of course there is secure software, otherwise we wouldn't be able to live as we do.
That attitude allows practical risk management and effective engineering. Pretending software can be secure or mild steel has infinite yield strength cannot.
There is no lock that can’t be picked either, which is why no one leaves millions in cash protected just by a lock without guards and a surveillance system. And why they insure large amounts of cash.
At this point it should be pretty obvious - don’t put important secrets on computers without a way to expire/revoke them. If it’s a secret that can’t be expired/revoked, think long and hard about if you need it on a computer - and if you do, use a SCIF.
Monitor any connected computer systems for compromise. Use encryption extensively, preferably with hardware protection, because software is insecure, etc.
Same with controlling dangerous equipment - don’t rely on pure software or someone will get killed. Use hardware interlocks. Use multiple systems with cross checking. Don’t connect it to the internet. Etc.
This is all industry best practice for decades now.
Q: this is good steel still, why not use it?
A: steel is never ideal, that's the problem.
Risk manage us nginx please. At least write out the steps, you must have a checklist or something, right?
Let's be honest, we just apt install it and read vulnerability reports when they hit /news.
But it's also moot: if you're that afraid of vague security threats, then just don't expose your software to the internet. It's not difficult.
the whole point in context was that exposing software to the internet is high risk, no matter how secure you think it is, because no software is truly ever secure given enough exposure.
Talk about exhausting bullshit. But then what to expect from a green throw away?
Uh, me, I did. I thought I was pretty clear. Please refer to my previous comment.
> It's realism.
Okay. How are you going to change your behavior?
I'm not sure what point you're trying to make. If you want to put your recipe website behind a SCIF, be my guest. Some of us aren't quite so afraid.
You’re the one trying to turn this into some kind of existential emergency. What are you going to do differently?
Which is my point.
Or yolo it because you don’t care about a compromise. It’s your life, not mine.
Hopefully you aren’t storing any medical records, financial records, etc. for me or anyone I care about if that is the case though.
Because software is fun, and I get to work with cool things. There is a joy in programming in and of itself.
I guess your question doesn't make sense to me. Just because it will eventually be broken, does that automatically mean there's no value in software? I don't think that's true, it just probably means you should have an analog backup process if possible, especially for critical things like government services.
What makes you think such a thing is possible? In reality, not theoretically.
I also have yet to find an unpickable lock, given the same constraint. Locks still have utility.
But only fools protect something very valuable with just a lock.
The main source of my confidence is extrapolation from the results of successful initiatives to improve security. Rust is one such initiative: at relatively low cost, it drastically improves the security of "systems software" (defined for our purposes as software in which the programmer needs more control over resources such as compute time and latency than is possible using automatic memory management). Another data point is how much Google managed to improve the security of desktop Linux with ChromeOS.
There's also the fact that even though Russia has enough money to employ many crackers, Starlink's web site continued operating as usual after Musk angered Russia by giving Starlink terminals to Ukraine -- and how little damage Russia has managed to do to Ukraine's computing infrastructure. (It is not credible to think that Russia has the ability to inflict devastating damage via cracking, but is reserving the capability for a more serious crisis: Russia considers the Ukrainian war to be extremely serious.)
Sufficiently well-funded organizations with sufficiently competent security experts can create and maintain a software-based system that is central to the organization's process for delivering on the organization's mission such that not even well-funded expert adversaries can use vulnerabilities in that system to prevent the organization from delivering on its mission.
You seem to be saying ‘secure’ == ‘compromises are able to be fixed’.
Which doesn’t fit any definition of secure I’m aware of.
Every one of those things you mention has been compromised, and then fixed, at various times. Depending on specific definitions of course.
And that is what we see publicly. Typically figure on an order of magnitude more ‘stealth’ compromises.
For a compromise to be fixed, someone has to notice it. Exposing machines to the Internet increases attack surface dramatically. Allowing machines to talk to the Internet unmonitored and unrestricted increases their value to attackers dramatically.
Without careful monitoring, many of the resulting compromises will go undetected. And hence unfixed.
[https://www.cvedetails.com/vulnerability-list/vendor_id-1902...]
[https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...]
[https://purplesec.us/security-insights/space-x-starlink-dish...]
[https://www.pcmag.com/news/account-hacking-over-starlink-spa...]
If you had written, "99% of software used in anger is insecure," or, "most leaders of most organizations don't realize how insecure the software is that their organizations depend on," or, "most exploits go undetected", I would not have objected.
My point not only stands, but is reinforced by your comments.
If software is eventually compromised, it was not secure. I have yet to see any software that does not eventually get compromised when it gets enough exposure.
That those compromises can get fixed after the fact doesn’t change that.
And ignoring the explicit cases where your examples were disproven doesn’t help your case either.
It's funny that password managers and random generated single use passwords are so popular now, because the greatest risk to one's credentials isn't direct attacks, but having them leaked by someone's half assed backend. It gets even funnier when the service that gets breached has some arcane password security rules with two symbols or whatever, the ultimate hypocrisy.
20 years ago, when I was still young and naive, I took these concerns way too serious, remapped ports, believed in pwn, set up fail2ban and knocking, rotated logs. Later I realized it was all just FUD, even back then. You run on 22, 80 and 443 like a chad, use pw-based auth if you’re lazy, ignore login attempts and logs in general and never visit a server until it needs reconfiguration. Just say f* it. And nothing happens. They just work for years, the only difference is you not having tremors about it.
The only time a couple of my vpses were pwned in decades was a week after I gave a sudoer ssh key to some “specialist” that my company decided to offload some maintenance to.
What changed from back then is that software became easier to set up and config and less likely to do something stupid. Even your dog can run a vps with a bunch of services now.
Good luck. Some people have different experiences.
With opensource and how code works in general, we are all in the same boat with bigcorps and megacorps. And they receive the same updates at the same rate (maybe minutes faster cause they host repos).
This quote, "you can't be certain the software you use is secure", is technically true but is similar to the "you can't be certain you won't die buying groceries". Perfectly useless fearoid for your daily life.
But the way you phrase it isn't really convincing, and for singling out 443 and 80 ports. As the subthread of breaches hint towards. You might not need to be worried about nginx, but whatever you host on nginx might be a problem and being "certain the software you use is secure" is also pretty darn useless as guidance.
* Try to avoid it in the first place.
* Do research, minimize risk and make whatever compromises you are willing/able to make
* Isolate it
* Maintain, update and monitor it
Be aware of your threat model and the risks associated.
better off using key only logins and forgetting IMO
This happens _all_ _the_ _time_
Don't move the goalposts. I'm certainly not saying that nginx is insecure. I'm saying that if you think any piece of software written after the 80s has reached the point where it won't have 0 days anymore you just haven't been paying attention