Karen N. Johnson‘s most recent post discusses types of passwords and their strengths. That triggered some memories.

Before being sold to HP, I worked for Baltimore Technologies (world’s largest certificate authority vendor outside of the US during the crypto export restrictions years). During the official training they taught a trick for doing ‘secure’ passwords (ones that require letters, numbers and a symbol) such as in CA’s. It was word, then number, then symbol above the number, so password3# for example. It would be interesting, if not scary to know how many CA’s have their private keys protected by a ‘secure’ password like that. Especially in light of the second story.

About 10 -12 years ago when Cisco was first rolling out their security products I attended a salesinar with one of their penetration team leads. He had at his disposal a rack of machines used for brute forcing networks that had only been thwarted by passwords for 3 or 4 minutes at the most. When going against a Cisco device there was logic in the rack to try ‘frisco’ as the first password since that was used as the example in the manuals — and it worked > 50% of the time; even on border machines.

I think where I am going with this is not only do you have to look at the password algorithms when testing, but the human element as well. Does a manual give a password example? Is there one on the screen? You might be inadvertently causing users to use a insecure password.

And of course there is how passwords are stored in the database. And if there is an internal password, where and how is it stored?