Storing passwords in uncrackable form – Information for Web Server Admininstrators

News about intrusions into the servers of online stores, games vendors and other internet services can now be read on an almost daily basis. Often, the intruders obtain customers’ login data including their passwords. As many people use the same password in multiple places, criminals can use the passwords to obtain unauthorized access to further services.

To prevent passwords from being extracted, web site operators usually protect their users’ passwords through such cryptographic techniques as one-way hashing. For this purpose, a character string that doesn’t allow any conclusions to be drawn about the actual password is derived from the password. The only way of finding out whether a password matches a hash is to rehash the password and compare the results. This method is used by the authentication systems of operating systems and web applications – and also by password crackers.

MD5 hashing was long considered sufficiently resilient for this purpose, because the time that is required to try out all possible combinations made it difficult for attackers to reconstruct a password from a hash. With a strong password, trying out all password combinations (brute force attack) using a cracker such as John the Ripper on conventional hardware used to take months, if not years. But times have changed.

Cloud, CUDA and multi-core computer technologies are both a blessing and a curse: they can greatly accelerate the processing of data and make even complex simulations available to end users. Unfortunately, crackers use the same high-speed computing power to reconstruct plain-text data from an encrypted password, and then they use the password to log into a system as administrators. In this context, password crackers can take advantage of the fact that the harvested hashes were probably created using the MD5 algorithm, which is optimized for fast processing.

Commercial password crackers such as those by vendor Elcomsoft, and such free tools as Hashcat and BarsWF, can try out several million hashes per second to find out whether one of them matches a specific password. This means that a password of eight characters can be cracked in four days. However, there are even faster ways. As hard disk storage is getting cheaper and cheaper, attackers often use giant tables (rainbow tables) containing billions of pre-calculated hashes to find a password. These tables potentially allow them to determine a password within minutes. The lists required for dictionary attacks are also becoming longer and longer and, with very weak passwords, often enable cracking programs to succeed within hours.

Fortunately, progress has also been made in hashing technology that hampers high-speed password cracking attempts and makes it uneconomical for attackers to pre-calculate tables – even if the actual password to be cracked is weak. From a certain password length, calculating and storing rainbow tables is no longer viable in a reasonable amount of time. Therefore, an additional, random character string – a “salt” – is added to the password a user has entered. The newly created character string is passed through a hashing algorithm, and the resulting hash is stored in a file such as /etc/shadow. However, the salt must be known if a system is to compare subsequent password entries with the hash. The salt is therefore added to the beginning of the stored hash in plain text. Storing the salt in plain text may sound contradictory at first glance, but the salt doesn’t need to be secret, it only needs to be random. Its only purpose is to inflate the potential number of combinations for each individual password in order to exponentially increase the effort required to create rainbow tables.

However, a salt has only little impact when an individual password is attacked with brute force. Conventional hashing algorithms such as those for generating digital signatures or fingerprinting files are optimized for speed. This is counterproductive when checking passwords, as the intended aim is to thwart password crackers. Brute-force attacks can be rendered unattractive by intentionally slowing down the hashing algorithm or by hashing multiple times. For users, the required speed isn’t really an issue: They won’t notice if checking a password they enter when logging into a system takes a microsecond instead of a millisecond. A password cracker, on the other hand, will become a thousand times slower – instead of 100 million passwords per second, it will only be able to try out 100,000 passwords per second, and a brute-force attack on a password called “P4ssW0r7” would take 48 years instead of 18 days.

The method of artificially slowing things down has its origins in the derivation of crypto keys from passwords. As users’ passwords tend to be too short and have too little entropy, keys need to be lengthened securely, for example when encrypting via AES and 256 bits. Cryptographers call this “key stretching”, and they achieve it by sending a password through a hashing algorithm multiple times. The method has been standardized as Password-Based Key Derivation Function 2 (PBKDF2) and is, for instance, used in wireless networks with WPA-PSK keys. Smartphones use PBKDF to encrypt backup files with a password before exporting them. The method also successfully thwarts cracking attempts in those situations.

Each time, the resulting hash value is simply resubmitted to the hash function as a parameter. More complex round functions may, for instance, add the password to each value before it gets hashed. An operating system or application only needs to perform this exercise once per password and user. A cracking program, on the other hand, must perform it for every possible character combination – and each round adds processing time, so that the overall procedure for each password is slowed down immensely.

While many operating systems already use salts and key stretching techniques to securely store user passwords, password security is still a sore topic especially in popular web applications, even though such applications run the greatest risk of being attacked in an attempt to extract user or customer passwords. Sometimes, passwords are even still stored in plain text; and if they do get hashed, it might only be via MD5. Even such popular content management systems as Typo3 use MD5 without salt or rounds as their default method for hashing user passwords.

The “saltedpasswords” Typo3 extension promises to increase security. It offers added security via bcrypt or the phpass security framework; more about that in a moment. However, the extension must first be enabled and configured, which requires installing further extensions and making system adjustments – it’s hardly surprising that many operators simply use the default installation.

WordPress and phpBB use the phpass framework by developer Solar Designer – who, incidentally, also develops the John the Ripper password cracker. By default, phpass uses bcrypt. Bcrypt is based on the Blowfish algorithm which is, strictly speaking, an encryption algorithm rather than a hashing algorithm. Bcrypt uses a complex key initialization algorithm and further encrypts the resulting ciphertext by adding alternately the salt or the password. The number of rounds is a power of 2, and the exponent that is used is added to the beginning of the created string.

If the Blowfish algorithm isn’t implemented on a system, the phpass framework will automatically default to Extended DES and, if necessary, to MD5 with salt and iterations. To prevent the framework from falling back to weak algorithms, the developer recommends using PHP 5.3.2 or later. Blowfish, SHA-256 and SHA-512 are standard PHP components from this version, which means that no further operating system APIs or added libraries are required. Alternatively, the Suhosin PHP security framework will extend the PHP interpreter to include Blowfish.

However, WordPress and phpBB use the weakest of the three possible configurations. When tested on an Ubuntu system, WordPress used the MD5 variant; the CMS deliberately forces this variant to ensure the compatibility of various web applications. WordPress can reportedly use the phpBB user database, and vice versa. The Drupal developers, on the other hand, have adapted the framework for their purposes and started hashing with SHA-512 in Drupal 7. A “Secure Password Hashes” module provides added protection for older versions of Drupal.

The default security of the Joomla CMS isn’t as good as it could be, either. While the CMS is capable of using salted SHA-512 with multiple rounds (getCryptedPassword) via the crypt() PHP function, the default setting is a salt and MD5 with one round. Manually adjusting individual CMS installations to use a more secure variant is generally unproblematic. The only caveat is that add-on modules may be incompatible with the changes.

Self-test

How your own content management system stores passwords can be determined by analyzing its source code or by looking into its database. The latter solution is easiest and can simply be achieved by establishing a connection to the database server, for example like this: mysql -u <user> -p. The “user” parameter designates the registered database user which is used for the CMS to sign into the server. The command show databases; lists all available databases. For instance, to select the typo3 database, enter use typo3; (don’t forget the semicolon at the end). All available database tables can subsequently be displayed using show tables;.

Under Typo3, the most interesting tables are be_users and fe_users. select * from be_users; displays the table contents. If the user passwords contain a simple sequence of characters such as 1ee9e0daf4a2b81fe4064aa5ae31aae4, the system is using a simple, unsalted MD5 string.

In current Drupal installations, a (user table) password hash that is stored in the database may look like $S$CbkCbEtqypgcggWPee9c6wpgwUYqKjMb0pUR9YTgdwdYkxztRmWj

The dollar signs at the beginning enclose the hash type and are followed by the salt and the actual hash. The hash type value of 2a designates bcrypt. WordPress (wp_users table) will produce entries like $P$Bz0ZwGCmWuvcurZbj4CaptBFir8gQv1 – the “P” hash type designates what is called a portable hash – in other words, the MD5 variant.

Integration

Phpass is very easy to integrate into PHP applications. It consists of a single PHP file with one class and several methods. Although in modern versions of PHP all hash algorithms can also be called directly, the advantage of using phpass is that there is no need to worry about creating a random salt or assembling the character string. The returned hash string can be stored directly in the database.

On UNIX systems, phpass creates the salt by reading /dev/urandom, and under Windows it uses the microtime() PHP function. Two lines are sufficient to generate a secure password hash: $t_hasher = new PasswordHash(8, FALSE); $hash = $t_hasher->HashPassword($password);

The FALSE parameter in the constructor tells phpass to choose the most secure algorithm first – on modern systems, this will typically be bcrypt. Submitting TRUE forces the insecure, but more compatible, MD5 implementation to be used; this is, for instance, the approach chosen by WordPress. The constructor also generates the salt. In bcrypt, the 8 parameter determines the exponent for the required number of iterations, meaning that bcrypt uses 256 rounds. The maximum exponent is 31.

The HashPassword method then generates the hash from the password and the salt. Checking an entered password is equally simple: $check = $t_hasher->CheckPassword($password, $hash);

The $check variable contains the result of the comparison, where 1 is true.

Rather than relying on their system’s default settings, administrators should implement the most secure methods – and let their users know about it. However, when visiting a forum or online store, users have no influence on whether the operator uses a secure method. Even worse, it isn’t possible to ascertain which password encryption method is being used. Therefore, the best way for users to protect themselves is by always choosing different passwords. Using identical passwords for the Typo3 CMS and for a PayPal account should be avoided. The basic rule is: length is trumps – as long as the word isn’t contained in a dictionary. Passwords for less important accounts may be a bit shorter than those used for premium services.

 

Drupal Resets Passwords After Breach

Drupal.org has reset all account passwords after discovering that intruders had gained unauthorized access to information on its servers.

The Drupal.org security team says it has discovered unauthorized access to Drupal.org and groups.drupal.org account information which has exposed user names, country, and email addresses along with hashed passwords. No credit card information was stored on the servers, but the investigation is ongoing and the team says it “may learn about other types of information compromised”. According to Drupal.org, there are over 967,000 registered users on the Drupal.org.

The security team has reset all passwords on the systems and is advising all users that, to regain access, they will need to reset their password by going to https://drupal.org/user/password, entering their username or email address there and waiting for a password reset email. The site says these emails will take up to an hour to arrive due to the “current load”. The passwords stored on Drupal.org should be hashed and salted, the administrators say, but “some older passwords on some subsites were not salted”.

According to the advisory, unspecified third-party software installed on the Drupal.org servers was compromised and the breach was not due to a vulnerability in the Drupal software. The compromise was uncovered in the course of a security audit, during which a number of files were discovered which were apparently used to expose the user account information. The Drupal team are in contact with the developer of the third-party software to ensure that the problem is fixed and disclosed.

The Drupal.org administrators are working with the OSU Open Source Lab, who host Drupal.org, and are rebuilding production, staging and development servers and installing GRSEC secure kernels on most of them. They will now be routinely scanning for other malicious and dangerous files and say that, so far, they have not found any. Finally, older Drupal.org subsites for specific events have been converted to static archives.

The exposure of salted and hashed passwords is more of an issue these days as advances in password cracking through rainbow tables, crowd sourcing or cloud-based crackers makes it more likely that passwords will, eventually, be revealed. Users should ensure their passwords are not made up of words or phrases, ensure a good mix of character types in their passwords and use different passwords on different sites so that, if one site is compromised, it doesn’t expose them on all the sites they use. Administrators should look at using stronger encryption for passwords to ensure their security.