this post was submitted on 19 Aug 2026
196 points (99.5% liked)
Cybersecurity
10657 readers
144 users here now
c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.
THE RULES
Instance Rules
- Be respectful. Everyone should feel welcome here.
- No bigotry - including racism, sexism, ableism, homophobia, transphobia, or xenophobia.
- No Ads / Spamming.
- No pornography.
Community Rules
- Idk, keep it semi-professional?
- Nothing illegal. We're all ethical here.
- Rules will be added/redefined as necessary.
If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.
Learn about hacking
Other security-related communities !databreaches@lemmy.zip !netsec@lemmy.world !securitynews@infosec.pub !cybersecurity@infosec.pub !pulse_of_truth@infosec.pub
Notable mention to !cybersecuritymemes@lemmy.world
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I was so happy when we finally hired a director of security and the first thing he did was stop forcing us to rotate passwords every month.
It was so fucking insane.
MONTH??
That was the recommendation for years.
It was commonly 90 days for regular user accounts, and 30 days for admin/privileged accounts.
with automated password rotation, and no api access (no permission to use api access, that is) to the keyvault. And they expected us to automate stuff too!
ThisPasswordisforJANUARY1stMonth!
Our organization got hacked and there was about a year after where CISO had us changing passwords every two weeks.
It's monthly at my company. Combined with other complexity requirements, it's pushed everyone into such predictable patterns that I could probably guess my way into any manager's PC in probably a few minutes.
Also, there's no lockdown after X attempts. I can try infinitely, as far as I'm aware.
Eh, AFAIK that's not a best practice anyway, at least not any low number. From what I recall, the recommendation is to either have a high number of attempts that causes a lockout (50+?) or high-priority alerts when a large number of invalid attempts is detected. One of the problems with lockouts based on X attempts, especially low numbers like you often see, at least in my mind, is that it opens people up to a denial of service attack. Let's say that all account names are predictable, like first initial and last name. A rogue user could lock out anyone they wanted to with that knowledge. What if they know or can easily predict the usernames for all admins or IT people in the organization and they lock them all out?
Typically you want to do the lockout for a location, not the user, or you step up the auth level. 3 bad logins -> please mfa before trying again.
But yeah, letting an attacker do that at will is bad. I'm a fan of token bucket rate limiting with exponential back off. You get 10 attempts. A new attempt is added every second. An attempt while the bucket is empty makes that become two, then four and so on.
Most people never notice because a buffer of ten and a new attempt every second just never runs out. If you accidentally hold down enter you're only blocked for a few moments. A dumb attacker quickly locks themselves out forever.
Good points, thanks. I wasn't familiar with token bucket rate limiting.
I had companies where it was monthly. suxed
Even NIST stopped recommending pw rotations.
To their credit, none of the businesses I have a pw for require changes anymore. Also, to their credit, I can use long pw's now. Some used to restrict to 8 chars max (!?) But against their credit, many still restrict the pw content, like you can't use non-letter symbols or w/e.
Very old operating systems used to have a method for password hashing built in that could only handle 8 characters max. The need for compatibility with it, or things that were too zealous in being compatible lingered for a very long time.
It's not good, but some services end up behind firewalls that reject inputs that look like SQL injection. Sometimes they decide it's better to prevent sql-ish passwords than risk some weird fluke.
Sometimes they just say |, I, and l all look too similar and our users are idiots. Which is awful practice.
My personal feeling is that password length should be capped with the length of input the system can handle. Plaintext copy of Alice in wonderland from project guttenberg? Go for it.
Don't most of those systems turn the user pw into a salted hash? I suppose that would limit the effective pw length, given random pw's. Like if the hash was 128 bits or w/e, lots of 256 bit pw's would hash to the same value.
But IDK how big those hashes are. Maybe they're huge?
You would be correct. However, they would truncate the password to eight characters, and 7 bits per character. This allowed the password to fit inside a 56 bit block for a des based hashing scheme.
This is an old scheme, but it was very compatible so it lingered on and on.