Password Policies
Do you have a password policy for your organization? You probably should. I have read a lot about password policies in recent weeks, and there seems to be some controversy about the best approach to take. Here's my method for the madness. Keep in mind that this is just the best I have been able to come up with so far. As Bill Gates recently mentioned, passwords may be on the way out. Barring the premature demise of the password, these recommendations are subject to change:
Password Complexity - I use Group Policy to enforce complexity requirements, which by Microsoft's standards is to include 3 out of the 4 possible types of characters (lowercase letters, capital letters, numbers, and symbols).
Password length - Again, a Group Policy setting. I am currently allowing a minimum of 8 characters. The longer the password, the harder it is to crack. One other detail: all Windows server operating systems, by default, generate LM hashes for all passwords 14 characters or shorter. LM hashes are relatively weak, and should be disabled (another Group Policy setting) if possible. Another easy way to avoid LM hashes is to use a password of 15 characters or more. I couldn't quite get that one approved, but I tried.
Account lockout settings - This is a tricky one. I have heard arguments going both ways on this one, but most accounts would consider this to be Security Theater. If you enable account lockout policies, you are most likely attempting to avoid having a malicious individual from attempting to "guess," or bruteforce, an account password. On the surface, it sounds like configuring that account to be locked out after a handful of failed attempts would be a good idea. There are two problems with that approach. The first is an administrative issue. As soon as you enable that lockout feature, you will have users calling you (or your helpdesk) complaining that they have locked out their account because they forgot they had CAPS lock on or some similar issue. Secondly, it would seem trivially simple for a malicious user to effectively cause a denial-of-service attack by typing in the wrong password to an account multiple times in order to lock it out. Imagine you enabled this feature throughout your domain, and someone managed to lock out a service account, or all the domain or enterprise admin accounts! Sounds kind of risky to me.
Best practices - While all of these options I have mentioned have involved technical controls, meaning you are using settings in Active Directory to mandate certain password conditions, there are other steps that you should take that are not always as simple as a setting in Group Policy. For instance, tell your users to avoid using dictionary words in their passwords. Even with complex passwords of sufficient length, dictionary attacks can be fairly effective. Another idea is not necessarily to avoid those dictionary words, but to use more than one. I think the idea of a passphrase instead of a password seems like a pretty effective technique. For instance, the passphrase "My dog's name is Max" is an extremely strong password. It has capital and lowercase letters, it has special characters, it is 20 characters long, and it is extremely easy to remember (provided you actually have a dog, and have named him accordingly). Easy to remember is a good approach for your users, so you won't have to deal with passwords written on a Post-It note under their keyboard.
Password Complexity - I use Group Policy to enforce complexity requirements, which by Microsoft's standards is to include 3 out of the 4 possible types of characters (lowercase letters, capital letters, numbers, and symbols).
Password length - Again, a Group Policy setting. I am currently allowing a minimum of 8 characters. The longer the password, the harder it is to crack. One other detail: all Windows server operating systems, by default, generate LM hashes for all passwords 14 characters or shorter. LM hashes are relatively weak, and should be disabled (another Group Policy setting) if possible. Another easy way to avoid LM hashes is to use a password of 15 characters or more. I couldn't quite get that one approved, but I tried.
Account lockout settings - This is a tricky one. I have heard arguments going both ways on this one, but most accounts would consider this to be Security Theater. If you enable account lockout policies, you are most likely attempting to avoid having a malicious individual from attempting to "guess," or bruteforce, an account password. On the surface, it sounds like configuring that account to be locked out after a handful of failed attempts would be a good idea. There are two problems with that approach. The first is an administrative issue. As soon as you enable that lockout feature, you will have users calling you (or your helpdesk) complaining that they have locked out their account because they forgot they had CAPS lock on or some similar issue. Secondly, it would seem trivially simple for a malicious user to effectively cause a denial-of-service attack by typing in the wrong password to an account multiple times in order to lock it out. Imagine you enabled this feature throughout your domain, and someone managed to lock out a service account, or all the domain or enterprise admin accounts! Sounds kind of risky to me.
Best practices - While all of these options I have mentioned have involved technical controls, meaning you are using settings in Active Directory to mandate certain password conditions, there are other steps that you should take that are not always as simple as a setting in Group Policy. For instance, tell your users to avoid using dictionary words in their passwords. Even with complex passwords of sufficient length, dictionary attacks can be fairly effective. Another idea is not necessarily to avoid those dictionary words, but to use more than one. I think the idea of a passphrase instead of a password seems like a pretty effective technique. For instance, the passphrase "My dog's name is Max" is an extremely strong password. It has capital and lowercase letters, it has special characters, it is 20 characters long, and it is extremely easy to remember (provided you actually have a dog, and have named him accordingly). Easy to remember is a good approach for your users, so you won't have to deal with passwords written on a Post-It note under their keyboard.
Post Continues...
posted by i3ia5i at 10:38 PM
0 Comments:
Post a Comment
<< Home