Security in software: seriously, leave it to the experts

Table of Contents

· At a glance: what we should and shouldn’t do ourselves
Things we should do
Things we shouldn’t do
· A basic overview of password security
Encryption (hashing) algorithms
Rainbow tables
Salting
More computationally expensive algorithms
· The problem with doing it yourself
· Leave it to the experts

At a glance: what we should and shouldn’t do ourselves

As developers, when we build software, there are certain security practices we should and should not engage in. This is a non-exhaustive list.

Things we should do

  • Filter ALL user input, to prevent cross-site scripting attacks and other malicious code insertion
  • Use parameterised database queries to prevent SQL injection
  • Ensure all data that must remain private at all times, like API keys and secrets and user access tokens, are stored securely

Things we shouldn’t do

  • Attempt to make our own encryption algorithms or random number generators for cryptographic use, or make our own salt values
  • Insist on using a specific encryption algorithm hardcoded into our application, unless there is an extremely good reason (e.g. a complete lack of any standardised solution in the language in question)
  • Configure any security-related part of our software unless we know exactly what we are doing — leave it to someone better qualified (webserver configuration, etc)

A basic overview of password security

Encryption (hashing) algorithms

When you register for a website or service, you are asked to create a password. The website will use a one-way encryption algorithm to create a “hash” of your password: a hash is effectively a ‘string’ of letters and numbers (in computer science, a ‘string’ is like a word: some letters or other characters.). It then stores this hash, alongside your username, in its database.

  • The hash bears no relation to the password — if you change the password by one letter or number, the hash could change a lot or very little but it will never change in a predictable manner
  • You cannot feasibly turn the hash back into the password — i.e. the algorithm only goes one way

Rainbow tables

If you think about it, you could compromise any hashing algorithm by just computing the hash of every possible password up to a certain length, e.g. every password up to 20 characters long (and it has happened in the past — but wouldn’t work now). This is known as a rainbow table.

Salting

Salting is a common practice used for passwords today. Instead of hashing the password alone, you add a “salt” to it (another random string of letters and numbers), and hash the resulting string. You can then store the salt alongside the hash in your database.

More computationally expensive algorithms

MD5, and other algorithms like SHA1 and SHA256, are no longer used today for password security in any place that takes security seriously.

The problem with doing it yourself

Doing this kind of security work yourself frequently leaves your applications vulnerable to all sorts of attacks: from failing to use a proper cryptographically secure random number generator, or using your own salts that aren’t up to scratch, you can easily end up making a serious security vulnerability in your code.

Leave it to the experts

When you’re say, making a website — you might feel the temptation to implement your own password validation. Few people are insane or foolish enough to try and implement their own hashing algorithm, but quite a few will hardcode a specific existing one into their code. Don’t do this.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store