If rotating passwords is outdated, why are JIT password rotations a security standard?
Posted by JalapenoPopPoop@reddit | sysadmin | View on Reddit | 69 comments
I'm genuinely asking because a lot of the times I miss stuff or don't think it through correctly so trying to get other perspectives
But I'm kinda confused on this one. I've worked in environments where an admin will have to request their admin account password each day since it changes each night or db users will have to request new db credentials every day. But what actual security advantage does this provide?
It would be one thing if these JIT systems disabled the account or something when not being accessed, but the vast majority of the time it's nothing more than "your password rotates each day at midnight, to start work the next day you need your new password" and I don't understand the point. If we say it's perfectly fine for standard user accounts to use a password that never expires why does this not apply to other accounts? What security benefit is actually being provided each night?
To me this seems just as much of an illusion of security than forced password rotations. I guess I just don't really understand how one side of the mouth can say rotating passwords every 90 days doesn't keep you more secure while the other side of the mouth says we need to rotate every night to stay secure
DeadOnToilet@reddit
Rotating passwords is only outdated when combined with mfa/fido authentication, depending on the criticality and confidentiality of the system. It’s often misquoted and taken out of context.
JIT auth is superior for critical data use cases. Trust me when I say you don’t want your banking information protected by password only auth where passwords never rotate.
mnvoronin@reddit
This is incorrect. NIST 800-63b does not make this distinction.
The MFA/fido/etc is not mentioned anywhere in the requirement.
DeadOnToilet@reddit
See it’s people like you that cherry pick one standard from a suite of standards and in your beautifully Dunning-Kreuger way, ignore every other authentication related standard in the suite of NIST guidance.
The AALs defined in SP800-63 explicitly discuss MFA. You aren’t even comprehending the standard you’re citing. Your argument is only correct for AAL-1 (low risk systems). And EVEN THEN, have you implemented known compromised password filtering? Passphrases? Are you allowing all ASCII characters? Because if not, you’re cherry picking one line of a complex topic to suit your own moronic rhetorical goals of (checks notes) making your systems easy to compromise. Well played.
Read the entire suite of standards related to authentication and educate yourself, and if you’d like to listen in to some of the NIST and CIS workgroups that work on these standards, feel free to DM me.
mnvoronin@reddit
See it's "people like you" that vaguely wave their hands towards "entire suite of standards related to authentication" without being able to point to the specific ones.
I don't work on feelings, show me the document, preferably with quotations of the relevant part and then we can talk.
I use NIST guidance because I consider them to be one of the most trustworthy entities to issue one. It's like a federal law - you can have local laws/industry regulations, but they cannot override the requirements of the top one, only expand on it.
DeadOnToilet@reddit
I did. NIST SP800-63B-4 Section 2.2. It's clearly spelled out in my previous post. You CLEARLY lack reading comprehension skills. I'm VERY, VERY glad you aren't one of my subordinates.
theNAGY1@reddit
For Assurance level 1. Considering most businesses touch PII, PHI, payment, company sensitive, or client sensitive data that could cause significant harm the to business if lost or stolen, most should be implementing assurance level 2, possibly 3 which does require it. Even then though, many cyber insurance providers won’t care and demand rotations anyways.
mnvoronin@reddit
No, section 3 "Authenticator and Verifier Requirements" is not split by AAL, it defines normative requirements per authenticator/verifier type.
AALs further restrict which combinations are allowed. And password authenticator alone is not permitted for AAL2 and 3. There is no additional text that says something to the effect of "passwords must be rotated if not used in combination with MF verifier".
Ssakaa@reddit
Right... 2+ requires MFA. If you have a password as part of MFA, it's fine to not bother rotating it. I.E. if you're using that document as backing that you don't need to rotate your password, and you're selectively ignoring the MFA component of the combined guidance, you're basically saying "there's absolutely nothing valuable on the other side of this authentication". If you're good with that, great, otherwise, you need MFA, or you need compensating controls. Guess where rotation comes in?
mnvoronin@reddit
Show me the place in the document where it talks about password rotation as a "compensating control". Please.
You do not use only passwords for AAL2/3. End of discussion.
Note that "JIT password" is, by nature, a short-lived ("just-in-time") secret and technically falls under session secret verifier rather than password verifier.
Ssakaa@reddit
Right. So. This document doesn't apply in environments where they are just using single factor auth, particularly passwords, for things of any importance. Right? Great. Then this document isn't a factor in deciding what controls need to be in place. That also means it doesn't in any way have any bearing on recommending against rotation in those environments.
HeKis4@reddit
"Rest of the fucking owl" moment right there :p
mantawolf@reddit
Cyber insurance and legal requirements.
Rich-Parfait-6439@reddit
This is right. I worked at a $6BB bank, and cyber insurance was so expensive that it was a requirement that we do this, or else they would not insure us. We've never had any security incidents either, but it's simply because of the size and our exposure. It sucked because I had to log exactly why I needed to use that access and my supervisor always got notice that I requested this. He didn't care, but it's such a huge PITA.
Nakenochny@reddit
Banking regulation is such a PITA. And the auditing lol
CharcoalGreyWolf@reddit
Compliance is a good thing—
However, compliance requirements often trail best practice changes by a considerable bit. A d insurance is always a risk-averse business so cyber-insurers stay conservative and don’t change quickly; if anything, they become more onerous in requirements.
ISeeDeadPackets@reddit
I'm a bank CIO and yeah, stupid auditors suck. I vette the living crap out of the ones who have anything to do with IT, particularly on the technical controls side. If your plan is to run nessus and toss a report at me, please just go away. I want qualified people who can find stuff we can fix or at least have an informed discussion on whether or not it's acceptable.
CharcoalGreyWolf@reddit
I don't mind people who use Nessus and Qualys scans as part of their auditing. However, if they have no idea what to do with the data, and no idea what the remediation is for a solution or what they'd like to see in a second scan other than "that my scanner doesn't show it any more", then they're not worth a lot.
I think there's a true job niche out there for auditors that both know how to perform the audit, and then actually provide technical details on a fix through their real-world experience. That said, in this world I'd be concerned that some auditors might be combination arsonists/firefighters, so vetting is indeed important.
Also, I can't bear it when an auditor requires administrator access only to proudly point out a vulnerability that only exists if you have admin access (or additional privileges) to the system. I'd very much like to say "Get past 802.1x, then gain user account access yourself, if not already elevated, elevate yourself and then I'll see we have an issue". If you've already got access to a LAN port (or wireless access) inside the private network and you've got admin access, there are bigger problems than a single vulnerability. We don't just throw the doors wide open to bad actors, do we?
Nakenochny@reddit
Oh absolutely. But doing a Fed Exam, a third-party audit, and a state Exam every 12-18 months leads for some very packed years for me lol
My boss is always trying to push forward their expectations and requirements, we do a lot of context explaining too so we don’t get gotchas. But we still can’t have passwordless, because regulation says so—must have 14 characters for users and 16+ for admin, changed every 90 days like clockwork. Insurance/regulation is unironically the thing that keeps us less secure.
CharcoalGreyWolf@reddit
Trust me, as someone who has a bit of experience where you are, I feel your pain.
Rich-Parfait-6439@reddit
Me too. 20 years of doing IT in banks I've gotten use to the rectal exams every 18 months :)
Rich-Parfait-6439@reddit
Yup... 20 years and counting doing IT in banks...
JalapenoPopPoop@reddit (OP)
This seems like the main answer, similar to why rotated passwords stayed for so long
Mindestiny@reddit
Rotating passwords is only "outdated" if you look at the logic behind why NIST changed their tune about it.
Rotating passwords is objectively more secure on a technical level. You don't wait for it to be compromised and react, you rotate it and now any potential leaked credentials are invalid before anyone tries to use them. Inarguably better on paper.
The reversal is because of end user behavior. Joe Blow in Accounting making his password Spring2026! and writing it on a sticky note because it changes every 90 days exacerbates the human elements of laziness, hubris, and ignorance and undermines the increased security of rotation to land on a net loss in security posture.
If passwords are rotated with secure examples and with disciple, it's absolutely a net positive instead. Hence any system that can automate password rotation for non-end user use is still recommended (service accounts, temporary elevation, etc) as well as regularly rotating API keys.
M-G@reddit
The other reason for the reversal is MFA. When the only protection was a password, it was definitely useful to require periodic changes. But now that MFA is universal, it's not much of a threat.
DeadOnToilet@reddit
Passwords suck. The guidance should be “don’t use passwords, use something else”.
CrappleAMIRITE@reddit
My counter to that- in our org we've been going pretty heavy in the passwordless direction. That works fine, until you hit an app that either doesn't allow or doesn't support biometric/other forms of Auth.
All of a sudden the user has to remember a password that they've long since forgotten.
thortgot@reddit
If you have apps that don't support SAML, advocate for migrating to something remotely modern.
Mindestiny@reddit
Which is all well and good on paper, but SaaS companies simply don't give a shit, and "but muh passwordless" is pretty much never going to be a stronger business case to use something else than whatever these high profile business apps are that don't support SAML (or support it poorly).
It's an uphill battle that we'll likely fight until we're all well beyond retirement.
thortgot@reddit
I disqualify companies for lacking SSO support fairly rarely now. Nearly everything I would recommend in the first place supports it.
There are onprem scenarios that you can add wrappers for but those are generally for admin use cases or a small user subset.
Mindestiny@reddit
I don't disagree, but I'm also not the be-all-end-all SME on business tool selection. I can perform security review and make recommendations, but when senior leadership goes "We're buying this, deal with it" there's not a whole lot I can do but remind them I raised the concerns from the review.
I'd imagine a lot of businesses are in the same boat - some things the business just says we want this and it is what it is.
thortgot@reddit
Part of it has to with IT maturity and governance, part of it has to do with how you communicate risk.
SSO is a 100% hard requirement for anything new in my book because you want to have a central audit record of credential activity.
So I write up a policy that aligns with that objective, advocate for why and get it approved. To be fair I'm part of senior leadership so I when someone says we want to implement "XYZ", I can say that it doesn't meet our security policy that would allow it to house secure data. If the use case is something that doesn't house secure data (ex. Canva if it didn't support SSO) then a entry in the risk matrix can be generated with the sponsor's name next to it.
YetAnotherSysadmin58@reddit
Authenticate passwordlessly to a password manager that remembers that for them
DarthShiv@reddit
Biometrics are worse. Use something else except those.
DeadOnToilet@reddit
Wholeheartedly agree.
Mailstorm@reddit
There is one thing you are missing...how did the account originally get compromised? If an account got compromised and you don't know how it was compromised its going to happen again. In this case rotating the password is just a speed bump.
Mindestiny@reddit
That's not really relevant to either scenario though. If there's still an ongoing compromise, "don't rotate until there's evidence of a compromise" just means that it's going to get re-compromised whether it auto-rotated or if you manually rotated it. You still have to remedy the attack vector in either scenario.
autogyrophilia@reddit
Furthermore, most passwords are used to derive time sensitive tokens, tickets, keys or whatever and get automatically rotated.
If the system is built properly that is.
thortgot@reddit
Password rotations alongside ending sessions ensures you don't have "stale" sessions that is functionally bypassing the JIT component. It's an auditing measure.
Likely_a_bot@reddit
The main reason is that JIT is mainly for privileged access which usually has a higher cyber security risk.
Centimane@reddit
Sounds like a bad JIT solution. It's not Just In Time if you do it in the morning. JIT access should be available far shorter.
TheCyberThor@reddit
Passwords are inherently weak on its own. Rotating it means it’s only valid for 24 hours if compromised.
Higher risk profile if it’s shared accounts or systems only support single factor authentication.
Secret_Account07@reddit
My account has a complex password that changes every 8 hours.
Guess who’s SecOps team disabled copy/paste in VMware console due to security concerns?
So naturally everyone copies and pastes in notepad. I stg security folks have no idea what folks do in the real world.
BoltActionRifleman@reddit
Wait, I’ve been under the assumption pasting into VMWare console is just broken with no hope for a fix.
HeKis4@reddit
Personally I use keepass to type the password instead of pasting it. You just need to make sure all your shit is in the same language and keyboard layout (usually en-us + qwerty).
modder9@reddit
There are 2-3 entries you need to add in the VM’s advanced settings iirc
BlackV@reddit
has to be enabled at the vm settings and the vmware settings first right ?
but also RDP exists for the sole reason of copy/paste from VMs :)
Secret_Account07@reddit
So I’m struggling to remember what we used for paste years back. I think you had to use the VMware console vs html/web, but we did have it working. Perhaps it require a plugin? Can’t remember lol
But anyways security nixed that. It really sucks for LAPS and PAM passwords.
TheCyberThor@reddit
Is this your own individual account? Does it have MFA? If yes, then rotating password is just security theatre with no benefit.
Disabling copy/paste suck. It’s a half baked control to “accommodate” lack of privileged workstations.
Secret_Account07@reddit
Yep, MFA. All accounts are actually.
Vaulted too
Now I’m referring to our admin account, our standard “employee” account is 90 days. But we use our admin account for most work.
But it just creates issues. So unnecessary to change every 8 hours. Think it’s 18 long (complex).
TheCyberThor@reddit
In that case I don’t think the rotating of password adds any value other than sysadmin friction. Since the password alone doesn’t guarantee access.
Maybe there is an external compliance requirement. If there isn’t, then it might be something you challenge on whether this control is “legacy” and should be deprecated.
-Alevan-@reddit
JIT tokens are temporary, hence the name Just-In-Time tokens.
lethargy86@reddit
Interesting, all JIT systems I've seen either keep the account disabled when not in-use, or create a fresh profile for your ID, each session.
Chowdog03@reddit
Dwell time is a consideration not to be forgotten. When the credentials are phished and token pilfered, how long is your exposure? See risk tolerance for guidance.
Independent-Sir3234@reddit
The difference is whether you're rotating a standing secret or minting a short-lived one. We had a legacy admin account that technically rotated daily, but the password still got pasted into ticket notes and forgotten on jump boxes, so it wasn't buying us much. Our JIT setup worked better because the credential only existed for the 20 minutes someone needed it, and the request itself left an audit trail.
sivanandu_itops@reddit
JIT helps reduce long-term exposure of credentials. Even if passwords are strong, rotating them dynamically reduces risk in case of compromise. It’s more about minimizing attack window rather than replacing passwords completely.
I_NEED_YOUR_MONEY@reddit
i'm guessing the common feature here is that these are not user-scoped passwords?
short-lived credentials are an alternative to a user system, so you can check that the person you're giving those credentials to is still allowed to have them each day. if you can revoke a user's access another way, that's usually better than short-lived credentials but sometimes you really actually need to sign into the root account somewhere, and they can't just delete the root account when you leave. so the alternative is to give you a password that can't be used tomorrow.
desxentrising@reddit
really don’t think that insurance requirements reflect the real world. went magic link and MFA only w my app and I’m left wondering why I even would want a DB of creds. one less liability.. maybe I’m missing something ? seems counter intuitive when pw recovery relies on email/mfa anyway
SevaraB@reddit
The problem isn’t the rotation, it’s that people make crappy passwords, and the more of them they make, the crappier they get.
Randomized passwords rotated as part of a JIT request don’t share that weakness.
Master-IT-All@reddit
Those are different things, similar but not intended for the same audience.
End user protection is either rotate passwords frequently or strong password and MFA. Rotating when you have MFA doesn't make sense.
JIT Admin passwords, that's Privileged Access Management.
I would assume that for those, the process is the admin connects with their lower security MFA protected account, requests the admin access and is given a username/password that will work for a short period of time.
billy_teats@reddit
NIST changed its recommendation to rotate passwords for standard user accounts where a human is picking the password. It makes sense on paper to change it often but in practice users just pick really bad passwords, like the season and year, Summer26! Then Autumn26! So the prevailing advice is to use passphrases, less special characters and more total characters, so you don’t need a ^ in your password if your password is 14 characters long.
Admin account passwords should not be manually input or chosen. The system sets a (pseudo) random password that can easily be 24 characters long. The user flow should involve using the secret management system to get the password every time it’s needed, so changing it every day should have no impact on the workflow. You can change the password 5 times a day and the user experience should be no different.
Changing the password often also has the benefit of ending existing sessions. If you change the password most systems will invalidate any existing session. So if the password does get compromised during use, the exposure time is greatly reduced. Unless the secret management system is compromised, but there should be layers of controls around that -SSO, strong MFA, session timeouts, managed devices, approved IP ranges, user behavior monitoring, etc. so if a user has only ever accessed the system from a managed device in Iowa and does so in the morning, then “the user” attempts to access the system from Florida from an unmanaged device, then attempts to access a dozen different secrets, they should be blocked and alarms should be going off.
Sasataf12@reddit
Rotating user passwords is outdated. And that's only because of the human.
Remove the human out of the process, and rotating passwords is more secure than having a long life password.
Tessian@reddit
Everyone's forgetting the reason we don't rotate passwords is because users pick predictable passwords. JIT / PAM solutions doing daily rotations are picking completely random passwords each time. It's to limit exposure and to ensure that you have a decent time boundary of when a user knew the credentials to admin account X.
Capt91@reddit
800-63B is more complex than just don't rotate passwords and it even further bans complexity in passwords. It only requires 8 character passwords w/MFA or 15 character passwords w/SFA. It suggests allowing up to 64 character passwords. Because security is actually weaker without these in place.
It also requires, let's just say for Authenticator Assurance Level 2, High Confidence MFA, blacklisting checks, no recovery hints, no KBA recovery, and paste support from password managers. SMS/PSTN MFA is almost completely banned and the MFA must be phishing resistant. Biometrics are not enough to be High confidence, it can only be an activation factor. There needs to be a hardware bound key involved. Along with basic salting/hashing, throttling and session management then you are actually following the "no password rotation" guidelines.
bonksnp@reddit
If you're accessing systems on a daily basis, is JIT the right way to provide the access? In my experience, if you need elevated privileges on a daily basis, it makes more sense to have a strong password with MFA vs JIT with rotating credentials.
JalapenoPopPoop@reddit (OP)
That's what I'm trying to say! Daily access with a daily rotating password just doesn't seem like the best solution for anyone involved. If they're daily accessed why not treat them like day to day accounts and lock them down the same way? Rotating daily feels like something someone implemented cause it feels secure. If strong pw requirements and 2fa work for other accounts it works for db/admin accounts. It either works or it doesn't.
penguinjunkie@reddit
What other security measures are in place or can be in place? This matters too.
progenyofeniac@reddit
I think there are multiple pieces to it, with limited but still significant value.
Rotating privileged accounts keeps you from sharing creds, hard-coding creds into a script, and makes it somewhat easier to lock you out upon termination (lock your main account and you can’t get to the vault anymore). Also ensures that random complex passwords are used.
Vaulting them in that way also puts all privileged accounts in a system where they can be monitored in the first place, sort of a system of record. And as far as rotating them, I don’t really mind a bit of additional security on privileged accounts even if it’s minimal.
But I’ll agree that daily seems excessive. Rotating every first of the month could make more sense or something, I don’t know.
ExceptionEX@reddit
Well everything is opportunity, situation, and compromise. If you have a method to insure complex diverse passwords, then rotation isn't needed. If you have a legacy system whose password requirements are fixed and simple, rotation is a good layer to add some protection. And if the system is seen as mission critical, then having as many layers as possible is also good, so rotation of complex passwords can be employed if you have a method to insure the users can get access from a secondary secure source.
Binary thinking of if this is good for one it should be good for all, is a dangerous and basic way of thinking, and should be actively worked against.
ElectroSpore@reddit
User credentials and Admin credentials are completely different levels of exposure should they be compromised.
If the receptionists credentials leak then a number of calendars and emails she had access to get exposed. If the guy in marketing gest leaked his client lists and maybe some new product launches.
If the sysadmins admin credentials get leaked then potentially ALL systems get exposed either directly or indirectly through additional attacks.
If a DB gets exposes possibly all clients and all financial info gets exposed.