Our organization has not yet enabled the "password must meet complexity requirements" option in the Active Directory...
Group Policy password policy settings for our domain. I would like to enable this setting, but I am concerned about what this will do to existing user accounts. Will it immediately invalidate all user passwords if they do not currently meet the new standards, or will it only take effect the next time they are prompted to change their password? How should we go about managing the transition?
The Group Policy setting in Active Directory that you describe will have no effect on existing accounts until users try to change or update their passwords. So, yes, if their passwords don't meet the password complexity requirements, they'll stay the same until they're prompted to change them. (Note: Systems running OSes older than Windows 2000 don't support Active Directory password policy management.)
Password policies are set through the Group Policy Objects editor, which is part of the Active Directory administration GUI. These policies should be configured for the whole domain, rather than individual workstations, to maintain consistency across the network.
Additionally, Active Directory can be used to manage password age, history and length. Plus it can manage password complexity, which means using a mix of uppercase and lowercase letters and numbers, and ensuring a password doesn't have at least three consecutive characters from the username. This not only prevents someone from using his or her user ID as a password, but also can cut down on many common brute force and dictionary attacks. Of course, it's not foolproof, but it's an effective part of a multilayered authentication.
The Group Policy should also be set to force users to change their passwords after a set time period, with frequency depending on the risk level of the data being protected and, of course, your organization's business needs and requirements.
The best way to manage such a transition would depend on the size of the organization. For a larger organization, a phased-in approach is best. Send an announcement to users -- either through the corporate Intranet, a logon banner, or a mass email -- giving them dates and locations for the changes in password policies.
For a customer portal application, once a user has successfully logged in, should he/she be allowed to see his/her current security password-retrieval answer? Does it matter if the portal uses a single sign-on (SSO) system?
Security questions and answers are still authentication credentials, just like a user ID and password, or any other login credential, for that matter. As such, they should have the same protections as a user ID and password. Whether or not the portal uses SSO is irrelevant. A login is a login, no matter whether it comes through a single authentication system, or a complex one, like SSO.
You wouldn't expose a user's password on a desktop or online, right? Think of a security question and answer as an extension to a password.
Just as a reminder, here are some rules, or best practices, for safe handling of passwords that should be applied to security questions and answers, as well.
- The answers to a question, once answered by the user, should never be displayed again. In future instances when it would be displayed, it should be blanked out, or covered with asterisks, just like a password.
- If a user needs to reset the answer to a question, he or she should be redirected to that question and asked to answer it again.
- If a user forgets the answer to a question, again, just like resetting a password, he or she should be redirected to the question to re-answer it, or be sent to a question-reset page.
- If the user wants to add, delete or change a question, the same rule applies. He or she should be asked to start the question-and-answer process again from scratch.
Now, keep in mind there's one key difference between a question reset and a password reset. When a password is reset, it's a best practice for a system administrator or the help desk to issue a temporary password good only once and then only for a short period, say 24 hours. Once the user logs on with the temporary password, he or she is prompted for a new password, and the temporary password is invalidated. This way, the password is always kept secret and isn't accessible even to system administrators or the help desk.
This is because, unlike a password, security answers are almost always initially set up by the user, while initial passwords are usually set up by an administrator or other IT staff.
For more information:
- In this tip, Joel Dubin offers best practices and tools for ensuring password compliance.
- Learn how to safely distribute passwords to new users.
Dig Deeper on Active Directory security
Related Q&A from Joel Dubin
Ensuring authenticity of online communications is critical to conduct business. Learn how to use a public key and private key in digital signatures ... Continue Reading
Learn about the purpose of CAPTCHA challenges that enable websites to differentiate bots from authentic users to stop spammers from hijacking forums ... Continue Reading
Proper planning is at the top of the list for single sign-on best practices, but it's important to get enterprise SSO implementations off to a good ... Continue Reading