> Expecting developers to know that 512 bit RSA is insecure clearly doesn’t work. They’re not cryptographers. This is not their job. The failure wasn’t that someone used 512 bit RSA. It was that a library they were relying on let them.
I disagree. Anyone using a library should have enough knowledge to use it properly, else they shouldn't be writing serious software. The flip side is that the library should be documented clearly enough to prevent a competent professional developer from making that mistake by accident.
I don't have an issue with a library supporting outdated standards since that can be useful for writing (hopefully temporary) code to interface with legacy systems. Again, as long as it's documented properly, and the devs understand the potential ramifications.
This is a great opportunity for me to cite my new favorite thing: the OHSA Hierarchy of Controls. In the physical workplace, documenting a hazard would be seen as an inadequate control if it can simply be removed.
Old crypto profiles often can't be removed because there's still ancient hardware that needs to be interacted with. Exhibit A: the SSH server in my modem only speaks diffie-hellman-group1-sha1 and 3des-cbc.
So putting it in separate legacy modules, removing them from automatic negotiation and putting warnings on them is usually the best option.
> We can do so much better than “be less dumb”.
Yes. But in the end "we only had junior engineers working on this piece of infrastructure" would not fly for Boeing either.
We have been doing this software and hardware thing for a decent amount of time now. If the SSH server in your modem uses bad encryption because of a hardware issue, the company should replace it and not make their own infrastructure less security because of that. It's the issue with IoT in general, there's no maintenance plan. But some countries are enacting regulation to ensure these devices aren't left rot (and eventually become a national security issue).
I'm not saying companies should do this for free, btw.
Requiring people to know everything is a strawman. Raising some basic awareness about risk factors in software systems such as "crypto, authentication, security are hard to get right", is not the same as expecting everyone to be able to implement constant time elliptic curve cryptography in assembly.
Understanding the boundaries of your own knowledge, where to delegate¹ to someone else or do some research to deepen your knowledge is also not the same as knowing everything.
¹ using libraries is not quite the same as delegation if you can't even assess if you're using them correctly or if they do the right thing. You still have to meet it where it is.
You don't have to know everything about everything. You just have to RTFM enough to understand what you're doing and what the ramifications are of doing it wrong. If you're not sure, ask a more senior dev for guidance.
I disagree. Anyone using a library should have enough knowledge to use it properly, else they shouldn't be writing serious software. The flip side is that the library should be documented clearly enough to prevent a competent professional developer from making that mistake by accident.
I don't have an issue with a library supporting outdated standards since that can be useful for writing (hopefully temporary) code to interface with legacy systems. Again, as long as it's documented properly, and the devs understand the potential ramifications.