Rants (go to Raves)

More than 30 years old, there is absolutely no excuse for having this vulnerability in your system! What's really bad is that IT risk and compliance auditors rarely check for this in physical security systems. In a recent client engagement, auditors never checked for a factory default password that I learned about from a science fiction book publshed years ago. The same system also had the other common default password vulnerability, the installer default password. Auditors missed both, which had been in use for years.

The factory default password is really bad because you can usually find it in quick start guides, user manuals, and installation instructions downloadable from the Web. The installer default password really irks me because it doesn't ship with the system—it is a system vulnerability that the installer puts there, and into the same brand of system for every other customer who has it.

Believe it or not, there is also the customer default password! This is commonly installed by lazy (be honest!) customer technicians who have many system of the same brand (common with DVRs, for example). You learn one password, you now have access to the systems at all locations.

Commonly, I find that customers with this vulnerability have no written password policy. But even some who do have a policy don't audit against it or enforce it. (Shame on you!).

An audited written password policy is a simple countermeasure that cures the problem. The only excuse for not establishing one is laziness, and of course that's no excuse.

1. Establish a sound password policy that forbids default or master passwords or logons. There are plenty of examples on the Web. Require at least annual audits (but also see #2 below).
2. Enforce its application. Make all in-house and outside service personnel sign a committment to apply and enforce the policy. For example, require that at the start of each service call the first action (and last action on the last day for multiple days of service) is a password review.
3. Keep a list of all systems subject to this policy. Make sure the auditors have it.

Do you even know if any of your systems have default passwords in place? Most systems do. It's time to find out, isn't it?

This vulnerability is deadly because it is invisible to most customers, and it can't be changed by the customer. So—unilke default factory passwords—the customer can't just change a mandatory database logon without breaking the security system that uses it.

Instead, the csutomer must put stringent computer and network security measures in place, and may not be able to deploy the system in the way it was intended. That stinks!

Just last week I downloaded a user guide (from the Web) to a video management system software product, and what did I find? Holy Credentials, Batman! A single mandatory logon for all of the systems network devices as well as for the database! To make matters worse, the manual discusses putting the system on the Internet!

But that's not all, Batman! Holy Integrator Shortcoming—no installer has yet complained about this!

End User Warning: Make sure that the products you procure don't require mandatory logons, or else make sure that your systems integrator or IT department puts appropriate security measures into place. If possible, don't buy the product, and make it known to the company's senior executives from the CEO on down that you don't purchase products with built-in fixed vulnerabilities. If you don't get a thank-you note or other good response from the company write a rant at this site.

We from the IT world expect that all the modern developments over the last 10-15 years in the information processing field have been applied to modern computer systems. When it comes to passwords, this means we expect systems to store passwords securely. We are way past the point where vendors can get away with storing passwords in the clear or through some trivial obfuscation mechanism.

And all the cheap programmer tricks your PACS engineering team thinks are cute, like ROT-13 and XOR (a simple scheme for changing around the 0's and 1's that represent password characters in the computer), have been identified long ago by hackers, reverse engineers, your competitors, and the bad guys.

If a system requires authentication, in modern times one expects the implementor to do one of a small list of tried and true techniques:

• Use the windows logon for access so you leverage all the Windows access control features.
• Use a username/password logon over a secure path (HTTPS not HTTP), and store the passwords securely locally. Assume 10-20 years worth of attack technology is looking over your shoulder when you design this. Don't get cute, be conservative and secure. Use a standards-based mechanism if at all possible.
• Use or support a two-factor authentication mechanism.
• When you pass this test be ready to be challenged on what kind of role-based access control and governance controls (i.e. operator access management logging) you offer.

Some companies you don't want to be compared to:

    vendors who use XOR

    vendors (like Adobe) who've been caught using ROT-13

    vendors who store passwords in the clear

    vendors who store passwords in the clear and are visible from SNMP via default credentials

And remember: if you let users provide short passwords then it doesn't matter how good your password mechanism is, because a password guessing attack can be mounted. If the passwords aren't at least 8 characters, they're easily guessable. Get over it and get some honest to goodness password handling.