How Blueberry Solves Password Handling

It’s a complex issue. Not only do we need to ensure that we build a robust system, but users often make themselves more vulnerable to password theft by choosing weak passwords, and so we need to consider how to address the bad habits users fall into as well.

It’s also a constantly evolving battle between developer and hacker as each side develops new tools and strategies. But in all the years that Blueberry has spent thinking and testing and developing systems with extremely tough data security measures, there are certain rules that we always follow. Here are our four golden rules of password security:

This first rule is very simple – only the user sees their password. This means that administrators should never have access to the user’s password. For example, in cases of a forgotten password, the best practice is to have support trigger a reset procedure. By following this rule, you take out any risk of human mis-use, which helps keep the user’s password safe, and protects the administrator from getting into trouble.

If there is one best practice that users should definitely follow, it is to choose a different password for each account. Unfortunately, this is probably the one that gets broken the most. We could require users to choose a password that is complex and hence unlikely to be used elsewhere, but this generally annoys users too much.

It’s a bit easier to help people stick to the next best practice of password security – use a long password. A password that is 10 characters long is roughly 500,000 times harder to crack than one that is six characters long.

You could apply even more stringent guidance such as requiring passwords to contain symbols as well, but I’m not personally convinced by overly complicated rules. If we make security too complex, users will tend to write down their passwords onto post-it notes, which pretty much defeats the point.

When Blueberry develops web systems, we use a standard algorithm to show the user how secure their chosen password is as they type it in. We also enforce reasonable standards for password choice – such as using a combination of letters and numbers, and making the password eight characters or longer.

However, we also go one step further: we look up user passwords in a dictionary of known common passwords, and warn the user if their selected password is on the list.  We also check to see if a user is using a common pattern of password such as ‘tree123’.

Let’s say a hacker gains access to your PC. What’s the first thing he does? He opens your email and searches for ‘password’. He’ll find emails from people and systems saying “the password is X”.  He takes these passwords and puts them into a tool which checks to see if the password works on Facebook, Google, Amazon and every bank.  If he’s lucky, he gets into an account and jackpot – he goes on a spending spree…

To prevent this, online systems should never, ever send passwords in an email. If I find an online system doing this, I always send a complaint to the owner. Thankfully, I see this happening a lot less than before.

The best way to allow a user to reset their password is to send an email with a link to the password-reset page, and set the link to expire within a reasonable time.

The big scandals of recent years have been situations where a hacker gains access to a server, and steals millions of passwords and other user details. The obvious first step is to protect the servers with good firewalls and other security measures. But if a hacker still manages to find a way in, we need to have an extra layer of protection by securing the passwords themselves too.

The standard technique for securing passwords is ‘hashing and salting’. Hashing uses special algorithms to convert a password into a long series of jumbled numbers and letters which cannot be reversed. This allows the hashed password to be used to check a future login, but the password itself can’t be obtained. But hackers don’t usually stop there. They’ll have a few more tricks up their sleeves, including dictionaries of common hashed passwords which they can use to check against the stolen database. If they find a match, they’ve got the password. Which is why we also need to add ‘salt’ to passwords. Salting is an extra random number added to the password before hashing and goes a long way to providing extra protection against attacks.

Modern day hackers are always looking for more sophisticated ways to attack and are very resourceful – even building a mini GPU supercomputer from gaming video cards that can test millions of passwords per second. But by constantly switching to tougher hashing algorithms that are much harder to break and helping people make strong password choices, we can help ward off these attacks.

So if you see a system owner breaking any of the golden rules of password protection, set them straight! Bad password handling risks more than hackers getting into their system – it can expose other online systems to attack and cause personal loss to many.