Registered email addresses, password hashes leaked.
On Friday, Neil Spellings sent out an urgent email to all Spellings.net customers warning that a list of registered email addresses and password hashes from their online store have appeared on the web – and, it turns out, those hashes weren’t salted.
For a simple explanation of hashing and salting, see below. The important point at this stage is that unsalted password hashes stand a much better chance of being cracked than salted password hashes. That the passwords on Spellings.net’s servers were only hashed, therefore, means that anyone who’s data was included in that leak has a potentially vulnerable password – and if they used the same email address/password combo on other websites (which many people do, even though it is a very ill-advised practice), their log-ins to those other sites are therefore potentially vulnerable.
The Information Commissioner’s Office have been notified about the breach, and there is no evidence of any other information having been obtained. Importantly, spellings.net doesn’t store any debit or credit card details on the site – so customers do not need to worry on that score, at least.
It appears that in the process of trying to find the source of the leak, Spellings.net have identified a SQL injection flaw in some PHP code dating back to their old aemulor.com store, from over twelve years ago, and an audit of all the website code is underway “looking for further protential weaknesses to protect against attacks.”
Spellings.net have kept the store operational, but says that “unfortunately the security of the code written a decade ago has not been sufficient to protect against the multitude of miscreants out on the internet today.”
Passwords on the store have been reset, so should anyone manage to crack any passwords from the leaked hashes, they cannot use those passwords to access accounts on the website – but customers are strongly advised that if they re-used the same email address/password combination on other websites, they should change their passwords at those other sites.
It would appear that the new password is purely to prevent miscreants from accessing user accounts, but hasn’t been sent out to users – if a user needs to log-in themselves, they should visit the ‘password reminder‘ page to receive a(nother) new, temporary password, then log-in and change it to “a more convenient password.” Passwords are now hashed with a stronger algorithm, and salted.
Previously, when a new account was set up on the Spellings.net store, the same password that was used there was also used automatically to create a log-in on the support forums. That password has also been reset, and forum accounts are no longer being created automatically when a new account is created on the store – in future, users will need to create a separate support forum account themselves, should they need one.
Hashing is the process of running a password through a one way, cryptographic hash function. The password goes in, and the hash comes out. Rather than store a user’s password as part of their record, the hash is stored instead. Since the process is one way, when a someone attempts to log-in, the password they enter as part of that log-in is similarly passed to the cryptographic hash function. The resulting hash is compared to the hash stored in the database – if the same password was used, the same hash will result.
Although a hashing a password is a one way process – which means that there is no direct equivalent to a cryptographic hash function that turns a hash back into a password – that doesn’t mean password hashes can’t be cracked. There are a number of methods that can be used to crack them, with the simplest being a dictionary attack: Words are hashed (possibly starting with commonly used passwords), and the result compared to the password hash – a matching hash means the password has been found.
Brute force attacks are similar but, rather than dictionary words, all possible combinations of characters are used, increasing in length, until a match is found. This sort of attack is ‘computationally expensive’ – it takes longer; the longer any given password is, the longer it takes to crack it. Then there are attacks using lookup tables (where a table of possible passwords and their hashes are worked out beforehand, and the hashes then compared with those to be cracked) and derivations of the same idea.
This is where salting comes in.
Salting involves adding an additional string to the passwords before they are hashed – preferably generated for each user (and further, generated anew each time they change their password) using a CSPRNG (Cryptographically Secure Pseudo-Random Number Generator) function.
Adding the salt to the password makes it longer and, if the salt is unique to the user, even when two users happen to have the same password (which is far from unheard of, especially when many people have weak, obvious passwords) the combination of the salt and password will be unique – and so will the resulting hash: Two people using ‘password1’ as their password will have two completely different hashes stored.
This therefore makes an attack based on lookup tables much harder – because rather than a table being set up for all possible passwords, the table has to be generated again (and again, and again…) for each salt; the list of password hashes can no longer be attacked en masse, and instead each hash has to be tackled individually.