Not a member? Gain Access.

Unyielding Security

We hear a lot more about privacy in the policy space than we do about security. Regulators, it seems, are more interested in what companies do with user data than how vulnerable that data is to theft. Ultimately it’s left up to private companies—and the developers they employ—to make smart decisions that protect their users. But we’ve heard from developers in our community that pressure to ship can eclipse security concerns. We asked Andreas Backx to contribute some thoughts on the subject.

It is time for us as developers to take a stand for what we truly believe is necessary for the user and for their data to be safe. You could say that it’s a two-way street: we want our data to be safe elsewhere so we have to make sure our user’s data is safe too. We are also hired because we’re the ones with experience and know-how, so we have to express that and put our foot down when security requirements are being neglected.

Lately many of us who have been keeping up with security breaches have been checking whether we have been pwned. Putting it in different terms, we have been checking whether our passwords were compromised in a data breach. This is because of a data breach back in 2012 at Dropbox, of which the data has recently been made publicly available and we are all interested in whether our accounts were part of that breach. Dropbox certainly isn’t the first nor is it gonna be the last. If we sit idle and don’t do anything about it, we all run the risk of having a data breach seriously affect us. This all while we can easily prevent a disaster like that.

How passwords are stored

Passwords are transformed by a one-way hash function into a unique “hash” before they are stored in a database. These one-way functions are infeasible — if not impossible — to invert and so all possibilities of inputs and outputs are tried to crack a password. The generated hashes can be used to determine whether a given password is the correct password when a user tries to login. The problem is that all of the publicly available data breaches use a weak hashing function to store passwords. The hashing function used is the last line of defense in case of a breach and when using a weak hashing function then it basically is a door that just requires a bit of force before it can be pushed wide open. Behind that door is immediate access to all of your other accounts on top of the one breached if you use the same password elsewhere.

So why should passwords be stored using a strong password hashing algorithm when they’ve already been breached? Because it takes orders of magnitude longer to crack passwords hashed using a strong password hashing algorithm compared to a weak one. For comparison, with the use of easily available servers an average password of around 8 characters can get cracked in about a second. An equivalent password hashed using a strong password algorithm could take years. This enormous amount of extra time allows users to react to the data breach before their password can be cracked.

The fact that we still see these practises being used in major companies is worrisome. These are the things we new and old developers are hammered on when we create software and they are so easy to implement. Implementing these security features is unfortunately not visible to the client nor is it visible to the management team. It is hard to explain what you’re working on and how it improves the product. It might look like you’re wasting your time in the eyes of the management team.

What we can do about it

As managers and leaders, we need to listen to the engineers that we hire. We put so much work into recruiting the best engineer, yet that work is not being fully taken advantage of. Is it because in order to work in a big company they need to work well in a well-oiled machine? Of course not, and that is why we see these great products! So we have to trust the people that we hire even though the advantages aren’t immediately clear to us.

Persuading people to listen to you or putting your foot down might come over badly and that is why I see another reason for management to implement these features. Features are technically only really “features” when they’re being pointed out on the website for example. Can’t we also do that for security features?

You see it on every single fintech or security startup: “military grade encryption,” “AES-256 encryption,” and even more slang that more than half of the people don’t understand. Why can’t we add these features to the features pages of our websites? Should be just as easy as actually implementing them, right? It gives users a sense of security they otherwise wouldn’t have and another reason to choose your product over that of the competition.

In the meantime, I recommend we all use strong passwords or use a password manager that does the job for you. This will be your last defense, because even a very long and strong password can take years with weak password hashing algorithms. It just shouldn’t be taken for granted that the user uses strong passwords. It is also great to hear that companies learn from their mistakes and offer better security to their users like two-factor authentication. Dropbox handled the situation perfectly by doing so and taking responsibility for their shortcomings.

Andreas Backx is an Android and backend developer living in Belgium. He has co-founded Cloock and administers the AndroidChat Slack team.

photo credit: Protest against ACTA – 2012-01-28 – Toulouse – 12 via photopin (license)

Fill out the form to request access

We’ll review and get back at you

* indicates required