The biggest security mindset shift for me was understanding that input is not something a user enters in a form element. Input is literally everything that comes to your server (since everything can be tampered with), so treat it as such!
That async request you yourself wrote so you think you can trust it? Validate that payload same as you would a text field.
The less data you store, the fewer security hazards you expose yourself to, and the safer your participants will be. Don't hoard data on the theory that it'll become useful - only save what you need, and question yourself every time you get into a situation where you think you need it.
If you must store data, especially sensitive data, don't ever store it in plain-text! Look into hashing algorithms like bcrypt.
Always give your participants the option to delete their data, and actually delete it when they ask you to.
In Europe we must comply to GDPR which is coming into practise in the next few months. We’ve had to implement what you mentioned on every single system which holds more than one piece of identifying information about a user.
Not everything, just database tables containing personally identifiable information. You’ll want to encrypt this information rather than hash it, as you’ll more than likely need to retrieve it at a later date. Here is a good read which explains the legislation in more detail: techblog.bozho.net/gdpr-practical-...
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
The only perfectly secure system is one that's been disconnected, powered off, encased in concrete, and dropped into the ocean from a helicopter flown blindfolded.
Any functionality you can use is functionality someone else with ulterior motives can use. Data you can access through your system is data someone else can access through your system. Backdoors are an inherent security risk.
I'm not sure if the blindfolded helicopter will achieve its purpose. It might just crash pretty quick, make the system fall and release it from concrete. Just sayin'
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
Re 6: No, hashing is not enough.
Use an algorithm suited for this task, as recommended by those crypto experts, which right now is mostly scrypt and argon2.
md5/sha1/sha2/etc is not enough no matter how much salt and pepper you throw on top.
Security is hard. It's worthwhile to read about various attacks to understand the magnitude of ways in which stuff is attacked.
Your system will be breached. Mitigation strategy is as important as the "wall".
A system is never "secure", you can only balance security goals with current risks and available resources.
Privacy is inseparable from security. Even if you're irresponsible and don't care about your users, the attackers will.
Security becomes harder as the data becomes more valuable. Most systems are really only secure because nobody really wants the data they store. As a company becomes successful, the attackers will come.
Security is a moving target. You are are never done implementing security.
User security is as important as corporate security.
Being open about security is the only way to know it's correct. There is no security through obscurity.
Everybody is responsible for security. Every person and every machine is a potential attack vector.
Kim Arnett [she/her] leads the mobile team at Deque Systems, bringing expertise in iOS development and a strong focus on accessibility, user experience, and team dynamics.
I follow these two guys on Twitter: (@Scott_Helme)[twitter.com/Scott_Helme] and @troyhunt. They're a source of lots of security articles, research, breaches, etc. I try to keep up on recent events, and do a deep dive in the web whenever a concept/term comes up that I don't know.
Kim Arnett [she/her] leads the mobile team at Deque Systems, bringing expertise in iOS development and a strong focus on accessibility, user experience, and team dynamics.
I'd add: never even commit a credential (password/API key/etc) to your repo. I'd argue this applies to any repo, not just open source ones, since you never know what might happen to the repo in the future. Even if you remove the credential in a future commit, it still exists in the history.
He/Him/His
I'm a Software Engineer and a teacher.
There's no feeling quite like the one you get when you watch someone's eyes light up learning something they didn't know.
Just FYI if anyone has hit this issue before: ‘Bfg repo cleaner’ can clean the repository of any traces of files, however if you’re working on a team project the key can spread like a virus as it will ‘infect’ branches stemmed off of master in the future (if this passed code review of course). I had to deal with a situation similar to this as someone had committed a global config file containing passwords which was only meant for development. Fun times. Of course the solution for deeming an API key pair useless is just to regenerate the key, however passwords are a different story if you don’t want a history of previous passwords being revealed.
There's no one stop shop security solution for any application. Security and best practices are always changing and the most important thing in security is showing up and staying informed. And trust no one.
Oldest comments (47)
The biggest security mindset shift for me was understanding that input is not something a user enters in a form element. Input is literally everything that comes to your server (since everything can be tampered with), so treat it as such!
That async request you yourself wrote so you think you can trust it? Validate that payload same as you would a text field.
The less data you store, the fewer security hazards you expose yourself to, and the safer your participants will be. Don't hoard data on the theory that it'll become useful - only save what you need, and question yourself every time you get into a situation where you think you need it.
If you must store data, especially sensitive data, don't ever store it in plain-text! Look into hashing algorithms like bcrypt.
Always give your participants the option to delete their data, and actually delete it when they ask you to.
In Europe we must comply to GDPR which is coming into practise in the next few months. We’ve had to implement what you mentioned on every single system which holds more than one piece of identifying information about a user.
What did you do, just hash or encrypt everything? We are facing the same right now.
Not everything, just database tables containing personally identifiable information. You’ll want to encrypt this information rather than hash it, as you’ll more than likely need to retrieve it at a later date. Here is a good read which explains the legislation in more detail: techblog.bozho.net/gdpr-practical-...
So it's not just a good idea, it's the law ;)
I agree. The idea of soft-deletes irks me. My personal data isn't a line in a log file which one would wanna keep for as long as possible.
I created an account, said my name is Rexford. Now I'm leaving, and say, delete that data, and then soft-deletes it?
It's so crazy of an approach not sure why it still exists.
Don't roll your own crypto in production.
Something about not exposing passwords by passing form info as url variables because people can then see your password.
I'm not sure if the blindfolded helicopter will achieve its purpose. It might just crash pretty quick, make the system fall and release it from concrete. Just sayin'
You can take off without the blindfold but you have to put it on once you're over the water.
This sounds reasonable
Re 6: No, hashing is not enough.
Use an algorithm suited for this task, as recommended by those crypto experts, which right now is mostly scrypt and argon2.
md5/sha1/sha2/etc is not enough no matter how much salt and pepper you throw on top.
PHP (which isn't exactly my favorite language) kinda got it right, providing easy-enough to use password functions in their standard library.
Practical advice:
Do you have any books or suggested reads on various attacks?
I follow these two guys on Twitter: (@Scott_Helme)[twitter.com/Scott_Helme] and @troyhunt. They're a source of lots of security articles, research, breaches, etc. I try to keep up on recent events, and do a deep dive in the web whenever a concept/term comes up that I don't know.
Awesome! Thanks!!
API Keys are just as sensitive as a username and password combination!
I'd add: never even commit a credential (password/API key/etc) to your repo. I'd argue this applies to any repo, not just open source ones, since you never know what might happen to the repo in the future. Even if you remove the credential in a future commit, it still exists in the history.
GitHub is pretty good with that, if they detect that one of their keys was committed and pushed to GitHub they'll let you know and disable the key.
Yeah too true.
Just FYI if anyone has hit this issue before: ‘Bfg repo cleaner’ can clean the repository of any traces of files, however if you’re working on a team project the key can spread like a virus as it will ‘infect’ branches stemmed off of master in the future (if this passed code review of course). I had to deal with a situation similar to this as someone had committed a global config file containing passwords which was only meant for development. Fun times. Of course the solution for deeming an API key pair useless is just to regenerate the key, however passwords are a different story if you don’t want a history of previous passwords being revealed.
There's no one stop shop security solution for any application. Security and best practices are always changing and the most important thing in security is showing up and staying informed. And trust no one.