In the last few years, we've been seeing some significant changes in the suggestions that security experts are making for password security. While previous guidance increasingly pushed complexity in terms of password length, the mix of characters used, controls over password reuse, and forced periodic changes, specialists have been questioning whether making passwords complex wasn't actually working against security concerns rather than promoting them.\nSecurity specialists have also argued that forcing complexity down users' throats has led to them writing passwords down or forgetting them and having to get them reset. They argued that replacing a password character with a digit or an uppercase character might make a password look complicated, but does not actually make it any less vulnerable to compromise. In fact, when users are forced to include a variety of characters in their passwords, they generally do so in very predictable ways. Instead of \u201cpassword\u201d, they might use \u201cPassw0rd\u201d or even \u201cP4ssw0rd!\u201d, but the variations don't make the passwords significantly less guessable. People are just not very good at generating anything that's truly random.\nThe other argument that's been made is that putting the onus of generating and using complex passwords on the heads of the end users leaves them with a lot of stress and responsibility that might be better handled in some other way.\nThese changes in password composition recommendations have been coming at us for a while \u2013 generally in articles or posts about how setting overly strict password complexity standards might actually be making accounts less safe. Still, it's only been since NIST's fairly recent draft of its Special Publication 800-63-3: Digital Identity Guidelines (https:\/\/pages.nist.gov\/800-63-3\/) that those of us who manage servers have really begun to feel the need to sit back and pay attention. What do the rule changes mean to us? What might we do differently?\nWhile these guidelines primarily apply to government agencies, the same guidance will likely work its way into companies who work with government agencies, have government customers, or simply want to adhere to what is likely to soon be considered best practice.\n\nThe Gist of the NIST List\nThe new NIST guidance on passwords suggests that:\n\npasswords never expire\nno required character complexity or variety rules be implemented\nthe maximum length for passwords be set to 64 characters\nthe minimum length for passwords be set to 8 characters\npasswords be checked against known bad passwords, banned lists, etc.\nno hints or knowledge-based questions be provided to someone trying to log in (like \u201cWho was your best friend in high school?\u201d)\npasswords only be changed when forgotten\n\nOn Unix and Linux systems, there is no maximum length setting for passwords \u2013 no \u201cmaxlen\u201d to complement the \u201cminlen\u201d setting. Even so, the likelihood of anyone even trying to set their passwords to use more than 64 characters seems quite unlikely.\nAs for minimum password length, the suggestion doesn't mean that you shouldn't consider setting your minimum password length to greater than 8 characters. I would still go with requiring 12-16 characters, especially if you remind your users that passwords can be fairly arbitrary and still be memorable. A phrase that they can remember like \u201cCan I go home now?\u201d or even \u201cIneedmorecoffee!\u201d would work.\nYou can also encourage your users to use truly random passwords -- like those generated by some of the password safe products. Passwords don't have to be easy to remember if they are cut and pasted as needed. The key to this strategy, however, is that they never forget the key to the safe.\nOf course, the new guidance is not simply a relaxation of all constraints on passwords. The intent is to move away from complexity that doesn't improve security to complexity that does. Checking passwords to make sure they're not dictionary words, clearly based on dictionary words, related to the username, etc. are key to ensuring that they're reasonably good. And, luckily, for Linux systems administrators, there's always pam_pwquality. It will run new passwords against a series of checks that include 1) can't be a palindrome (e.g., racecar), 2) can't be simply a case change from the former password, 3) can't be too similar to the old password, 4) can't be too simple, 5) can't be a rotation of the old password, 6) can't have repeated characters (optional), and 7) can't contain the user's name. These configurable checks and some guidance provided to your users on how to most easily construct a password that is both easy to remember and hard to guess will go a long way toward keeping you in NIST's good graces and relieving your users of their password anxieties.\nUser vs Service Accounts\nThe new NIST guidelines are intended to improve password security while taking the heat off your end users. They do not, however, need to be applied against all accounts. A former colleague of mine, Ryan Hill, now Director, Systems Engineering at BECU (https:\/\/www.becu.org\/) suggests using different policies for service\/resource (non-human) accounts and user (human) accounts. He encourages shifting user accounts toward the new NIST guidelines that favor length over complexity while pushing service\/resource accounts toward greater entropy (lowered predictability) and length since these accounts are rarely used for logins.\nWrap-Up\nRelieving users of the need to reset their passwords every few months while steering them toward passwords that are genuinely difficult to guess is likely to be a big step forward and not the big step backward that dropping complexity might have first seemed it would be.