So I’m re-reading The Web Application Hacker’s Handbook, 2nd Edition again as it’s a classic, and I feel rusty. It’s a great read, and a must read for anyone who wants to get into web application testing. Yes, it’s a bit old and some of the chapters may not have aged well, but it’s still very much relevant today. However, that’s not the reason for this post. Nope, the reason for this post is to do some reflection on the whole password cycling thing.

Password Cycling

The term password cycling refers to the process of having users change their passwords every 90 days. It’s usually coupled with password requirements of a 4x3 rule, i.e.:

Pick a password of at least 8 characters that contains at least 3 out of the following 4 character types:

1. Upper-case characters.
2. Lower-case characters.
3. Numeric characters.
4. “Special” characters, such as punctuation, symbols, etc.

Yeah, that set of rules. We all love to hate this one, and there has been a movement recently to simply do away with all of this. In Special Publication SP 800-63-3, NIST has changed their recommendations regarding passwords in a few ways, including:

• Remove the arbitrary password complexity rules, like the 4x3 one described above.
• Remove the need to reset passwords on a regular basis.
• Require that new passwords be tested against passwords that were part of a breach.

I like it. But again, while I was reading WAHH, I couldn’t help but notice that there was an argument for rotating passwords regularly, mainly because it lowered the window in which a password could be used. This is the age old argument for resetting passwords, but we in the security field have argued against it for ages! The NIST document I link to above came out in 2017, and in 2019 Microsoft recommended dropping the password-expiry policies in their Security Baselines for Windows 10 v1903 and Windows Server v1903.

So what’s exactly the problem here? Everyone gets what we want, and we don’t have to worry about it, right? Well, let me ask you something. Do you check the passwords that your users use? Do you audit them? What about if your organization is responsible for creating an application where a user can create an account with a password? Do you check that? Do you monitor password breaches and pro-actively check your users passwords against the updated breach? Probably not. In fact, it may be impossible unless you’re storing passwords in a simple hash format that allows you to check that hash against something like haveibeenpwned.com. Of course if you’re storing passwords using bcrypt, then chances are you’re not going to be able to check those passwords even if you wanted to (and that’s how it should be).

So what point am I trying to make? I think the biggest one is that we shouldn’t take this shift in password requirements lightly, in that we now can focus on something else completely. Rather quite the opposite! While we can drop the need for password rotations for the general populace, it comes at the cost of adding additional checks, audits, reviews by security staff to ensure those passwords are solid and not using ones that were disclosed in a breach. Either through automated means, forcing long passwords, or improved awareness training on password selection (plus using a password manager), the fact is that there is arguably more work for security professionals because of this guidance. I worry that this is being lost on people since we have “won” the battle on password rotation.

This is just a short post, but it’s meant to make you think about your own password policies and what you’re doing to supplement them. Ideally you’re already doing all of these things, but if you’re not, maybe now would be a good idea to start looking into it.

– John