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.

Mobile Device Security

A couple of years ago, we started investigating the IT security of mobile devices and the 1st generation of smart phone. Grant Jacoby was the first of a couple of grad student who researched how to implement some sort of IDS on PDAs and smart phones. He discovered that the Windows Mobile OS doesn't allow access to raw sockets supposedly for "security" reasons. This restriction basically prevented us from writing any type of IDS program for that platform.

So, how could we create an IDS that would be effective on those platforms? We decided to look at the power output of the batteries to see if we could detect aberrant behavior. We discovered a number of things.

1. Smart batteries are supposed to output their power readings every second. We discovered that interval varied from 1-9 seconds. So, much for standards.....
2. For idle devices, we were able to detect anomalous behavior by monitoring the power output of the batteries.
3. We couldn't determine the type of attacks but we can definitely say "something is attacking us" :-)

If you want the gory details, check our IEEE Security & Privacy article on the subject. The link is at http://www.computer.org/portal/web/csdl/doi/10.1109/MSP.2006.139.

rcm