Read Time: 4 Minutes
Are your systems easy to hack?
How password key stretching can make your systems more secure?
Password theft is nothing new, but it keeps on making headlines. Everyone remembers the infamous Ashley Madison breach, where the personal details of the infidelity site’s users were discovered by hackers, sold on the Dark Web, and later published on the Internet for everyone to see.
However, this could happen to any company in any business – personal data is one of the key targets of cyber-attacks. In fact, your personal details can be up for sale on the Dark Web for as little as one dollar.
Passwords are now making top headlines also due to the Apple IPhone case, where Apple was sued by the FBI, who is trying to force them to help break the security features on a terrorism suspect’s iPhone. The Apple case has started a discussion on whether tech companies should design their encryption so that it can be bypassed for governmental investigations.
While a backdoor for the FBI to solve a clear terrorism case might sound like a reasonable request to many, it is the possible existence of a backdoor as such that is quite scary. What if it is not the FBI trying to get in for a good reason, but a hacker who has found the backdoor? Backdoors create security weaknesses that will allow a wide range of hackers to break into devices and data. And, encryption as such does not allow criminals to hide.
In the case of the Apple iPhone, the default encryption has been efficient enough to keep the FBI from fully accessing data stored on the device.
If you want to make sure your company is not the next one making the headlines with password theft disclosing company secrets and the personal data of employees, partners or customers, or if you wish to make sure you actually are right in saying that you have no means to break individual passwords, you need to do things right from the start. And from the start means when you are creating your requirement specification documentation. Only then can the coders actually do a proper job in safeguarding your systems.
So – how should you approach passwords?
People tend to create passwords that are quite simple to break with suitable tools and calculation power. Keyword stretching with a cryptographic hash function can be used on a system level to improve security. Using key stretching, you can benefit from the fact that you have to verify the user passwords only at the speed that users enter them.
Jarno Niemelä, Lead Researcher from F-Secure Labs explains:
The attacker who uses a brute force attack, is relying on the fact that he can do tens of billions of password guesses per second, for example this demonstration system back from 2012 did 68 billion SHA1 attempts per second, and with modern cards even higher speeds are more easily accessible. Also these days, instead of building a GPU cluster, you can simply get one from the Amazon cloud, and get whatever speed you want to pay for.
If you use key stretching you are cutting billions of attempts per second down to tens of thousands. For example, the 25-GPU cluster from 2012 did 63 billion SHA1 attempts per second, but when using Bcrypt, it was capable of only 71 thousand attempts.
Jarno has written two articles on password hashing and salting that you might be interested in reading or sharing with your more technical admins (“Are you sure SHA-1+salt is enough for passwords?”, and “No, Heavy Salting of Passwords is Not Enough, Use CUDA Accelerated PBKDF2”). Even though they are a couple of years old, they are still as valid as ever.
The point that Jarno makes in these posts is that simply hashing and salting is not enough. You need to limit the amount of password inputs with mathematical, advanced algorithms that the computer needs time to run, and that cannot be bypassed. Limiting attempts just by the clock (e.g. one per second) simply will not do the trick. Also, it might be a good idea to use two different types of algorithms – one to prevent bypassing the memory usage restrictions, and one to prevent someone from using even more efficient calculations.
Jarno’s personal favorite is combining Bcrypt or PBKDF2 and Scrypt functions, so that half of the allocated time is spent on Bcrypt or PBKDF2 and the other half in Scrypt. Scrypt offers very strong protection against GPU or CUDA-accelerated password cracking, and in case there is a weakness discovered in Scrypt, the password is still strongly protected with Bcrypt or PBKDF2.
Another thing that is crucial is to select a high enough iteration count for the key stretching functions. One should measure the iteration count that matches the time you can afford to verify a single user login. For example 500ms for a mobile device or PC and 1-10ms for a server.