If you DO write it down . . .

another Password Manifesto by Dan Hadaway

Shhh. 

Once again I’m huddled over my laptop, wondering if I’m really going to submit this to be posted and/or published.  You see, once again I’m going to go ahead and say it:  some of our beliefs about non-technical controls are myths.  I talked about this once at a conference and my evaluation ratings came back either very good or very bad.

This whole thing started long ago, when I started giving talks designed to teach my clients’ Acceptable Use Policies, with an emphasis on why rather than what.  But in those days, I never imagined I’d end up here,  huddled over my laptop in fear, wondering and agonizing about whether this article will ever be published.

You see, a long time ago, I published an article in a couple of places that was called The Password Manifesto.  It made the case that password aging had aged as a non-technical control, and since then smart people who have responded to my proposition have helped me tweak my belief to this:  password aging was no longer a meaningful control for certain types of applications.  It should still be in our arsenal and there are many authentication systems that should require aging, but we shouldn’t always have to use it.

The response was very good and very bad.  I still have people sending me kudos and scoldings.  Some loved the idea, said it was about time; and others complained that they had finally got their co-workers on board changing their password every 30-50 days and they didn’t need me undermining all they have worked for.

But I still believe that password aging is not necessary, because aging is not going to protect you from cracker software that can go through a dictionary in less than 20 seconds.  Aging is now outdated simply because even the strongest passwords can be cracked in far less time than passwords can age.  Because we require strong passwords on the network and in front of segregated sensitive information, aging only hinders good password practices.  Aging encourages written passwords, incremental passwords, and other ways to trick technical strength enforcement.

Several of  my critics were clients and/or friends.  And when we’d get together, after they reminded me of their distaste, I responded that it’s important to remember that authentication should be designed in layers.  Not only should we never rely upon one control, but the overall design is what should be analyzed and tested, not any one layer.  We must view authentication systems (and other systems of control) holistically, and use system thinking when changing the system.  Password strength requirements, management, policies prohibiting the writing-down of passwords, and testing techniques all play into the picture.

Manifesto

As I continue to teach acceptable use to bank employees, another recognition of reality affects my set of beliefs about “layered authentication.”  The planned non-enforcement of the policy about not writing passwords down needs to be exposed.  We teach that you should never write passwords down, then we say “but if you do, shred what you write them down on” and “if you must, at least hide where you keep them written down” and/or “if you put them in a spreadsheet, and that’s against the policy mind-you, but if you do, at least don’t name the file ‘password’ and use a password on the file that you don’t write down!”

Pragmatism results from realization, and we need to realize that no matter what our policy says, our employees write down passwords.

I realize that we auditors and examiners have long said, “we’ll find you deficient if you do not have policy prohibiting the writing-down of passwords.”  However, with this manifesto, I propose that policy should establish objectives FOR, not against, documentation of passwords.

Policy should teach that passwords are part of a system called credentials, and policy should encourage the management of credentials and establish objectives for protecting credentials.

Management of Credentials:  the user should develop secret themes and methods to remember strong passwords.  No matter what we do about writing passwords down, memory tricks have to be a part of the equation.

Protection of Credentials:  The user should be taught best practices surrounding passwords, including do not share the password, don’t use your name or themes that would be easily guessed, don’t use the same password or theme for personal and business use, and , of course, do not write the password down (in a place where it can be discovered.)

But what would be different this time is to add to the policy that instead of writing-down passwords, you are required to properly store it using approved guidelines.

The guidelines should embrace new technologies for storing not only back-door administrator passwords, but personal passwords that heretofore have been prohibited from being: “written down.”

–          There are methods in use for the storage of passwords.  Some simply use a password protected (hopefully strong) excel spreadsheet named “advertising.xls.”

We have seen a few applications:

–          KeePass (all platforms)                                   –  The Riddler (free Android app)

–          S10 Password Vaul (Windows)                    –  Safe Password (free iPhone app)

–          Password Safe  (Apple, iPhone)                   –  1Password (Mac OS X)

–          Sxipper (all platforms)                                    –  RoboForm (Windows)

Many of our clients have shown me what they’re doing in audits, and I am letting them have a pass.  But don’t forget your risk management practices.  Be sure to follow normal due diligence controls as the above vendors are definitely Critical Vendors, because they may end up in possession of very confidential information, especially if they are cloud providers.  And conduct a risk assessment on the application once you get it.  Look at authentication, use, and data entry / output processes.  Analysis should flesh-out whether you or the vendor will hosts passwords, and be sure to establish how your information will be destroyed.

You should end up with a list of controls.  Be sure to teach your employees how to use these applications and especially the controls in your list.  But before you roll this out to your employees, walk through the use of the system yourself and develop “do’s and don’ts” for your users.  Then test the use of the application on a few passwords for a few people.  Maybe you start with your steering committee, using lower-risk passwords (and not your whole set).  Be sure to implement controls (including awareness training) prior to changing the policy.

—————————————————

I’m not sure if this will be published or not.  If it is, it’s because I did my own risk assessment on the notion of once again disagreeing with “best practice.”  And if you are reading this, it’s because I have decided that the rewards of affecting the evolution of “best practice” was greater than the risk I would cause issues with those of my clients who are finally getting people to stop writing their passwords down!

Dan Hadaway CRISC, CISA, CISM
Founder and President, Infotex

“Dan’s New Leaf” is a “fun blog to inspire thought in the area of IT Governance.”