Packet Guru

In my last post I provided a template business case that InfoSec people could use to justify increasing the minimum password length while also reducing the frequency of enforced password changes. The reasoning being that if users are not forced to regularly change their passwords then they will be more inclined to select complex passwords that are difficult for an attacker to guess or crack (but still easy for them to remember). This is a sound business case but, to really make the point, wouldn’t it be great to also provide empirical evidence that with the default password policy users are actually using weak passwords!? With some technical knowledge, password hashes can be dumped from a domain controller and subjected to a cracking attack. Chances are, that in domain with a default password policy, many users’ plaintext passwords will be revealed within a reasonable amount of time. Metrics can then be derived, such as the percentage of passwords that were successfully cracked

I love getting root. I also love looking for other people getting root. What I don’t love doing is telling how they can stop other people from getting that sweet sweet root. I know I’m not alone but unfortunately this is what gets many InfoSec folks paid. InfoSec folks have to explain to lay people how to make things more secure in a way that is easy to understand. For many this doesn’t come easily. Your root can be the sweetest root, but if you can’t explain to others why and how it needs to be fixed then you’ve arguably failed as an InfoSec professional.  I’ve recently been in this situation. I’ve needed to justify to senior leadership increasing the minimum password length for Active Directory domain from the default 8 characters to 14. This was a tough sell because users don’t like long passwords. They’re considered harder to remember and a pain to have to enter every time they want to log in. To make this seemingly bitter pill easier to swallow, I also recommended that the maxi