One of the most common questions I get is: How can I enforce strong passwords for my users who don't seem to care...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
about security? Weak passwords are no doubt one of the greatest vulnerabilities that threats far and wide seek to capitalize on for ill-gotten gains. Unfortunately, management and other employees often dictate password strategies and that's how many people get into trouble.
Looking at some of the longstanding password Group Policy Objects in Active Directory, many people have them wrong. They believe that the more stringent the better, but that's not always the case. For example, it's not uncommon to see Active Directory policies such as the following:
- Enforce password history: 730 days
- Maximum password age: 30 days
- Minimum password length: 10 characters
- Password must meet complexity requirements: Enabled
- Account lockout threshold: 3 attempts
For those of us who have worked in IT for years, it's not a huge deal to change -- and remember -- complex passwords every month. After all, we (usually) know how to create unbreakable passwords and we'll often use password managers to keep up with all of them. Putting ourselves in typical users' shoes, such policies are all but absurd. The underlying problem is that it's easy for us to leave users hanging, assuming they'll know what to do. Or, they can just deal with it because, after all, it's in the name of security.
Many users I speak with haven't had a second's worth of training on how to create complex passphrases. No one has shown them examples of passphrases that are super easy to remember yet shouldn't require changing more than once every 6-12 months (.e.g., Great_year2015!). Active Directory password policy settings and training are often an afterthought because, as many believe, there has to be more to security than just the basics. I've long believed that's not true and more and more research is supporting that theory.
As you work to make your enterprise passwords more resilient, be careful not to get caught up focusing only on your domain passwords. There are other crucial systems in your Windows environment that deserve -- and often don't have -- strong password policies such as:
- Local Windows accounts that may be exempt from the domain password policy (a common oversight).
- SQL Server databases running with standard (non-domain) authentication.
- Virtual machines, including development, QA and staging systems that aren't connected to the enterprise domain but still house production data and are accessible internally nonetheless.
- Websites and applications -- both internal and external.
- Firewalls, routers and related network infrastructure systems.
In the end, password standards and policies should be just that -- standards and policies that apply across the board. Windows Server or not, all it takes is one compromised password in your network to create trouble. Spend the coming year nailing down your passwords. First, determine where your risks are. You might already know where you're weak without having to perform a formal assessment or audit. If not, you can use general vulnerability scanners such as Nexpose and LanGuard. Microsoft's free MBSA tool (currently in version 2.3, which happens to support Windows Server 2012 R2) is a decent alternative if you just want to look at your Windows systems. There are also password cracking-specific tools such as those offered by Elcomsoft and L0phtcrack that can uncover -- and demonstrate at a much deeper level -- where your weaknesses are.
Once you determine where things stand with your passwords, it's time to fine-tune your standards and flesh out your policies so that they properly reflect what you're trying to accomplish. Finally, use Active Directory -- or perhaps a third-party password/Active Directory audit tool such as those offered by Avatier, ManageEngine and Netwrix -- to enforce your passwords. Remember, after your password standards and policies are developed, if you start creating exceptions for certain groups of people and systems across the enterprise, that's when trouble can creep in.