LITMIR.BIZ

Скачать книгу

that cause other losses. As Bob Lockhart pointed out at https://www.tractica.com/biometrics/in-biometrics-which-error-rate-matters/, most real-world applications of access control have to operate well on the left side of this graph.

      Note, too, that regardless of which type or types of authentication factors your systems use, you also need to support these with administrative, logical, and physical processes for revocation of existing credentials, replacement of credentials that have been lost or stolen, and reissue or revalidation of credentials as part of periodic review of access privileges. This is covered in more depth later in this chapter.

      Let's look at these factors in some depth and each one's strengths and weaknesses when used as a single-factor authentication of a subject claiming to be a legitimate human user on your systems. (You'll learn about device authentication in more detail in Chapter 6, “Network and Communications Security.”)

Type I: Something You Know

      Everyone who has used a modern computer system is familiar with the first type of authentication factor, “something you know.” Common forms of this authentication factor include passwords, passphrases, personal identification numbers (PINs), and security questions. Some systems also ask users to authenticate themselves by confirming recent activity on the system, such as the last three transactions on a bank account. All of these forms assume that human memory and willpower can provide a reasonable degree of protection for the chosen type of “secret knowledge” used as the factor.

      Note that the more complex and secure you try to make your Type 1 factor implementations, the more you risk transforming into something the user has instead, by making the temptation to write it down somewhere too great to pass up. By the same token, a password manager such as LastPass is another device (albeit a software one) being used as the source of the authentication factor, rather than the human being's own memory. That said, current practice treats the use of password or passphrase managers as being part of the Type I authentication factor process and problem set.

       Passwords

      Almost every month, the news media publish a story about another data breach in which usernames and passwords were accessed, corrupted, or copied by the attackers. The damages suffered by individual users in such incidents can be both traumatic and financially crippling; the damage to the targeted business can be enough to put it out of business, and in extreme cases, its directors can suffer time in jail.

      Passwords are by far the most commonly used authentication mechanism and perhaps the one most prone to self-inflicted vulnerabilities when users:

       Choose trivial or easily cracked passwords.

       Forget their passwords.

       Fail to keep them safe and secure.

       Share them with others (whether those others are trusted systems users or not).

       Reuse the same password on multiple systems, websites, and accounts.

       Reuse the same password, or a simple transform of it, when asked by the system to change it.

       Leave passwords set to the default values set by the vendor or manufacturer.

       Store passwords on paper or in unprotected files kept on the systems or websites that they use.

In many cases, the use of password policies that require the use of special characters, numbers, and mixed case have contributed to these vulnerabilities, as many users find it difficult to create strong passwords in 12 to 16 characters or less that comply with such requirements. Requirements for frequent password changes also add to user frustration, which leads to some of the poor password security hygiene habits described in the previous list.

      At some point, the chosen length of a password causes the user to shift into thinking of it as a passphrase instead.

       Classical Password Policies—and Pitfalls

      Human beings just aren't good at creating a seemingly random, short string of text that makes for a strong password, in other words, one that is hard to guess but also easy for the user to remember. Despite this, many early ideas about password security became institutionalized, as reflected by their presence as security policy options in nearly all modern operating systems. These include the following:

       Complexity, which is usually interpreted as a mix of letters, symbols, and numbers used to transform a correctly spelled word into a secure password

       Minimum length, which may be as short as eight characters or more commonly 12 to 16 characters

       Reuse limitations, prohibiting the reuse of any of the last three to five passwords

       Prohibitions on commonly used words, such as names of days or months, names of sports teams, popular expressions, or other words in a restricted dictionary

      One problem with these policies is that these policies may end up leading users to create passwords that are easy for password-cracking algorithms to crack, even if they are too complex for the average human to guess at. Consider a password like “@u28&iza710n,” which a single CPU password cracker might need 200 years to crack, primarily because it's a few short transformations away from the word authorization. Switching the order of the front and back halves of that string do improve its strength—to about 76,000 years of single-CPU work factor. But in doing so, it's made the password harder to remember.

      Another problem with all of these policies is that they assume a common human understanding of what makes a chosen string of text, complete with special characters and misspellings, be a nonobvious choice for a password. The experts don't agree; how, then, can a billion users guess correctly on this? This leads to the incredible range of different password policy requirements that typical users see across the many websites and systems they interact with every day.

The stronger we attempt to make our password policies, the greater the frustration for our end users; and experience tells us that frustrated end users will find ways to cheat on the system and in doing so weaken its security.

      And no matter how complex we make our passwords (or passphrases), chances are that if they are easy for us as a user to use, they're also vulnerable to a quick peek from a shoulder-surfer. That quick peek doesn't have to capture the entire phrase—just enough of it to help a puzzle-freak combine their intuition, their open source knowledge of you and your personal history and habits, and the job or system you're working with to be able to feed some smart guesses into their favorite cracking tool.

      Complexity rules also run the risk of creating a false sense of security for administrators, users, and organizational senior leadership alike. More often than not, complexity rules that humans can use to select and use passwords can easily be broken by modern cracking tools, especially ones that draw upon zombie botnets to provide massive boosts to their computational capabilities.

      Passwords are useful as a first authentication step—but they should never be the one and only step.

      Password managers are software tools that provide users with a one-stop way to store, manage, and use all of their access credentials across many different platforms, systems, and websites. Password managers typically are used as browser extensions, providing automatic fill-in of the user's credentials when the browser navigates to a web page known to the password manager. They typically encrypt the stored user ID and password/passphrase information in a local file (sometimes called a vault). They can also be used to store and manage local device login information, such as the usernames, IP or MAC addresses, and passwords for a small office/home office (SOHO) router or modem or for other devices on the user's local area network. A single set of access credentials, typically an email address and a password,

Скачать книгу