4 ms·
The thing is, your "roll your own" auth is likely way smaller and less targeted than the library everyone uses. So the new exploits may simply not apply to your
by GuB-42 1y ago
The thing is, your "roll your own" auth is likely way smaller and less targeted than the library everyone uses. So the new exploits may simply not apply to your case.
Many famous vulnerabilities happen in parts of software people don't actually use. For example, the "Heartbleed" vulnerability in OpenSSL targeted the "heartbeat" feature few people actually used. In the "Log4Shell" vulnerability the exploit targeted LDAP support in log4j, which I have never seen used and didn't even know existed.
In addition, the "experts" maybe aren't. You may think that whoever is writing that popular library has a team of experts in security, it is used by big, serious companies after all. But in reality it may just be one overworked guy, and people only notice when the system has been publicly compromised. And that's if the developers themselves don't have malicious intent, or have accepted someone with malicious intent in the team (for the latter, see the xz story).
- j_w 1y agoI think this is good retort to what was argued. What's missed in me saying roll your own auth, even though I did say it, is that you aren't implementing the network stack or crypto. As long as you keep your dependencies up to date you shouldn't have any increased risk over using a third party library. If there is a novel security flaw discovered, consider the first SQL-injection or XSS attack, then you definitely should know about it. The idea that not rolling your own security related functionality absolves you from the responsibility to know or understand major security considerations is incorrect. It is the responsibility of every programmer to be knowledgeable of the security risks in their space and the patterns that protect against those risks.