Security: Part 7 of How to Commission a Software Project
This security article is part of the “How to Commission a Software Project” series.
When I wrote about infrastructure I urged readers to find an expert specifically for security. I stand by that admonition and in the same breath disclose and disclaim that I am not a security expert. This is only a collection of some common pitfalls at the software development level and not meant as a replacement for a proper security audit.
Some of the items on this list may seem silly. It’s terrifying, however, that I see major NO-NOs in production all the time. So we can’t take anything for granted.
Hash the passwords
At a minimum, you should encrypt passwords with bcrypt. As time goes on, newer hashing algorithms and better methods will be required to keep access to your resources and your users’ accounts secure – but right now, bcrypt is a good standard for normal security applications. Remember if you’re dealing with government software or exporting source code across international borders you may have to make other considerations. It’s really important that we do not use two-way hashes, two-way encodes, or plain text passwords. I can’t believe I even made that list but I’ve seen all three of those methods used during 3rd-party code reviews we’ve performed over the past year.
Build authorization early
First, a refresher: authentication answers the question “Are you who you say you are?” And authorization answers “Now that I know you, are you allowed to do the thing you’re trying to do?” I highly recommend building an authorization model which tests access to specific resources and methods and denies access by default, unless the user/role is on the list. Of course, this becomes a question for your requirements gathering phase and you already did that very well, right? Ask me about a role matrix someday.
Don’t put credentials in code
Yes, you keep your source code in a secure place because it already contains your valuable intellectual property, but resist the urge to hard-code credentials because there are still risks. It’s harder to adjust in case you need to invalidate a token, and there are plenty of alternatives. Environment variables, databases, or credential management microservices are all better than creds-in-code.
Don’t share accounts
If I had a nickel for every time a third-party dev team sent an email like “user is admin, the password is @dmin123” I’d still be crying because this practice breaks my heart. Give every single user, admin or otherwise, their own account. I simply do not understand the motivation for any other practice. There are three major reasons:
“Who deleted this setting?”
“Hmm, looks like admin.”
“Who signs in as admin?”
“About 10 of us.”
“Charles quit, let’s make sure to remove his admin access”
“What was that admin password again?”
“I guess if everyone else has it, I can give it to you! It’s @dmin123.”
Be minimalist with data
Just like with the authorization model, only send data to a UI or subsystem when needed. You never want to find out after launch you were sending a full list of user emails to the browser behind the scenes because it saved the engineer 30 minutes of intentional development.
If your software requires compliance with any sort of standards body for privacy, healthcare, finance, government, or other sensitive industry, those standards trump anything I say. Make sure you have an in-industry trusted advisor to help navigate those standards.
Ask. Always ask
Stay on top of the development team about security best practices. Ask lots of questions, especially the ones that seem dumb. Take nothing for granted and make sure you’ve got a team you trust. Remember, even if your software isn’t occupying a sensitive space your users will always consider their data a sensitive asset.
Interested in getting help with security best practices?