Choose the password configuration rules enforced by the passfilt.dll windows add-on.
|
https://workbench.cisecurity.org/files/2754
Exploring what’s next in tech – Insights, information, and ideas for today’s IT and business leaders + Subscribe Complexity, uniqueness, and periodic change have long been the top best practices for passwords, but new recommendations have led to changes around password policies.
Passwords were supposed to fix authentication. Instead, they have become a source of significant problems. Users continue to choose weak or simple-to-guess passwords and reuse the same passwords on multiple services. They also tend to question restrictions: "Which of these rules are reasonable? Which are most effective? Why do we have all these requirements?" Password policies continue to evolve even if user attitudes have not. Experts suggest placing more emphasis on checking passwords against known weak password lists and focusing less on password expiration policies. Here are the current best practices in use:
Over 1M people read enterprise.nxt. Are you one of them? Password standardsThe National Institute of Standards and Technology (NIST) addressed the question of password policies by issuing NIST Special Publication 800-63B (Digital Identity Guidelines – Authentication and Lifecycle Management). Section 5.1.1 “Memorized Secrets” has much to say about passwords and how they should be managed and stored. The requirements are actually pretty lenient: User-supplied passwords must be at least eight alphanumeric characters; passwords randomly generated by systems must be at least six characters and may be entirely numeric. NIST has been updating its standards and the most significant new requirement: The system must check prospective passwords against “a list that contains values known to be commonly used, expected, or compromised.” Types of passwords that might be disallowed based on such checks include:
To confuse the issue, NIST's recommendations are not specifically required; there is no organization whose role is
to enforce these policies, and NIST's guidelines explicitly recommend against complexity requirements. The rest of the NIST recommendations are smart measures based on common sense and real-world experience. For example:
Windows password policiesBecause the Windows domain password is the main password for users in so many enterprises, the default Windows policies are, at least, the starting point for most organizations. For many, there is no obvious reason to go any further than the defaults. The Windows default settings are not necessarily the same as those in the Windows Security Baselines, which are groups of
policy settings “based on feedback from Microsoft security engineering teams, product groups, partners, and customers.” The baselines are included in the Microsoft Security Compliance Toolkit, which also includes policy-related tools for administrators. The Security Baselines serve as another very common setting, by virtue of being a Microsoft-endorsed
configuration. The most interesting settings, at least recently, are the minimum and maximum password age. The minimum age is the number of days before users are allowed to change a password. The maximum is the number of days after which users must change their password. The default minimum is one day, both for Windows and the security baselines; the maximum defaults to 42 days for Windows and, until recently, 60 days in the security baselines. These settings are enabled in almost all default configurations. The default levels are changingBut in May 2019, Microsoft announced changes in the Security Baselines for Windows 10 and Windows Server build 1903: The minimum and maximum password ages will no longer be set in the baselines and therefore will not be enforced. Microsoft cites research (see "An Administrator’s Guide to Internet Password Research" and "The Security of Modern Password Expiration") to claim that password expiration policies are no longer considered to have great value. Other measures, such as checking lists of banned passwords, are more effective. As they note, Windows Group Policies don’t provide for checking such lists, so neither can the Security Baselines, which is a good example of why you should not rely only on the baselines. Microsoft offers some of the more advanced capabilities in Azure AD Password Protection. Password complexity: The ground rulesWhat is the default Windows password complexity policy?
Everyone who has had to deal with these policies, which are enabled in the Security Baselines, knows what a pain they can be. As the Microsoft document says, enabling the policies "may cause some additional help desk calls for locked-out accounts because users might not be used to having passwords that contain characters other than those found in the alphabet. However, this policy setting is liberal enough that all users should be able to abide by the requirements with a minor learning curve." The default password length requirement is seven characters, but elsewhere Microsoft recommends eight characters, as do the NIST requirements. In the Security Baselines, the minimum password length is 14 characters. The NIST policies specifically reject (though they do not ban) complexity requirements. Microsoft has not removed the default imposition of these requirements from Windows or the Security Baselines, but it may be a change you want to make yourself. If you want finer control of password filtering but want to stick with Active Directory, you can replace Microsoft’s standard Passfilt.dll with a commercial one or write one yourself, as Yelp did, based on an open source implementation. Examples of commercial replacements are those from nFront Security, ManageEngine, and Anixis. Using one of these replacements, you can implement current best practices within your otherwise standard Active Directory infrastructure. SecLists keeps a collection of many large common password lists. Beyond banned passwordsBanned password lists are useful, but another way may be better. Have I Been Pwned is a site that keeps records of major user ID and password breaches and allows you to check whether any of your logins have been compromised. The site was built and is maintained by Troy Hunt, a Microsoft regional director and well-known security expert. It has data on 369 breached sites and 7,860,402,548 breached accounts. The site also has an API that allows you to check whether a particular account has been breached or just if a particular password exists in the breach database. Hunt thinks that, once a list is as large as his, it is "exceptionally unlikely to have anything outside that collection which is both terrible and actively used.” The answer is to check against the separate Pwned Passwords database, which contains 551 million passwords that have been in one or more of the breaches, using its API. Hunt says he would set a minimum of six characters and then block anything that shows up in Pwned Passwords. One more tip from Hunt: “I’d block every variation of the company name; nobody on the Acme Corp. website can use AcmeCorp, AcmeCorp1, AcmeC0rp, etc.” If you want to use the Pwned Passwords API, you can build on one of the many projects already doing so. Typically, they create an environment-native interface to the API, such as with the many PHP libraries, Python and Perl scripts, WordPress plugins, and Java clients, as well as an IFTTT recipe. In addition to many weak passwords, Pwned Passwords has a large number of passwords that would satisfy any set of complexity rules, so it might seem to be overkill. But compared with the range of possible passwords, 551 million isn’t as big a number as it seems. Nearly all of my own passwords are randomly generated by my password manager, but I tested several passwords I made up on my own in recent years, and none appear in the Pwned Passwords database. So maybe relying on Hunt’s API and a minimum length and blocking organization name variants is the easiest route to strong protection. I wrote a program to check the contents of one of the SecLists lists of “common credentials” against the Pwned Passwords database. All but 3,663 of 262,000 passwords tested were in Pwned Passwords, and more than half of those that weren’t had fewer than eight characters. Perhaps this means that Hunt is right that checking banned password lists is largely redundant, though if you’re going to check one or the other, it’s easy enough to check both. But all of this is about usernames and passwords, a technology that we should all hope will someday be deprecated. At the same time you make sure your passwords are strong, move forward with multifactor authentication and biometrics that bypass the inherent problems with passwords. Password policy best practices: Lessons for leaders
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.
Larry Seltzer has long been a recognized expert in technology, known for industry analysis as well as security consulting and software development. Until 2013, he was editorial director of BYTE, Dark Reading, and Network Computing at UBM Tech. Prior to that, he spent more than a decade consulting and writing on technology subjects, primarily in the area of security. He is the author of three books and thousands of published articles and many more unpublished, private reports. Larry has been technical director at several test laboratories where he both directed and ran product testing, with a special interest in test automation. Larry began his career as a software engineer at now-defunct Desktop Software Corp. in Princeton, New Jersey, on the team that wrote the NPL 4GL query language. He also worked on corporate IT and software development at Chase Econometrics. Larry is a graduate of the University of Pennsylvania with a degree in public policy.
Larry SeltzerManaging editor, Enterprise.nxt Hewlett Packard Enterprise Larry Seltzer has long been a recognized expert in technology, known for industry analysis as well as security consulting and software development. Until 2013, he was editorial director of BYTE, Dark Reading, and Network Computing at UBM Tech. Prior to that, he spent more than a decade consulting and writing on technology subjects, primarily in the area of security. He is the author of three books and thousands of published articles and many more unpublished, private reports. Larry has been technical director at several test laboratories where he both directed and ran product testing, with a special interest in test automation. Larry began his career as a software engineer at now-defunct Desktop Software Corp. in Princeton, New Jersey, on the team that wrote the NPL 4GL query language. He also worked on corporate IT and software development at Chase Econometrics. Larry is a graduate of the University of Pennsylvania with a degree in public policy. Subscribe to the Enterprise.nxt newsletterStay up to date on the tech trends that are impacting the future of business Subscribe now Which type of instruction or code is executed from a Web browser to an end user's machine?XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user.
Which of the following security standards commonly supplements the use of an Internet Key Exchange?Internet Key Exchange (IKE) is a key management protocol standard used in conjunction with the Internet Protocol Security (IPSec) standard protocol.
Which of the following is a hardware token that generates a random string of characters to enter into a corresponding authentication application?Which of the following is a hardware token that generates a random string of characters to enter into a corresponding authentication application? Salt is random data that is used as additional input to a one-way function that hashes a password.
|
