We recently came across an interesting article on Ars Technica (original link here http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/) which described how hackers set out to reveal user passwords. While we take more than a passing interest in security processes and related technologies, the results of the hacking attempts (and our own subsequent tests) proved to be disturbing.
No doubt, everyone knows (and also loathes) the golden rules of managing passwords:
1. Always use a complex password with upper and lower case letters, special characters and numbers;
2. Never use the same password on multiple systems;
3. Never use words found in a dictionary or that can be easily guessed; and
4. Never use a password less than 8 characters.
To see whether the results reported were genuine, we spent some time reverse engineering the process of how we would hack one of our systems populated with test data to see whether the above was just FUD or if the results were believable.
Step 1: Break into the system
Given we built the system, breaking in should be easy? We made life a little more difficult by simulating real conditions where the only access method was to actually find an exploit in the application or systems. Unfortunately for this first part of our test, defence in depth is still a very solid technique to protect systems. Even tapping into the knowledge of the developer who built the system, accessing critical information proved to be very difficult.
Outcome: You really can’t overstate the importance of the concept of ‘defence in depth’. Layers of security such as securing administrative access, changing default passwords (simple, but you’d be surprised how often default vendor accounts are left active), using layered firewalls, intrusion prevention systems, application firewalls and enforcing logical security zones and boundaries may not stop a determined hacker but the delay they impose allows security teams time to analyse the hack and put in place preventative measures prior to it being successful.
Step 2: Cheat – download the database of hashed passwords
To continue our experiment, we decided to cheat and bypass the disk encryption, security and lockout tools and ‘stole’ a copy of the conveniently unencrypted database backup. This contained passwords hashed using MD5, SHA1 and bcrypt. We then set to work getting access to the passwords.
Unsurprisingly, MD5 and SHA1 passwords began to be revealed almost immediately using hacking tools freely available on the internet. After 30 mins, one of our team had revealed up to 40% of the passwords listed in the MD5 and SHA1 tables by relying on nothing other than the default settings. Once we added common substitutions and patterns (0 for o @ for a, capital first letters, etc) and a dictionary list of words, the success rate for recovering passwords went up to above 70% without a significant increase in effort. What was surprising is that we also saw similar results to the Ars Technica team in the recovery of what were considered complex passwords.
As expected, bcrypt hashed databases started the hacking tools and CPU working at 100%. While this was identical to the MD5 and SHA1 attempts, we noticed a huge reduction in the volume of passwords being returned. If you’re interested in knowing why, have a read of (http://en.wikipedia.org/wiki/Bcrypt). In short, this is because bcrypt makes the hacking device work exponentially harder to get the same results.
Outcome: The storage of passwords can be just as important as the policies determining their strength. Ensure that physical and logical security of all aspects of data storage including backups, non-production systems and the disposal of faulty hard disks, backup devices and obsolete equipment is reviewed regularly.
Step 3: Exploit the hack
At this point we’ve recovered usernames and passwords for the application. As we used a backup copy of the database, some time had passed since the passwords were stored and logging into the application proved to be more difficult than expected due to mandatory password reset policies. Unfortunately for the hacking team, the intrusion prevention systems and application firewalls started detecting numerous failed login attempts from the same source and began alerting system administrators to this attempt. We then simulated a real attack by distributing the logins from different IPs, varying the access attempt intervals, retry attempts, IP addresses and source device information to make the traffic look as legitimate as possible.
In the real world, depending on the motivation for the attack, exploitation may not come in the form of login attempts or access to the user data. The attack may be for bragging rights, as payback for a real or perceived offence, for financial gain or simply to embarrass the organisation. Another often overlooked motivation has been a significant increase in well-funded and highly competent criminal and nation-state hacking.
So what?
The biggest learning from this exercise was that, when viewed as an isolated task, the leaps made in processing and cloud computing power mean that traditional views on password complexity and assumptions on brute force difficulty can no longer be relied upon as good enough to secure passwords. More than ever, a strong password can only be considered as one component of an overall security solution.
We also confirmed that passwords of 8 characters provided no more security than passwords of 6 characters. The best passwords were ones which did not conform to a pattern and were greater than 16 characters in length. Appreciably, these passwords are not all that conducive to a good user experience!
