Internet Security II: Slowing Things Down

"You will not be punished for your anger; you will be punished by your anger." -- Buddhist proverb

• Internet Security Part I: Cryptography and the Darknet
• Internet Security Part II: Slowing Things Down
• Internet Security Part III: Salting Your Hashes

Here's an interesting geeky snippet you probably don't know. The substantial part of progress in computing technology over the last handful of decades has been about making computers, and computational processes, faster and more efficient. However, there is one very important area of computing technology where significant improvements have been made in deliberately making things slower and less efficient (and no it's not Windows startup time - that's just a coincidence). Making the process more "computationally expensive" as us geeks like to say, just so that you think we're clever and will hopefully pay us more money.

By now some of my geek friends will already know what I'm talking about, because this actually is a rarity. Normally when we make things slower it's by mistake, there really are very few things we *try* to make slower. What I'm talking about is a facet of computer security to do with the processing of passwords.

Basic web security says that you never (ever) store user passwords. If you store a user password, however carefully, there's a chance it can be found. If you don't store the password it can't. Standard practise, which reduces rather than eliminates risk, is instead to store a "one way hash" (actually a salted one way hash, maybe another day I'll explain salting). A hash of a password is effectively a very, very large number, and everything in computers is a number when it comes down to it, that represents the password. Given a password typed in by the user you can put it through the algorithm that turns it into a hash and compare it with the stored hash. If they match then the user has supplied the right password and if it doesn't they haven't, and yes this means there is an infinitesimally small chance that by coincidence someone could supply a wrong password that happens to hash the same way - this is a tiny but literally calculated risk. This way you can still check if the user has given you the right password without having to actually store their password. It's called a one way hash because you can go from a password to a hash easily but not easily back from a hash to a password. Genius, right?

Except modern computers are astonishingly fast, and what's more nowadays you can trivially easily (honestly) use cloud computing to perform similar calculations on hundreds of computers simultaneously. So even with hashing in place it's possible to just try every possible password until you eventually find the right one. This is called a "brute force" attack. (There are a whole class of computing problems where "brute force" is the only known way of finding the best solution, these are called "NP hard" problems and they include the knapsack problem and the travelling salesman problem, which are problems delivery drivers have to solve every working day. Delivery drivers solve these problems a similar way to how programmers solve NP hard problems that they can't actually use brute force on because it's too slow; take a best guess and get on with it.)

The solution to the problem of cracking passwords by force, or at least the best amelioration to date, is to use a hashing algorithm that is really expensive. i.e. to make the process of checking if a password is correct "computationally expensive", very slow and requiring a lot of memory. So a brute force attack, whilst still theoretically possible becomes effectively impossible in practise. There you go, slowing things down for the good of all humanity.

For the true geeks amongst you, up until recently the recommended slow hashing algorithm was one called "PBKDF2". The latest hotness, I believe, is called "Argon2". Slow hashing is a rapidly changing field.

The looming scary monster on the horizon is not the ordinary progress of computing technology we've seen so far, you'd still probably have to have a million computers churning away until the heat death of the universe to crack some of our codes. The scary thing is the maybe-real-maybe-not-who-knows quantum computing which is gradually emerging. This takes a completely different approach to solving this kind of problem, and if we ever get it right. Well, that's a whole different kettle of ball games. The bottom line is that no-one knows what scary terrors await us on the other side of the future, and the only sensible thing to do in the meantime is make sure you enjoy today and cuddle the people you love. A lot.


You may also be interested in the following programming related articles:

• The Craft of Software Engineering
• Abstractions and Business Processes
• Software Engineering Abstractions: Design and Testing

"There's an Islamic teaching that one of the prayers that is never refused or not granted is one for true guidance and truth. It is, after all, the only key to open the door. Just ask."