3 ms·
If security breaches lead to jail time, nobody but a few big companies will build anything. Be careful what you wish for.
by trustno2 2y ago
If security breaches lead to jail time, nobody but a few big companies will build anything. Be careful what you wish for.
- figassis 2y agoMy side projects will never leak passwords. How is that not security 101? You do not need to "invest" in this, every single engineer needs to have this level of working knowledge. Not having this in place should absolutely mean not being allowed to run a business online.
- croemer 2y agoHow can you be so sure? Never is a strong word unless you never use passwords in your side projects. And this here wasn't a side project. It's easier if only one person controls a code base than with complexity.
- trustno2 2y agoWhat if someone gets into your app logic and make a POST trigger that gets the passwords out. What if you log all POST requests for debugging purposes and forget to sanitize the logs. What if you have XSS in your web app that sends the password to a third party. What if your mobile phone app has a dependency that includes a keylogger. The likelihood of this increases the more layers you have in your organization (for example, the log pipeline team assumes the logs are already sanitized; the login form team assumes the log team is sanitizing them; it all goes through some A/B testing team that just dumps all data to "data lake" somewhere unsafe; the FE team puts in random node.js dependencies as it's "just a frontend"; etc). Passwords can leak from more places than just from the DB...
- figassis 2y agoGetting into the app's running process is an effective way to exfiltrate everything, and likely they'd have a lot more to worry about there. I don't however think that piggybacking on a live app does not give you the size of these leaks. I mean, does every user of a service access the service in these periods? More likely they steal the app's credentials (db, cloud provider, etc) and then go to town on data at rest. You're right on logs and things like fullstory, but no one on any team should assume things are sanitized. You do your job independently. If you're an infra, devops, sre, does it make sense to say I thought they had it handled? Was that what you marketed on your resume? Not saying there aren't complexities involved, but in many of these cases I see a lot of low hanging fruit, likely due to moving too quickly. We really need to own up to the fact that we've grown too comfortable with not giving any thought to other people's data. Why is it that there are the PCI audits when you handle card data, but not when you handle PII? Because card fraud hits the banks and they don't want to pay for any of that. So an entire industry was spawned, it's not perfect, but it helps a lot. You do not see a lot of credit card leaks.
- haswell 2y agoI disagree. I do think it would incentivize new security products/libraries/services focused on helping companies fulfill their security requirements instead of rolling their own crappy solutions. If a startup cannot secure their customer’s data effectively, I don’t want their product to exist. If that means fewer startups get products off the ground, I fail to see that as a bad thing if a lack of security was the reason. Slowing the industry down after a decade of breach after breach after breach seems like a reasonable and possible necessary intervention.
- trustno2 2y agoGood model is credit card numbers because they really cannot leak and if they leak, people are prosecuted. Thus there is basically nobody doing credit card processing and the companies that DO that are unreasonably big and basically a monopoly. (Everyone always complains about PayPal...)