More often than not, security is a pain to think about. On top of worrying about whether or not you have a functioning app, a go to market strategy, and all the moving pieces that come with owning a digital product, security is the last thing you want to have to think about.
To make things a little easier for you, there are five rules I suggest you follow no matter what kind of application you’re trying to build.
Disclaimer: Just keep in mind that the steps I’m suggesting is the baseline and bare minimum for the level of security any app should contain. Depending on the nature of the industry you operate in or the nature of the app itself, these five things might not be enough. And even if you do all five of these things, you may not be 100% safe, but it’s a good place to start.
Hash user passwords
Password hashing is when you take the plain-text password a user inputs, and run it through a one way function that spits out a scrambled, nonsensical string so that when it is stored into the database, the text is nowhere near the original input and can be saved securely. Take the example below. For simplicity’s sake, if the user’s password is ‘password123’ (which I don’t recommend by the way), running it through a hash would give something similar to this:
password123 -> SHA256 -> ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f
It’s important to note that this function is designed to be non-reversible. Ideally, this would prevent a hacker from getting a readable version of every user’s password in the database in the scenario of a data leak. In practice however, password hashing on its own doesn’t work as perfectly as it was intended to. Hackers are persistent and creative, and are constantly trying to crack these hashes through things like rainbow tables.
So what is a Rainbow Table exactly?
It may sound nice and harmless, but it’s neither of those things. In short, a rainbow table is a massive table, or database of passwords and its corresponding result after it’s been hashed with common hash functions (SHA256, MD5) like the example shown below.
With a big enough table with different password variations, hackers are able to match the hashed passwords (that they would have gotten from a data leak) to the original password inputted by the user.
This is another reason why hack leaks are so detrimental. Every time a major hack occurs like the ones that happened to Equifax, Yahoo or LinkedIn just to name a small fraction of them, the information gets added to a rainbow table, making everyone else’s credentials more vulnerable.
This is where password salting comes in to save the day.
Salt your hashes
We know that hashing a password sometimes isn’t enough to keep user information fully secure. In fact these days, ‘hashing’ and ‘salting’ pretty much go hand in hand.
What is password salting?
The term ‘salting’ comes from the act of random sprinkling. ‘Salting’ is when some random string is sprinkled into the original password before it gets hashed. This ‘Salt’ is usually unique to the system, and sometimes even each user.
As you can imagine, salting a password before hashing it makes it substantially harder to crack because a hacker would have to create a unique rainbow table for each salt. In order to protect users’ passwords, it’s important to apply both hashing and salting.
Use transport layer security
Transport Layer Security, also known as Secure Sockets Layer or SSL/TLS, is something that can instantly tell you how trustworthy a website is.
If you’re reading this blog on our website, simply shift your eyes up to our domain “www.twotalltotems.com”. To the left of that you should see a padlock, followed by the word “secure”, and “https://” before our website domain name. This is one of the ways you can tell whether or not a site is SSL/TLS certified. Another way is to right click on a page, click on “inspect”, click on the security tab, and click view certificate which should give you something like the following image:
So why is transport layer security necessary?
It takes care of two very important things. Identification and Encryption.
First off, it ensures that the visitor or user is communicating with who they’re supposed to be communicating with. It also encrypts the data that is being sent from the user to the server so the data cannot be intercepted by a hacker.
Any website or app that has even a little bit of confidential or nonpublic information going to and from it definitely needs to be SSL/TLS certified. Most third party certification bodies will charge around $100 annually, but Amazon route 53 is free. No, we’re not sponsored by Amazon, we just like providing useful information.
There are ways to hijack SSL sessions but let’s leave that for another time.
Keep all system/Admin credentials secure
This one might sound self explanatory but it’s still a real issue believe it or not, so it’s going on the list. All admin credentials should be kept secure, with a password of substantial length (preferably 10 characters or more) and relative complexity. This applies to any application login and all server credentials as well.
Just recently, Equifax got called out (again) after the first data breach occurred. This time it was for something so wrong, it hurts my soul as a Security Engineer. Their web portal in Argentina was “protected” by the incredibly secure username & password combination of Admin and Admin. If that looks like the same word twice, it’s because it is. At this point, you might as well knock on your hackers’ front door, serve up your users’ private information on a silver platter and call it a day.
Any app should be expected to provide their users with this baseline level of security let alone an organization that holds people’s social security numbers, home addresses, and credit scores.
For secure password generation, I prefer using diceware, that helps create unique, difficult to bruteforce and relatively easier to remember passwords. You can learn more about diceware here.
Testing
As with anything, it’s always important to test what you’ve just built. I’m talking proper QA testing. Bugs are every developers’ nightmare, and for good reason.
Back in 2015, the gaming platform Steam had a bug that compromised some of their users’ accounts that could’ve been avoided with proper testing. If someone clicked ‘forget password’ and left the ‘enter verification code’ area blank, it would allow people through to reset the user’s password without having to enter a code. Essentially, all you needed was someone’s username.
To be fair, Valve (Steam’s creators) tackled this issue quite quickly, and most of the victims had their accounts fully recovered. However, the point is this could have happened with something more major, and it has in the past.
At the end of the day, security is all about prevention. The majority of leaks and hacks that occur could have been prevented. If you’re going to develop an app, do yourself and your users a favour and please, please make sure to follow these guidelines (at bare minimum). If you’re unsure of what level of security measures is suitable for your app, go and consult with an app developer because when security fails, no one wins….except the bad guys.
Wali has also contributed to the blog on “Social Insider Attacks”. Read more about that here.
