I remember working at a large organization with a team of other IT Operations staffers. We rotated this one job every month amongst a few people, each taking turns, where we’d lose a day to update all the privileged passwords for our servers. This was before Managed Service Accounts and the cloud, when we were required to change these every 30 days and then store the new ones in an encrypted store.
What struck me when I got stuck with this wasn’t the requirement to change every 30 days; that seemed normal. The thing that bothered me was how manual this was. As a former developer, I wrote some scripts to automated this, pre-PowerShell, and make the task easier on my fellow sys admins. I had scripts to generate a password, change it in AD, then print the pwd to be copied into our secure storage (no API there). This ran in a loop so I didn’t lose a whole day to changing password.
These days, we have lots of alternatives to managing passwords, and in fact, much of modern guidance isn’t to require password changes so often. For systems, use an automated process such as an MSA or GMSA. For users, we’ve mostly given up on changes and are trying to get people to use decently long passwords and disparate ones across services.
Modern guidance from Microsoft says to avoid using common passwords (asdfasdf, password1, ec.) and don’t use the same password in multiple places. MFA is also recommended, but the anti-patterns for success are requiring long, complex passwords or frequent changes. Studies show these lead to less security because users do stupid things.
These days, I would guess many of you managing database systems use some sort of integrated security with AD, Entra, OAuth, etc. However, I know there are still places where passwords are in use. Do you require changes often? Do you change any of your passwords regularly?
Security is always hard, and it’s even harder when the recommendations and rules aren’t consistent or even enforced. I don’t know what to do, but I try to use disparate, long passwords and MFA wherever I can. So far that’s worked well.
Steve Jones
Listen to the podcast at Libsyn, Spotify, or iTunes.
Note, podcasts are only available for a limited time online.
Voice of the DBA 
Password security is hard to balance. One one hand you have the It/Admins who want strong security and with good reason and on the other hand you have the multitudes of users who just want to get logged in and do their job with as little hassle as possible. By forcing users to use longer, more complex passwords that must be changed often and must either always be a new password or one not used in a log time you can end up making things less secure as some percentage of the users will now start writing these PWD’s down somewhere b/c they can’t remember them all. There will always be some % who write them down no matter how hard or simple PWD security is but you will increase that % the harder your PWD requirements are.
The only real fix is one not being implemented and that is to teach people from a very young age the importance of privacy and security but doing that runs counter to the desired goal of getting as many people as possible to download/install as many apps as possible. It’s hard to argue for privacy/security and then say but when it comes to 3rd party apps on your phone you can ignore all that privacy and security stuff we taught you. The It/Admins want strong security but only for the users it’s responsible for and not everyone. If it is a company like one of the food delivery services they don’t want users thinking twice about security/safety with downloading and installing an app.
If you want robust security you have to find a balance between needs of the systems security and what users are willing to agree to do. I’ve switched to using a pwd convention where I have a base value that changes based on source (what service or platform the PWD is for) and date so that all are unique and yet similar. Ity’s not fool proof but at least I don’t have to write my PWD’s down somewhere.
LikeLike
It’s always a balance, and the culture of the world (and corporations) doesn’t lend itself to doing better. I wish that people cared more to use the services that provided better security, but ultimately the bigger problem is that once people get invested in a service, it’s hard to change. And when it’s hard, often the vendor has less reason to care about security.
I’m torn on the base pwd+change, usually because this creates a pattern, and if ticketmaster loses your info, then someone can write a script to take that pwd and try it on BoA, Wells, Chase, other bank with the pattern. At scale.
Ultimately this stuff sucks and I think I like my local password manager, with a strong pwd for the vault and random ones everywhere else.
It’s a pain, but I’ve actually come to appreciate a few places (like Slack) that just email a magic link (or text it) and don’t have user/pwd.
LikeLike
Sadly with this I don’t believe there is an ideal solution or answer but more of a you do the best you can with what you have. There’s no security system that is %100 guaranteed to keep your home from being robbed and we’ve lived with that for a long time. What is key and you mentioned this is to not use the same PWD everywhere b/c if a site gets hacked and that pwd cracked you then have to change it everywhere you’re using it. Personally I believe a combo of pwd + physical key (i.e. USB fob) is the way to go for that which really needs to be tightly secured.
LikeLike