How Vendor Software Undercuts Password Controls

The biggest problem with password controls such as aging, resets and adhering to
strength guidelines is that vendor applications are sometimes the crippling factor in enforcing your rules.

For example, earlier versions (circa 2005-2006) of Oracle (<=11i) have an inherent password weakness that defeats most sensible strength rules. Google for "oracle password weakness" or "An Assessment of the Oracle Password Hashing Algorithm" by Josh Wright/Carlos Cid or http://www.integrigy.com/oracle-security-blog/archive/2006/12/12/oracle-apps-password-weakness to see some of the issue. Basically, Oracle passwords were converted to uppercase, certain special characters were restricted because they are used in standard DB queries and the hash algorithm were weak. 'marchany', 'marchan', would generate the same hash. This problem has been fixed in newer versions of Oracle but I believe it's in the Oracle Security package. Please verify that.

Also, the Apache mod_security feature can cripple password strength by disabling ANY special characters in input fields (to prevent SQL injection) but the net effect is that passwords strength is seriously weakened. One of the guys who works for me couldn't log into a web app
because the web developers used mod_security and he had special characters in his password.

My point in all of this is that BEFORE you embark on a mission of enforcing password strength, aging, etc., that you examine how ALL of your password enabled apps treat password features like strength, aging, etc. You may find that you are forced into a lowest common
denominator.