Are passwords safe?

Passwords have traditionally been considered the easiest and most popular method of authentication. It is one of the most convenient methods for users as it does not require special skills or additional equipment, and it is secure - or is it?

Password authentication is as simple as ABC. Inventing and memorizing a strong password (or several passwords) is all what it takes, isn't it?

The short answer is that password authentication isn't that simple. According to the poll conducted by American Ponemon Institute, 88% of respondents have forgotten their password at least once in the recent two years. Employees often consider security measurements, which include passwords, excessive and unnecessary. They bridle at the requirement to change their passwords every 30 days and usually keep on using their old passwords in slightly amended versions i.e. with “0”, “1” or current year indication added to the old password.

Unfortunately, in the view of IT security, password authentication is hardly the best choice. As many other technical solutions, password authentication suffers from two things: human factor and technical inconsistency. Human factor involves users’ disability or simply unwillingness to memorize strong passwords as it is fairly difficult. As a result, they stick to simple passwords or passphrases.

Another scenario: if employees are forced to use strong passwords, they tend to put them down on the underside of their mouse pads or keyboards or on Post-it notes.

On the other hand, technical weaknesses and mistakes that were made on the stage of development and/or implementation of password auditing software pose a threat to secure password verification.

Password security should be evaluated with explicit binding to particular systems implementing password authentication. In general, a password that can be considered strong and safe in one system can appear to be weak in another. This contradiction is rooted in the fact that various software use different mechanisms of preventing brute force and password guessing attacks. It is also due to possible software vulnerabilities or insecure algorithms that are implemented.

One common way to resist password guessing attacks is to intentionally slow down password verification process. The user will not notice any difference whether password verification takes 10 nanoseconds or 10 milliseconds, but for the attacker such a change will dramatically reduce attack success probability: password cracking speed will drop from 100 million passwords per second to just 100 passwords per second.

Slowing down password verification is typically achieved by iteratively hashing password supplied by user. This method was first suggested in 1997 in «Secure Applications of Low-Entropy Keys» paper. As mentioned above, security of the entire system can be jeopardized due to software weaknesses such as insufficient length of the encryption key or insecure password transformation.

For instance, Microsoft Word and Excel 97 through 2003 use RC4 stream cipher with key length equal to 40 bit as the default encryption to protect files. This is caused by U.S. export restrictions on strong cryptography which were in effect until 1998. According to them, the length of encryption key was limited to 40 bit for symmetric and 512 bit for asymmetric algorithms. The restrictions have been lifted, but all new versions support original encryption algorithm in order to ensure backward compatibility.

When short 40-bit keys are used, the attacker does not need to guess the password itself, but can simply obtain the key, which only takes several seconds on a common PC. The security of the entire system is determined by the strength of its weakest component, so, if 40-bit encryption key is used, there is no sense using passwords with larger entropy.

Another well-known example of software weakness is password verification in Windows NT/2000/XP/2003. Two algorithms, LM and NTLM, are supported in the above-mentioned operating system versions. When a new user account is created or the user’s password is changed, LM- and NTLM-hashes are computed in saved in the accounts database.

Calculation of LM-hash function involves the following steps:

1. The user’s password as an OEM string is converted to uppercase.
2. This password is either space-padded or truncated to 14 bytes.
3. The “fixed-length” password is split into two 7-byte halves.
4. These values are used to create two DES keys, one from each 7-byte half.
5. These two ciphertext values are concatenated to form a 16-byte value, which is the LM hash.

There are two obvious security weaknesses inherent in LM encryption. First, the password is converted to uppercase which leads to a considerable decrease in its entropy. For example, for a 7-character password consisting of both digits and Latin letters entropy decreases from 41,7 to 36,2 bit, i.e. more than 45 times! Second, the effective password length is limited to seven characters as each 7-byte half can be attacked separately. Thus, there is no sense using passwords longer than 7 characters as they are no safer. LM password hashing is not secure, and its use should be avoided.

Understanding peculiarities of the current password verification is crucial while using passwords as a main means of authentication. Information about encryption used in the most popular operating systems and applications such as Windows, Linux, or Microsoft Office, is abundant and can be easily found on the Internet. The best way to get reliable information about password authentication in less popular systems is to hire an expert who will thoroughly examine the system, write a detailed report and give his recommendations.

Elcomsoft is exhibiting at Infosecurity Europe 2009, held on 28th - 30th April in its new venue Earl's Court, London. The event provides an unrivalled free education programme, exhibitors showcasing new and emerging technologies and offering practical and professional expertise. For further information please visit Infosec