The Official (ISC)2 SSCP CBK Reference. Mike Wills

Чтение книги онлайн.

СКАЧАТЬ is guessed by an attacker on the user's system (the one your organization manages) or if the password manager vendor's central repository is breached. This should not be possible if proper encryption techniques are used in either case to protect the repository information while in use, at rest, and in motion; that said, it is a significant risk that must be addressed.

       Password managers entail another, much simpler risk, too, which is the possibility that the user might forget the master password. Eventual recovery might be possible, depending on the brand of password management software, but some operational disruption would be certain. This also requires users (individual or corporate) to repose great trust in their password management system vendor, the recovery agent, or both.

       Stay Current on Best Password Practices

      In 2017, the U.S. National Institute of Standards and Technology (NIST) has updated its password and passphrase policy recommendations. (See https://pages.nist.gov/800-63-3/sp800-63-3.html.) Based on many years of industry experience and with input from security researchers and academics alike, NIST's new recommendations overturn many of password policies that have been in widespread use for decades. For example, NIST no longer recommends requiring a periodic reset of user passwords, as this tends to promote poorer password hygiene among users. NIST also recommends against classical ideas of password complexity for the same reason. Many of these recommendations are reflected in this chapter; study them and see how they can be put to use to improve your organization's security posture.

       Passphrases

Since about 2016, more and more voices in the information security community have recommended the use of strong passphrases instead of passwords, primarily as a way to avoid all of the inherent failings of humans and human organizations to make effective use of more complex passwords. (One of the industry pundits who first advocated complex passwords actually offered a bit of an apology for doing so, as he acknowledged his change of heart on this topic.) A passphrase is a longer string of characters that ideally is both meaningful and memorable to its user and creator but is not easily inferred by others based on public knowledge about that individual. It should also not be a direct quote (with or without spaces and punctuation) from a published work. For example, if I am a well-known fan of J. R. R. Tolkien's body of fantasy works, a passphrase such as “inawholeindagroundlovedahobbit” might be too easy for someone to deduce based on my interests. (If I am anything but a fan of fantasy, by contrast, it just might be a start on a good passphrase.) Some of the best passphrases are made by combining four or five totally unrelated words together, with the occasional shift of letter case or a substitution of vowels with numbers. “Strongch33z3janerator,” for example, might start with “strong phrase generator” and be tweaked by the user into a phrase that might withstand attack for 35 quintillion years, according to www.howsecureismypassword.net (but don't use it as is because it's been published). Adding a few extra characters to a passphrase, such as tacking on a four-digit number to its end, does nothing for its overall hardness. Do be aware that many systems have length limits on the input fields for passwords (or passphrases) and advise users to stay within those lengths.

      Several key benefits come from using passphrases instead of classic but complex passwords:

       Users find them easier to create and remember, without relying on publicly available knowledge about them as a person.

       Longer passphrases exponentially increase the search space that a password cracker has to operate in, requiring much larger dictionaries or rainbow tables as well as far more CPU cycles.

       Passphrases actually make it easier for users to creatively use numbers, case shifts, and special characters as part of their phrase than they can in much shorter passwords.

      Security practitioners are also recommending that with proper use, passphrases do not benefit from being changed periodically.

      Passphrases, of course, are prone to being written down and to being reused on more than one system that the user has access to. Using a password manager application can help with these risks.

       Salt What You Know Before You Hash It

All but the most rudimentary legacy systems actually store a hash of a user's password, passphrase, or other Type I factor value; if an attacker exfiltrates a copy of the stored hash of the factor, they face a computationally infeasible (or tremendous brute force) burden of trying to unhash that back into its original plaintext form. This hash function should be applied at the endpoint device at which the user enters the factor so that only the hash is transmitted to the access control system.

      Secure hash functions can be made much more secure by appending a pseudorandomly generated salt value to the input plaintext version of the factor before hashing it. Secure frameworks and systems tools make it easier for systems administrators to add salt to their hash function use and provide many powerful ways to select and manage salts.

      There is no practical reason why the plaintext version of a Type I factor has to be stored in your system—anywhere.

       Security Questions

      Security questions are often used as an additional Type I factor during authentication. These often use a preset list of security questions that users must answer during account provisioning or after a password is forgotten. Typically, the system hashes the answers entered by the user (ideally at the user's endpoint device!) and stores the hashed answers in a table associated with the user ID. A very few systems treat the answer to a security question in ways that allow the user to vary the way that they enter it (such as with fewer blank spaces or in a different mix of upper and lowercase); while this may make “passing this quiz” easier on the user, it also reduces the security of the system overall and would not therefore be a recommended approach.

      At each login or access attempt, the user is asked to provide answers to a certain number of these questions. Retry logic might allow two incorrect responses to a set of five randomly chosen questions, for example, before the user must contact the help desk for assistance and verification of their identity.

      In many respects, security questions are just another set of passwords, and they suffer from all of the shortcomings and risks that passwords do. Users have been prone to take screenshots of the questions and answers as they first establish them and then store that file in an unprotected way on their system, for example. (You don't do that, do you?)

      In practice, most security questions reflect open source information (often called OSINT) about the subject—that is, information that is published or public-facing—which can be used to deduce both correct and incorrect answers to traditional security questions. Users can, of course, establish incorrect answers for these questions when the account is being provisioned, but those wrong answers still have to be memorable.

      Because of this, NIST has dropped security questions from its list of policy recommendations for user authentication. It might be argued that security questions can be used as part of a password reset dialog process; this might make life for your users easier at the risk of making it easier for an attacker to gain access.

NOTE Intelligence information also comes directly from humans (HUMINT), technical sources (TECHINT) such as your own network, and of course rumors (RUMINT). All of these, and more, should play valuable roles in your threat-hunting reconnaissance efforts.

СКАЧАТЬ