3 ms·

From the scasm readme.md: "Do not ask for the final goal of this: this is more a learning vehicle to abord several interesting topics." Isn't security one of th

by dkopi 10y ago

From the scasm readme.md: "Do not ask for the final goal of this: this is more a learning vehicle to abord several interesting topics." Isn't security one of those interesting topics?

sbuttgereit 10y ago
It can be... but it also can be a drag if that's not your immediate area of study. Security is incredibly important, but it is an overhead: including a cognitive overhead. If I'm futzing around with a toy project to learn about how, say, distributed agents can make use evolutionary selection to create efficient protocols amongst themselves (yes, a completely bullshit set of terms strung together) and I fully expect this to never leave a group of VMs on a home server.... yeah, security is NOT something I'm going to sweat. Doing so would be a distraction and counter-productive to my goals. To be fair to your point, however, by not constantly practicing secure coding techniques, regardless of context, I could get out of the habit of secure coding as a default. I may simply not think about it at a time when I should be. By always considering, even in my bullshit toy project, I stick to my good practices and more consistently apply them when it counts. But the argument that security coding can be interesting and fun is not a good enough argument to care about it all the time.
- dkopi 10y ago
  I'd argue that all code should be fairly defensive. Security flaws in the end are just bugs. And defensive programming helps reduce bugs. As for toy projects - you never know when your futzing around becomes a full blown product. Obviously, security is always a tradeoff. I'm not suggesting you implement 2 factor authentication for your wedding invite website. But it does always help to consider: 1. How can this code break, if someone accidentally misuses it? 2. How can this code break, if someones intentionally misuses it? Very often, thinking about #2 can help resolve a lot of things overlooked in #1.

by dkopi 10y ago

From the scasm readme.md: "Do not ask for the final goal of this: this is more a learning vehicle to abord several interesting topics." Isn't security one of those interesting topics?

sbuttgereit 10y ago

It can be... but it also can be a drag if that's not your immediate area of study. Security is incredibly important, but it is an overhead: including a cognitive overhead. If I'm futzing around with a toy project to learn about how, say, distributed agents can make use evolutionary selection to create efficient protocols amongst themselves (yes, a completely bullshit set of terms strung together) and I fully expect this to never leave a group of VMs on a home server.... yeah, security is NOT something I'm going to sweat. Doing so would be a distraction and counter-productive to my goals. To be fair to your point, however, by not constantly practicing secure coding techniques, regardless of context, I could get out of the habit of secure coding as a default. I may simply not think about it at a time when I should be. By always considering, even in my bullshit toy project, I stick to my good practices and more consistently apply them when it counts. But the argument that security coding can be interesting and fun is not a good enough argument to care about it all the time.

dkopi 10y ago
I'd argue that all code should be fairly defensive. Security flaws in the end are just bugs. And defensive programming helps reduce bugs. As for toy projects - you never know when your futzing around becomes a full blown product. Obviously, security is always a tradeoff. I'm not suggesting you implement 2 factor authentication for your wedding invite website. But it does always help to consider: 1. How can this code break, if someone accidentally misuses it? 2. How can this code break, if someones intentionally misuses it? Very often, thinking about #2 can help resolve a lot of things overlooked in #1.