Technology has developed so rapidly in most areas of computing it is easy to overlook the areas that haven't developed in decades. Password-based authentication is probably one of the most critical technical functions that we all use every day, yet it hasn't evolved much since the first multi-user computer systems. We continue to use this archaic form of authentication out of convenience even as more secure methods are developed. Moore's Law marches on as well, which continually provides faster processors to crack password databases in less time. The dismal results of this continued focus on convenience over security were demonstrated this summer through password breaches at social networking giant LinkedIn, radio streaming service LastFM and online dating site eHarmony.
These breaches demonstrate a potentially fatal flaw in using password authentication to protect cloud-based information assets. While the breaches occurred with consumer cloud services, commercial cloud providers often use the same technology. Consequently, companies looking to securely store proprietary information with a cloud-based provider will need to understand not just what cloud authentication is in use but how that authentication is implemented behind the scenes. This knowledge, coupled with an understanding of the encryption functions and attack methods, will help a company truly understand the risk of using a particular cloud provider.
Testing cloud password-based authentication
Cloud providers have many options available to safely store password information but most use the same open-source hashing libraries. This is true of LinkedIn, LastFM, eHarmony and probably many other sites as well. A cloud provider following this model will only store an encrypted version of a password using a one-way cryptographic hash.
There are some simple tests to verify that the cloud provider is using some type of password encryption. The first test is to request a password reset. If the password is emailed back in clear text, that's an obvious failure that shows the provider is storing the password in clear text without any encryption. The other test is simply to examine the characters that can be used to create the password. If the system restricts special characters from being used in the password, it's a good possibility the password is stored in clear text. The reason for this is that SQL databases interpret certain special characters as providing special functions and not as simply as data, so they need to be restricted. A system that fails either of these tests should not be trusted with any confidential data.
Hashing tools are built into Linux distributions and provide a good platform for understanding password encryption. These tools are available for Windows as well for those not comfortable with the Linux command line. Enter the following at a command prompt in your favorite Linux distribution to generate an MD5 encrypted hash:
echo –n 'asdfghj'|md5sum>password.txt
This combination of commands sends the text string "asdfghj" through the md5sum command and redirects the output to password.txt. The text string "asdfghj" should now be represented by the encrypted hash of "c83b2d5bb1fb4d93d9d064593ed6eea2." This is how the password would be represented in the database of a cloud provider such as eHarmony. The cloud provider does not know what the original password was nor can it reverse the encryption to recover the password.
This is where Moore's Law turns into a detriment instead of a benefit. The one-way encrypted hash algorithm was conceived when processors lacked the performance required to compute all of the possible combinations in a reasonable amount of time. In the past, the only way to attack these hashes was to attempt to brute-force the encryption, which took months or years. Today, pre-computed (rainbow) tables of encrypted hashes encompassing all possible combinations are freely available for download. An attack on password-based authentication then becomes a simple comparison function between the rainbow tables and the target hashes. This is an easy task for modern computing hardware.
Modern cracking programs utilize high-end video cards to boost performance of the CPUs to further reduce the time necessary for matching hashes. These graphic processing units (GPUs) were designed to do the high-end math necessary to render modern 3D video games. They are often faster than the CPU at these predefined tasks and contain much faster memory and wider I/O channels to facilitate rapid computation. This design element has an unintended consequence: These GPUs are well-suited for cracking encryption. For example, a single GeForce GTX 680 contains 1536 cores that can be put to work matching hashes to rainbow tables.
Cracking password-based authentication
I evaluated several tools that use GPUs in order to accelerate the rainbow-table hashing matching process. Each tool has its strengths and weaknesses; some are strong on SHA1 or MD5 hashes, while others are focused on cracking Microsoft Windows NTLM hashes used in enterprise networks. I focused on Crytpohaze GRTCrack, as it supports multiple types of hashing algorithms as well as both GPU manufacturers, AMD and NVIDIA. It also runs equally well on 64-bit Windows or Linux and is fairly easy to set up with rainbow tables. It can even be run on an Amazon EC2 instance, if the appropriate hardware is unavailable.
Cryptohaze GRTCrack uses rainbow tables that can be downloaded, but only limited lengths are available due to size restrictions. The password length determines the number of possible password combinations; these file sizes vary greatly from 41 GB for a seven-character table to a whopping 1.4 TB for an eight-character table. The addition of a single character increases the size of the size of the file by over 3,400%. The massive increase in size demonstrates how password length is crucial when using cloud-based services; it's much faster to evaluate 41 GB of hashes than 1.4 TB.
I now had all the components in place to run Cryptohaze against the password.txt file that I generated earlier. The format of the command is:
GRTCrack-OPenCL -h MD5 -f password.txt /pathtorainbowtables/rainbowtable.grt
The results showed up on my very modest test rig in a very short 15 seconds with the decrypted password "asdfghj." Password hashes are easily bypassed even with low-end hardware.
Strengthening password-based authentication
There are several ways to limit the effectiveness of these powerful password cracking tools. The first is to utilize salted hashes. A salt is randomly generated information that is added to the data before running through the hashing process. This way the encrypted value cannot be pre-computed, rendering rainbow tables useless for cracking the password. The salt will have to be stored in the database, which could get compromised. However, the salt should be different for each password, which will dramatically increase the amount of time necessary to decrypt each record. LinkedIn is adding salt to all accounts as passwords are changed or created, to increase security since its breach.
Two-factor authentication is another method that may be required to increase security when authenticating to cloud-based services. The Google Authenticator is a free tool for adding two-factor authentication to Google accounts, but it can also be added to Linux systems as well. Many of the newer Linux distributions already include the code necessary to use Google Authenticator. This is an inexpensive way to add additional security to prevent unauthorized access, even in the event of a hashed password breach.
One thing is certain: Technology will continue to advance, making password-based authentication for cloud services less viable in the future. Password length will need to increase until the point that it becomes impractical to manage. Companies looking to use cloud-services need to investigate the type of password hashing and the use of salted hashes when evaluating potential cloud providers. Security professionals need to keep current on password hashing technologies as well as new attack vectors in order to effectively manage this ever-evolving type of risk.
About the author:
Joseph Granneman, CISSP, has over 20 years in information technology and security with experience in both healthcare and financial services. He has been involved in the Health Information Security and Privacy Working Group for Illinois, the Certification Commission for Health Information Technology (CCHIT) Security Working Group, and is an active InfraGard member.