CORRECTION: Password re-use bypass

Managing passwords is an important part of maintaining security on any network. A key aspect of enforcing the use of secure passwords is to use the password policy in a Windows 2000 GPO. The password policy can be used to require a minimum password length, set maximum and minimum password age, maintain a password history, require minimal complexity requirements, and even determine whether the password is stored using reversible encryption.

The password restrictions of Windows 2000 GPO are all well and good, except for one aspect of the password policy that can be bypassed by anyone performing one simple task. The vulnerable aspect of password policy is the password history. The password history retains a specified number of previously used passwords so that when a user is asked to change their password they are unable to reuse any password still present in the history list.

However, a loophole has been discovered that allows a user to re-use a recently used password. That loophole is as follows: Just change your password before the first warning prompt about changing your password appears. By default, the warning that you need to change your password appears 14 days before the actual expiration date. For example, if the maximum password age is 30 days, you can bypass the password history restriction and re-use any previously used password by electing to change your password anytime before the 16th day of the current password's aging.

This loophole exists because Windows 2000 only checks the history list after the 14-day warning message is displayed to the user.

Microsoft has been informed of this problem, but they have yet to acknowledge it or issue a fix. So, until Microsoft steps up with a patch -- don't tell your users.

About the author
James Michael Stewart is a researcher and writer for Lanwrights, Inc.

Upon further testing, tip author James Stewart discovered that this was in fact not a vulnerability. Following is his retraction.

My security tip regarding the ability to bypass the password history restriction of a Windows 2000 GPO may be incorrect. After additional testing by other security professionals and myself, I've discovered that the issue may lie more with how GPOs are applied and the grandfathering of existing passwords rather than an actual problem or issue with the security system of Windows 2000.

My original source for the tip was the BugTraq vulnerability list: http://online.securityfocus.com/bid/4256

I did perform initial testing on this issue, but I think I fell into one of the following two pitfalls: 1. The GPO where the history and password age may not have been properly applied to the system where I was testing the vulnerability. This time, I reboot each system (the DC server and the client) twice to ensure that the GPO would be in effect. 2. The password history seems to only record passwords in its list once they are changed, thus making the current or existing password grandfathered and not restricted by the newly updated GPO rules (i.e. it is not recorded in the history list). I was able to re-use the original password for the test account, but not any later password. I think I as well as the originator of this issue at BugTrag may have fallen into that trap.

My test process is detailed below. As you can see in step 15, I was able to re-use the original password defined in step 2. But notice that step 2 where the original password is defined appears before steps 3-7 where the GPO was defined and the GPO was forcibly applied to all systems. Once a password is recorded into the history list (steps 9, 12, 15, 20) by defining a new password, none of those passwords can be re-used (steps 18, 19, 23, 24, 25, 26).

Here is a step by step of my latest test that reveals the problem: 1. TestUser account created. 2. TestUser's password set to PassOne 3. domain GPO set with 18 password history, 42 maximum password age, and 0 minimum password age. 4. reboot server 5. reboot client 6. reboot server 7. reboot client 8. log on with TestUser 9. change password to PassTwo (success) 10. log out 11. log on with TestUser 12. change password to PassThree (success) 13. log out 14. log on with TestUser 15. change password to PassOne (success) 16. log out 17. log on with TestUser 18. change password to PassTwo (failed) 19. change password to PassThree (failed) 20. change password to PassFour (success) 21. log out 22. log on with TestUser 23. change password to PassOne (failed) 24. change password to PassTwo (failed) 25. change password to PassThree (failed) 26. change password to PassFour (failed)

I apologize for overlooking now-obvious issues and declaring a security vulnerability. If anyone has tested this vulnerability and found a legitimate bypass, please contact me with details.