Twitter Password Reset and Media Panic Stories

 

Introduction

The Twitter data breach showcases the possible up-and-coming storm from the media on data breaches, especially that it still struggles to understand some of the technical elements involved in a breach. With the Facebook/Cambridge Analytica story making the news headlines, the media now know that they have a technically-related topic that the general public are interested in. And so Twitter is the most recent major Cloud Service Provider who has hit the headlines:

So many in the media this was pushed as a major story, but it was just a typical story of someone making a mistake and which was quickly righted. The chances of any related data breach is minimal as it was only an internal processing mistake. For most companies the error would go unreported external, but in the days of the media chasing for cover-ups and evidence of bad practice, Twitter did the right thing and reported it. The media, of course, go for shock headlines, and which can panic users (and shareholders).

A bit of hashing

In most system a password is never stored in its original format, and is hashed in some way. The three main ways to crack a hash are:

• Using a rainbow table. This method uses a table of pre-computed hashes and which match to passwords. The intruder then searches for the hashed value and then can map it back to the original password. This method can be overcome with the usage of a random salt string, and which is added to the password, and then hashed.
•  Using a dictionary attack. In a dictionary attack the attacher will try common words from a dictionary and then, with the salt string, see if they can get the same hashed value. As many people still use words from a dictionary, this method is often successful for weak passwords.
• Using brute force. If the above two methods do not work, then the intruder will basically try different permutations of characters.

In the following we see an eight GPU cluster can crack most eight character passwords within a few minutes, and has a rate of cracking at Tera-hashes/secord (over 1,000,000,000,000 hashes per second):

The traditional hashes such as MD5, SHA-1 and SHA-256 are fast at converting, but this has the downside that an attacker can then uses a GPU cracker to brute force  the passwords. To overcome this we use a slow hashing method such as:

• Bcrypt. Bcrypt. This creates a hash value which has salt.
• PBKDF2. PBKDF2. The PBKDF2 method created a salted hashed value, and which is used to generate the main key for TrueCrypt.
• PBKDF2 (Part 2). PBKDF2. The PBKDF2 method created a salted hashed value, and which is used to generate the main key for TrueCrypt.
• Scrypt. Scrypt. The Scrypt method created a salted hashed value using iterations and salting.
• Argon2. Go. Outline of Argon2.
• Balloon. Go. Outline of Balloon.
• HKDF. Go. Outline of HKDF (HMAC Key Derivation function).

These methods intentionally slow down the computionation of the hash, and even try to overflow the method of the GPU, so that it will struggle to compute the hash. We can see that if we crack at 1 THashes per second, and with any eight character password with upper and lower-case and numbers, the time to crack ever single eight character password is 3.64 minutes [link]:

If we use BCrypt and hash at a rate of 200 hashes per second  [Link]:

In this case it would take 34,594 years to crack a single eight character BCrypt hashed password by bruce force. If someone uses a password from a dictionary, then the strength of protection reduces greatly. For example a password of "123456" will be cracked almost instantly with a dictionary attack on BCrypt. If the password is in position 10,000 on the most popular passwords, then, at a hashing rate of 200 hashes per second, the password would be discovered in just 50 seconds.

Classifications of incidents

Recently the NCSC defined a classification system for Cyber attacks.  While this is a good starting point, but we need to better define incidents, especially as companies will need to respond to major data breaches within 72 hours. Overall recent data breaches, such as Equifax and Talk Talk, have been poorly reported on, and there is left a great deal of vagueness about the scope of the breach. Companies will thus have to have stronger investigation and reporting procedures, and which have been well-drilled. They will then be able to report on the details of an incident in a way which both the media and citizens can understand.

The NCSC classifications at least give a severity level, and where citizens could assess the severity of any data loss and its impact. Overall it will need stronger dissemination plans around incident reporting, especially to find the right channels, and for those who will assess a data breach to understand its impact. Important factors in reporting might be to define who the attackers were (such as hackers, spies, and nation states), the tools they have used, the access they used within the data breach, the results and scope of the hack, and objectives of the attackers has been. There is no standard way to report, but companies will have to increasingly focus on the impact on personal information, and deal with any issues within short time scales.


With GDPR on the horizon, the risk of not reporting is probably as bad as not reporting.  With a 72 hour time limit on reporting, companies (and the media) will have to become a whole lot smarter in the way that they report incidences, especially in articulating the true risk of a data breach. We perhaps need an improved taxonomy for incident report, and come classification system which truly defines the severity of a breach?

For Equifax it was possibly an 8 (out of 10), and for Twitter is was a 1. A 10 might be the hack of a major digital certificate provider (eg Verisign) or a Cloud Provider (eg for Microsoft Azure or Amazon AWS), and a 9 might be the hack of a major Cloud Service Provider (eg Facebook) or a bank. The scale might be:

10: Severve risk to systems and for them to be compromised.
9: Large-scale risk to financial compromise for affected accounts.
etc.

Conclusions

Twitter's mistake was to use the original password and a salt value to compute the BCrypt hash, and where the plaintext passwords were stored within an internal log. Overall Twitter didn't reveal why they were doing this, but it may be a pre-GDPR compute of more secure hashed passwords. For many companies, though, there is probably no need to store the original passwords anywhere, as it can become a target.


So ... don't use the same password for all your systems ... turn on multi-factor authentication ... don't use standard words from a dictionary ... and make sure your password is at least 10 characters.