Monthly Archives: June 2017

Software Security is Not an Option

When it comes to software development, many customers (external or internal) will not request, require or even ask you about the security features you are implementing. Either they don’t know enough to consider it or they think you’re going to do it because you’re the professional.

Whether you are a contractor or an internal software engineer, you need to make sure that security is considered, it is strong and it is tested. No customer is going to put security on your feature list. If they do, it may be something as simple as making sure there are eight characters in the password, that there is an uppercase and lowercase letter, that it includes a number and a special character. 

Whew. My work is done. I’ve met the requirements. The password is secure.

No. No, it isn’t. 

  • If you are transmitting the password as plain text, it is not secure.
  • If you are storing the password as plain text, it is not secure.
  • If you are encrypting the password, it is not secure.
  • If you aren’t using HTTPS (TLS v1.2), it is not secure.
  • If you are using SHA-1 to hash the password, it is not secure.
  • If you are hashing the password only once, it is not secure.
  • If you aren’t using a random salt, it is not secure.
  • If the database has a simple password or none at all, it is not secure.
  • If the database is exposed online, it is not secure.

There are so many things to think about here that you can’t rely on your customer to ask for them all. And if they do ask for security, they may be asking for the wrong things. For example, customers will ask to make sure that users can’t use the same password twice before they ask if you’re hashing the user’s password. What’s really more important? You need to help that customer make the right decision.

A customer is not going to know that encrypting a password is not the same as hashing it. If they do, will they know that you should hash the password multiple times? Will they know that you need to supply a random salt each time? Will they know which hashing algorithm to use?

No, they won’t. And they shouldn’t have to know these things. 

It’s up to you, the software professional to make sure that software security is baked in from the beginning. It’s up to you to make sure that software security is constantly evaluated to ensure you stay on top of the latest hacks, hashing methodologies and more. It’s up to you to test for security.

Have you tried a SQL injection attack against your own system? Have you run your database of passwords through a rainbow table to see if you can hack your own data? Have you tried to access your database through unconventional means?

So, I challenge you to read some good articles on password security. Write some example code. Create a database on an AWS server, populate it with some test passwords. Then try to steal your own data. Then pretend that you did steal your user table and see if you can reverse engineer the passwords. 

Create a sample login screen. Spam that login screen. Try to push SQL through it. Send a hashed password through it. Write a script to try to guess usernames and passwords. Improve your login screen with bot filters, Captcha, and SQL injection protection.

Take this time to have a little fun and build some security libraries. Then you will have what you need for new projects and upgrades to older products.

Remember, software security is not an option … in today’s environment, it is required.