How secure are your passwords? In this video, you’ll learn about password complexity, length, expiration dates, recovery processes, and account lockouts.
<< Previous Video: Group PolicyNext: Privileges >>
When you’re deciding on what password policies you’re going to use on your network there are a number of best practices you should keep in mind. We want our passwords to be strong. We want them to be very difficult to guess. So we want to use a password that, perhaps, is more than just a single word.
We want this to, maybe, be a passphrase that uses multiple words. And make sure that we don’t use obvious passwords. You don’t want to use the name of your children, or the name of your pets. Maybe you’d like to also mix the upper and lower case of the letters, even if it is a single word. That way it would be a little bit more difficult to guess or to brute force. And we want to, perhaps, even use special characters.
We don’t want to replace things that are very common. For instance, you don’t want to replace an O with a 0. The bad guys already know that particular trick. Instead you want to embed special characters within the password or the passphrase that you’re using.
We consider strong passwords to be eight characters or longer. Once you get up into those longer number of characters it becomes much more difficult to brute force just because of all of the different options that have to be used for every single character. If someone has to check for uppercase, lowercase, and special characters across all eight of those characters it becomes much more difficult to go through every possible permutation.
We also want to be sure that the same passwords are not reused over and over again. Generally the systems that we’re using can remember all of the old passwords you were using. And as the security administrator you can generally tell the system how many of those passwords to remember. That way if somebody does gain access to one of you’re old passwords they would never be able to use it because you would never be reusing that password again.
If someone does gain access to your account we want to limit how long they’ll have access with that particular password. So what we’ll require is that our users change their password after a certain amount of time. Generally this is every 30 days, or 60 days, or 90 days. If you’re in an environment that’s very secure it may even be shorter amounts of time so that if somebody does gain access or compromises in account we are going to limit the amount of time they have access to those systems.
If someone forgets their password and needs their password reset we want to be sure that that process isn’t something that’s easily done. We don’t need the bad guys from the outside calling in and saying, hi, I’m Professor Messer. I’ve forgotten my account. I need you to reset my password, and then simply have somebody on the phone able to do that. There needs to be a verification process, or perhaps a secure method to communicate directly with the end user to make sure they understand what changes are being made to their account.
Many operating systems will automatically disable an account if somebody tries to log in with the incorrect credentials a certain number of times. This is usually what we would like to have happen in these operating systems because we don’t want somebody to be able to keep trying over, and over, and over hundreds or thousands of times until they will finally figure out your password and gain access to your account.
This could be a big problem for service accounts, however, if somebody’s trying to log in as a service account and you have a lot of automated services running with those credentials, and then that account gets locked out, it could then cause those services to no longer work. So there’s usually a balancing act between creating an account and having that lockout time for your service accounts.
When someone leaves your organization you may be tempted to simply delete their account and therefore that would keep them out of logging into systems that they previously had access to. But the best practice is actually to simply disable their account. This still prevents them from logging in, but it retains all of their files and all of their settings. And if you need access to any of those things, now that they left the organization, you can easily get it by gaining access to their systems behind the scenes.
This is a good best practice not only for small, but also large organizations. And there’s usually a process in place to finally remove all of the information they were working on, and move it to a separate account. And at that point you can then delete the older accounts.