A good password should have at least eight characters and use all lowercase letters.

PINs, Passwords, and Passcodes

Determining passcode enforcement policy can be challenging for some organizations. It typically stems from traditional PC and Server 8-character password policies that require various complexities to achieve compliance or traditional security best practices. This is a prime example of traditional policies that just don’t work well in the mobile world. Requiring a user to enter an 8-character complex password to unlock their mobile device makes for a horrible user-experience.

Users are accustomed to a 4-character PIN. Most EMM policies can then enforce various complexities or wipe a device after 10 bad PIN entries. Many security conscious organizations have embraced App-level or Container-level passcodes to protect corporate data. And in those cases, some have incorporated a 6-character PIN or passcode at an App-level or Container-level.

Bottomline: it comes down to the organization, but it’s very important to consider the broader mobile security controls not found in the typical PC world (eg, Wipe after 10 bad passcode entries). It’s important to balance that with the user-experience to avoid lack of mobile adoption or causing users to circumvent security controls in other ways, commonly referred to as Shadow IT. Some of these options can include fingerprint authentication through Apple’s Touch ID or Samsung's fingerprint scanner. This can be use to authenticate at a device or container level.

Password Generation Calculations

One question you might be asking at this point is how many unique combinations of passwords are there? In order to be reasonable, let us start with the number of possible 8-character passwords by just using lowercase letters. The answer is shown in Figure 11.13 calculated by elPassword [elPassword]. In Figure 11.14, elPassword calculates the number of unique 8-character passwords using upper and lowercase letters, numbers, and special characters.

Using the online resource from LastBit, [LastBit] along with our best performance of 302,000 passwords per second, we can calculate the length of time required for a brute force attack. In Figure 11.15–11.18, I performed four separate runs. The first two using all lowercase characters with 1 and 100 computers, and the last two using the full ASCII set with 100 and 10,000 computers, respectively. Try them out for yourself.

Strong and Unique Passwords

The single most effective defense against a password cracker is to simply use a strong password. Although any password can eventually be cracked, there are degrees of magnitude in the time it takes to crack a six-character password and a 20-character password.

There are many password strength meters on the Internet, some built into the sites in which you may be registering an account, which allow users to receive immediate feedback on the strength of their password. Generally speaking, the stronger a password, the harder it is for a hacker to crack it. With this as general common knowledge, you would assume that most users would prefer to use a strong password that is easy to remember for their accounts. One recent data leak from www.rockyou.com proves this to be wrong. In December 2009, a hacker gained access to the user database of RockYou and learned that all 32 million account names and passwords were being stored in plaintext in the database.21 A follow-up review of the passwords showed that the vast majority of users chose weak passwords to protect their account.22 In fact, the most common password, used by more than 290,000 users, was “123456.”

Having such a simple password allows hackers to easily crack your password within mere minutes, if not seconds, even if it is encrypted. In practice, many people assumed that eight-character passwords were considered “secure enough” for the Web, but current recommendations are for passwords that are at least 15 characters long,23 as recommended by the SANS Institute's Password Policy, which we reviewed in Chapter 3, “Explore.” Additionally, passwords should also contain both upper and lower case characters along with special characters and should not be based on any dictionary term.

The simple practice of lengthening your passwords to 15 characters or more will disrupt most password crackers. At that length, with a good mixture of varying styles of characters, it would take years for most brute force applications to crack a password.

Although a strong password is critical to defending your data, it is useless if it is used across multiple sites. As soon as one site is compromised, and your password leaked, every other account that you have with the same password can also be compromised.

Constraining Data Types and Length

If you are collecting a date from a user, store it as a date in the database. If you are collecting an ID number, store it as a number in the database. If you are collecting an eight-character password, store it as a varchar of 8 characters maximum. If you combine the use of SqlParameter and data constraints, your code can reject data that doesn't belong. For example, if an attacker to tries to inject a new user account on the end of the password field:

our SqlParameter code will detect that the password is more than 8 characters long, and it will throw an exception. Alternatively, if an attacker tries to perform the same attack on a numeric field, the SqlParameter code will refuse it because the attack includes nonnumeric characters.

Hashing Pieces Separately

Older Windows-based clients store passwords in a format known as LanManager (LANMAN) hashes, which is a horribly insecure authentication scheme. However, since this chapter is about cryptography, we will limit the discussion of LANMAN authentication to the broken cryptography used for password storage.

As with UNIX password storage systems, LANMAN passwords are never stored on a system in cleartext format—they are always stored in a hash format. The problem is that the hashed format is implemented in such a way that even though DES is used to encrypt the password, the password can still be broken with relative ease. Each LANMAN password can contain up to 14 characters, and all passwords less than 14 characters are padded to bring the total password length up to 14 characters. During encryption the password is split into a pair of seven-character passwords, and each of these seven-character passwords is encrypted with DES. The final password hash consists of the two concatenated DES-encrypted password halves.

Since DES is known to be a reasonably secure algorithm, why is this implementation flawed? Shouldn't DES be uncrackable without significant effort? Not exactly. Recall that there are roughly 100 different characters that can be used in a password. Using the maximum possible password length of 14 characters, there should be about 10014 or 1.0x1028 possible password combinations. LANMAN passwords are further simplified because there is no distinction between upper-and lowercase letters—all letters appears as uppercase. Furthermore, if the password is less than eight characters, then the second half of the password hash is always identical and never even needs to be cracked. If only letters are used (no numbers or punctuation), then there can only be 267 (roughly eight billion) password combinations. While this may still seem like a large number of passwords to attack via brute force, remember that these are only theoretical maximums and that since most user passwords are quite weak, dictionary-based attacks will uncover them quickly. The bottom line here is that dictionary-based attacks on a pair of seven-character passwords (or even just one) are much faster than those on single 14-character passwords.

Suppose that strong passwords that use two or more symbols and numbers are used with the LANMAN hashing routine. The problem is that most users tend to just tack on the extra characters at the end of the password. For example, if a user uses his birthplace along with a string of numbers and symbols, such as “MONTANA45%,” the password is still insecure. LANMAN will break this password into the strings “MONTANA” and “45%.” The former will probably be caught quickly in a dictionary-based attack, and the latter will be discovered quickly in a brute force attack because it is only three characters. For newer business-oriented Microsoft operating systems such as Windows NT and Windows 2000, LANMAN hashing can and should be disabled in the registry if possible, though this will make it impossible for Win9x clients to authenticate to those machines.

6.1.4 Authentication and Access Control

•

Policies should be created that define the authentication and access control processes.

Authentication should be based on, as a minimum, user identification and complex password/pass phrase. Passwords should be a minimum of eight characters in length. Longer passwords are more secure and should contain upper and lower case characters, numbers, and special characters. This provides a character set of 95 possible characters. An eight-character password using a character set of 95 has a key space of 958, approximately 7×1015, or 7 quadrillion possible passwords. As the key space increases, the time required to perform an brute force attack on a password increases. The addition of two-factor authentication also increases security.

Employees should be not be given more privileges than what is needed to complete their tasks. This is called the principle of least privilege, which refers to restricting users, programs, and processes, to the lowest level of access, read/write, and execution rights necessary to do accomplish their intended work.

Access logs should be kept and reviewed periodically. Logs should be crosschecked with policy implementation.

Brute Force

With the brute force method, a series of passwords (whether or not exhaustive) is entered into a system. When the order is chosen in such a way that the most likely passwords are tried first, this is known as password guessing.7 In contrast to (U)SIMs and modern mobile operating systems, for example, a lot of devices have not limited the maximum number of consecutive incorrect attempts that can be made to enter a password. When dealing with embedded systems, users often select short, easy-to-guess passwords. The brute force method also has the great advantage that it is not usually destructive and can thus be tried first on an unknown system of which there is no other exemplar available. Some devices (e.g., BlackBerry, iPhone) will erase all data after a set number of incorrect password attempts. Depending on the type of system the password can be entered mechanically or electronically (see Figure 8.5 for a mechanic variant).

For a password hash read from embedded system memory, it is also possible to use offline password guessing or brute force. With this method hashes are calculated on a fast computer system and then compared with the extracted hash until a match is found. The found password is not necessarily the same as the original one because different passwords might have similar hashes.

Password Policies and Protections

Password policies are an area that is often treated too casually in network operations. In Windows 2003, it is extremely desirable to create and enforce strict password policies. Password attack tools are often free or available at low cost, and they allow an attacker to retrieve passwords for existing accounts or identify poor practices and vulnerabilities in a very short amount of time. Passwords should be changed at frequent intervals, should be a minimum of 8 characters (14 is preferred, since many password crackers can now retrieve 8-character passwords in a day or two), and should follow complexity rules. This means that the password should have letters, numbers, special characters, and upper/lower case in their construction. Passwords should not be names, parts of usernames, or common dictionary words or their derivatives. When trying to secure networks and resources, it is no longer an acceptable condition to accept insecure passwords or policies.

Windows 2003 allows us to configure these policies locally on workstations and standalone servers via the Local Security Policy management console in Administrative Tools. These locally created policies will apply to local accounts on the given machine only. If creating the policies in an Active Directory domain, the policies can be configured via the Domain Security Policy Group Policy Object. If a member of the domain, the domain policies will override the machine policies if the user is authenticating with the domain.

Defense

Defenses against access and escalation tools largely revolve around well-written and implemented password policy, patching, and system hardening. All are common and well-known security techniques, and are, in theory, some of the most basic security measures that we can put in place when securing our environment, but they are not as ubiquitously implemented as we might think.

Protection against password guessing and cracking tools largely revolves around ensuring that we have strong passwords in place. The common standard for strong passwords is: minimum length of eight characters, at least one uppercase character, at least one lowercase character, at least one number, and at least one symbol. Although this may seem excessive to some, we can see the difference in using such a password versus a more simple password quite easily.

An eight-character password using only lowercase and uppercase characters has 200 billion possible combinations. Given a reasonably powerful workstation (100,000,000 guesses per second), we could brute force our way through all of the possible combinations in around 30 min. Using the stronger password scheme that we specified above (uppercase, lowercase, numbers, symbols), our eight-character password has 7.2 quadrillion combinations and would take a little over 2 years to brute force [6]. Increasing the password length and adding additional character sets continues this trend, and can quickly make password guessing or cracking infeasible entirely, even for very powerful or distributed cracking tools.

Another key step to take, particularly in the case of defending against tools such as Metasploit or CANVAS, is to ensure that our systems are quickly patched. Many such tools can penetrate a system in a few seconds given unpatched vulnerabilities with which to work, and this is an easily avoidable situation. We can argue that installing application and operating system patches immediately after they are released is foolhardy and that we may cause more problems than we will fix, and this is likely true. We should absolutely take the time to test patches before we apply them, with exceptions to this being very few and far between. It is likely true that the exploits with which attackers gain entry to our systems will be older and more common, rather than cutting edge, but we should be patching for everything that we reasonably can, as soon as we can.

Lastly, we should harden our systems as much as we reasonably can and still allow them to execute their functions. The more ports, services, accounts, and so on that we leave enabled on a system, the larger attack surface that we present to those that would seek to compromise it. In many cases individual systems have very few tasks that require leaving outside access open, either incoming or outgoing, and closing down such potential methods of access greatly limits the set of tools that we leave for an attacker to utilize.

Enforcing Strong Passwords

If passwords are the central mechanism of your application's security, you must ensure that users have strong passwords. Establish a policy to ensure that passwords are complex enough to prevent someone guessing them easily. You can create a robust password policy by:

Enforcing a minimum password length of at least 8 characters

Not limiting the maximum password length

Requiring multiple character sets including lowercase letters, uppercase letters, numbers, and punctuation symbols

Allowing users to use any keyboard character in their passwords, including spaces

Not allowing dictionary words

Not allowing the username in any part of the password

TIP

Users are sometimes frustrated when they cannot come up with a password that meets complexity requirements. To avoid this problem, you might want to consider both length and number of character sets in the password as factors of complexity. Passwords that are longer but all lowercase are just as effective as shorter passwords that use multiple character sets. In general, adding two to four characters to the password's length is just as effective as adding a number or punctuation symbol. A six-character password with upper- and lowercase letters and punctuation is roughly equivalent in complexity to an eight-character password that is all lowercase.

Many popular Web sites do not enforce minimum passwords lengths, or they enforce a minimum length that is much too small to be secure. Figure 1.1 shows a Web site that allows passwords of only three characters and limits the maximum length to 25 characters. The minimum length is much too short, and although 25 characters is a long password, why impose any limit at all?

TIP

Another benefit of requiring long passwords is that it reduces the number of dictionary words available to users for use as their passwords. Passwords found in a dictionary are easily cracked and should be avoided. Setting a minimum password length of eight characters eliminates all three- to seven-letter words, of which there are about 50,000 words in an English dictionary. That is 50,000 fewer easily cracked passwords.

Many users will select predictable, easily guessable passwords if you do not enforce complexity requirements. Weak passwords are vulnerable to password-guessing brute-force attacks. If passwords are not long enough and do not contain multiple character sets, the number of guesses required to brute-force the password is greatly reduced. If an attacker is able to guess a user's password, he or she could use those user credentials to access restricted content, obtain sensitive user data, impersonate the user for a variety of purposes, delete or modify sensitive data, or even cancel the user's account.

WARNING

Attackers often try to guess passwords of eBay users by viewing the user's About Me page and gathering information about names of children, pets, friends, automobiles, or other interests. If an attacker can successfully guess a password, they authenticate to the account, change the password and contact information, and then list fake auctions under that user's account. This way they take advantage of the victim's reputation and feedback to defraud other users.

Ensuring Strong Passwords

To check password complexity, use a RegularExpressionValidator control or a CustomValidator control, as shown in Figure 1.2. This code assigns a CustomValidator to txtPassword. When validating form input, the control calls the PasswordCheck function. This is illustrated using C# in Figure 1.2 and VB.NET in Figure 1.3.

Figure 1.2. Validating Passwords Using a CustomValidator Control: C#

Figure 1.3. Validating Passwords Using a CustomValidator Control: VB.NET

WARNING

The most obvious way to hack weak passwords is to simply use a brute-force attack against the Web application. Any of the tools at http://neworder.box.sk/codebox.links.php?key=wwwcrks are useful for password cracking. If the Web application uses an HTML form for password entry, you might need to use a tool such as Elza (www.securityfocus.com/tools/1127). Of course, you will need some wordlists, which you can find at www.gattinger.org/wordlists/download.html or http://neworder.box.sk/codebox.links.php?key=passdict.