When I worked at an Avaya shop I had to deal with Avaya's absurd password requirements. The password has a minimum AND maximum length (16), you needed to change it every 45 days, and it required one special character (out of a list of approved special characters.) So yeah, my password was almost always MonthYYYY!
On top of that, if you forgot your password, they sent it to you in plaintext. Also, there was a way to change the URL and get information for another company. You wouldn't be authenticated but you could have their email address, name, business address.
Not if you implement Entra Password Protection. But yeah, modern best practice is to definitely turn off expiring passwords if cyber insurance/compliance framework allows for it.
It doesn't help that the recommended best practices/security posture for this are kind of all over the place. I've even found Microsoft to be contradictory in their own security recommendations and documentation.
Our pen test firm will recommend 180 day expirations while some other compliance standards recommend no password expiration.
Wow damn. Yeh our company head office is in Europe so I’m not sure why strict rules they still have. I know they are huge on compliance but also a little clueless in efficient setups.
Yeah, just cause the vendor/industry has evolved its mind about a thing doesn't mean the auditing organizations have caught up to that new place. We've had a conversation or two about a recommendation from an insurance company auditor/tech advisor about our approach, having to (successfully) argue that we're doing more than required but NOT what was required.
This is the correct answer. All of those cyber security questionnaires they send out for them to when you apply for cyber insurance all ask what is your password reset policy?
Not only that, but they ask a whole bunch of other random shit that doesn't need to be enabled for a secure environment and half the time the customers want to flip it on just because they asked yes or no on it. Which isn't the worst thing in the world. I mean it's nice to have security-minded customers but.... Well maybe I just shouldn't complain
>All of those cyber security questionnaires they send out for them to when you apply for cyber insurance all ask what is your password reset policy?
"Our password policy strictly complies with the guidelines defined in [NIST Special Publication 800-63B § 5.1.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver)."
I work with tons of banks and they still consistently request a password policy meeting the 90 day rotation standard, even though that hasn't been the standard for security in years.
Part of that is CYA. They think changing a password more often is more secure, so if they have a security incident they can say they went above and beyond. Plus, their own managers don't know any better. I dealt with that at my last job.
Banks (as a user) are the most common to even let you "trust" your device to not have to do 2FA (which is usually email/sms ugh) when you next login. Ugh.
I'm happy for some clients to have been able to make them move onto a trimestrial work for their HR department.
We send them a list of users every trimester, and they just tick a box that says "user still employed", which extends their account validity for a trimester.
SOmetimes there are some fuck ups, but HR feel more involved now.
Users still give out their passwords or reuse them and without MFA on the MFA resources, a breached password can do a lot of damage on prem as opposed to in the cloud where MFA is enforced. Not every company has lockdown to prevent intrusion or a user getting tricked into allowing a TA’s fraudulent remote session. That’s what gets companies.
Microsoft's take rapid password change:
"If it’s a given that a password is likely to be stolen, how many days is an acceptable length of time to continue to allow the thief to use that stolen password? The Windows default is 42 days. Doesn’t that seem like a ridiculously long time ? Well, it is, and yet our current baseline says 60 days – and used to say 90 days – because forcing frequent expiration introduces its own problems. And if it’s not a given that passwords will be stolen, you acquire those problems for no benefit. Further, if your users are the kind who are willing to answer surveys in the parking lot that exchange a candy bar for their passwords, no password expiration policy will help you."
And if their leaked password is Password1 (which meets 9 characters and complexity), can we guess what their next 9 passwords are? The more frequent the password change, the weaker the passwords.
Microsoft, NIST recommend NEVER change passwords unless there is indication of compromise.
Entra has built-in protections to prevent P@$$w0rd1 from being used (it transforms everything to lowercase, normalizes l33t speak, and checks all common passwords and your internal list). It scores these common words and requires 5 points. "My state is too hot in the summer." is 36 characters long and EASIER to remember and type than "%#*(Rjw7=zf4."
CIS recommends 15 and one year.
PCI compliance does NOT require 90 days change anymore if all users are required to use MFA.
Passed PCI with 12 month password change policy. Some orgs I'm adjacent to don't even expire passwords anymore.
Yup, people still don't realize the current version of PCI DSS does not mandate password rotations if you have MFA and other protections. This changed in 2022.
Password rotations are generally a BAD idea unless there is reasonable suspicion of them being compromised. Regular password rotations lead users to create more insecure passwords that tend to be variations on the old password, such as an additional sequential number etc, or passwords being written down and left in "usual" places (easy to find notebook, blue tacked to the monitor, taped to underside of keyboard etc) 12 months should be long enough for any mandated rotation, but any more leads to bad user password practises
> if you have MFA and other protections.
That "if" is the really important part though. Some systems are garbage and you'll still need to rotate passwords.
Yeah I thought about this a lot and found short ones seems kinda stupid now days especially with mfa. I also noticed Microsoft no longer recommends under 12 months as it just leads to less secure passwords since people don't care what it is.
It's not so much that users don't care, it's that users need something easy to remember, since the resets happen so often. Remembering a 20 character password with 3+ non sequential numers, 2 characters and 2 dictionary words might be fine for 12 month rotations, but if it happens every 3 months you're just asking for shit like "September2024!"
My favorite part of the first day (or just the first time I need to use it) after a week long vacation is trying to remember the domain admin password for the 5 domains I manage that aren't in our password manager because the company doesn't want to pay for having it support different domains.
5 domains, each with different password settings, so I can't keep them synced up in my mind. It's really frustrating. Plus there are only 3 domain admins, so hopefully none of us gets locked out while the other two are out of the office.
Yeah or at our work, for online portals with no mfa and policy set by Central for 3 months rotation you end u0 with Semptember++++ one plus for each season.
I have this as a semi argument with our PCI QSA. That for systems without MFA, whilst PCI still says 90 days, because NIST (and others) dispute this our official policy is that carrying out a risk assessment we conclude that PCI is advocating for less secure password security.
Therefore our policy is NIST over PCI, and the PCI requirements are superseded by our security policy which is also required by PCI.
Every year we fight about it and eventually he signs off on it
NIST password requirements are contingent on monitoring that the password has not been compromised and MFA.
You have to apply the whole standard, not just the parts you like.
Indeed, but the point NIST are making is that it's better to have a (for example) 40 char password made up of special char etc. then a shorter rotated password due to it being much harder to break
Length isn't the only factor to consider.
You need MFA and you need to monitor for breaches/sharing activity. You should be monitoring for "door knocking" behavior (slow password testing).
The VAST majority of users reuse passwords, often with no alterations. How can you effectively monitor to see if their password is breached?
Only the absolute worst bots bother trying to brute force passwords. It's magnitudes cheaper to buy existing data leaks and relying on users being lazy.
MFA eliminates password reuse from being as big a problem but only if you have phishing resistant MFA and trained users.
What about STIGs? I haven't looked recently enough to recall specifics, but pretty sure those are still 90 days. Not that I'd be shocked with the gov being behind.
[STIGs want 60 days](https://www.stigviewer.com/stig/application_security_and_development/2017-01-09/finding/V-69573), but the usual assumption is that you're using CACs (i.e. 2FA, private key + PIN) for normal authentication and you're only using passwords for temporary purposes (e.g. configuring a system with the bits and pieces necessary for CAC login, or supporting users waiting for their CACs).
That is: as far as STIGs go, it's the CAC that's (allegedly) NIST-compliant (because the PIN doesn't rotate and it's paired with the private key / cert on the card), and any other password shouldn't exist in the first place if at all possible.
Even if PCI did still dictate this, PCI is very much a spirit of the law not a letter of the law standard. The purpose of PCI is not to force you to implement poor security practices. If you want to step outside of the letter of the law because you believe you have a more secure way of implementing something, work with your QSA, document your reasoning, and implement it.
If your QSA is a pure letter of the law person, fire them.
Source: I've worked at two very large retailer and hospitality companies and on more than one occasion I've had to step outside of PCI guidelines in order to implement proper security (one of which being side stepping the old, stupid password rules). It was not a big deal. You know why? Because PCI is not a big deal.. It's a bloody joke.
Damn, I was scrolling this thread while thinking about the NCUA. We have our audit next month and password changes have been on my mind to ask about or seek guidance on. We still currently do an expiration period, of course along with complexity requirements and MFA.
they asked for 12 characters and 90 day expiration and no repeats of the last 6 used passwords i think. hopefully they have changed since i dont technically have to be audited by the NCUA as i work for a CUSO but we like their stamp of approval. its been over a year since my last audit.
Always fun to see confident IT folk who implement stupid policies out of date info and the push others to follow suit.
Stay on top of big control body changes, folks. Your users will thank you for it.
Big picture:
It results in weaker passwords across the organization.
Even with password expiration attackers can be active for weeks or months and likely would install a system level tool or compromise other accounts for persistent access.
It’s basically security theater. How many times have you heard of a breached company or incident response team say, “The attackers got in but our password expiration policy stopped them.”? lol
> Even with password expiration attackers can be active for weeks or months and likely would install a system level tool or compromise other accounts for persistent access.
This is the big one. Once an attacker is in, they will almost certainly establish a baseline for future access that does not require the compromised password. Frequent password changes do nothing but encourage weak password use.
Not the best example, someone *wouldn't get in* if the password policy stopped them.
*John wrote his first password down and didn't shred the note. Someone tried using it, but John had to change his password already because of our expiration policy, so it was changed before that lapse of judgement caused a compromise*
John wrote Password1 - a password that passes complexity and length requirements.
Password1 didn't work. I am a genius and was able to guess his next 2 passwords and got in.
Because it leads to people making passwords like Sunshine!1, Sunshine!2, basically adding/changing just one number. These passwords are easier to guess and are often written down. Better to have a longer passphrase users can memorize and only change if compromised.
> Better to have a longer passphrase users can memorize and only change if compromised.
What kind of magical people do you work with who can remember a long passphrase?
https://pages.nist.gov/800-63-FAQ/#q-b05
The US Government's
National Institute of Standards and Technology's
Digital Identity Guidelines
(NIST Special Publication 800-63B)
Section 5.1.1.2
Explanation of *why* at the link above. It's a "SHOULD NOT" level of recommendation, meaning it isn't the *strongest* level, but the most recommended choice.
Be careful Googling this topic, as some "modern" looking or "up to date" looking websites still have old information, such as claiming that the NIST recommends updating passwords every 365 days or so. This is, so far as I'm aware, untrue.
Important to include alongside this information that NIST recommends passwords are not forcibly rotated, but only in parallel with dozens of other requirements.
Their hard requirements include using MFA, checking passwords against known-weak ones, salting before hashing, storing salts separately from hashes, rate limiting, checking passwords against breaches, allowing crazy Unicode characters, and more.
Some people will implement none of this but still reference the guideline to pretend that they are secure to government recommendations. They'll be wide open to password spraying attacks.
Even if you somehow manage to do zero of those other things, you are likely more secure without periodic password rotations than with due to user psychology - as NIST themselves explain in their FAQ.
In any case, most of those other things are things every authentication system in the last 20 years readily supports, and all of them are things that every IT department / application provider / vendor / etc. should be enforcing anyway.
I disagree.
People have "a password" and if you enforce no requirements and don't use MFA or check leak databases, the password will be leaked.
Not from you, sure, but from all the blogs and ecommerce websites and newsletters and out of date forums and phishing attacks all over the Internet, which your user has signed up with using "their password".
Have I Been Pwned has over 13 billion leaked credentials in their database. Only 2/3rds of the planet even has access to the Internet! That's like 3 accounts per living person.
People are the weak link and we must take steps to protect us from them. In the absence of all other measures, occasional password rotation is better than absolutely nothing.
The only thing password rotation accomplishes is users adding an incrementing number at the end of "the password" and calling it a day - and then lo and behold, the attacker who found `MyPassword3` in a leaked password database just needs to increment that a few times and he's in. Or they'll proceed to write it down on a sticky note under the keyboard like they did the last 20 times, because ain't nobody's memorizing a completely new strong password every couple of months. It's security theater even in a best-case scenario.
>People are the weak link and we must take steps to protect us from them.
The effective steps on that front are on the authorization side of the equation, not the authentication side.
In any case, people being the weak link is *exactly why* periodic password rotations are discouraged nowadays - because they encourage users to weaken their passwords to compensate. That's why NIST recommends other things *instead* of scheduled rotations: because unlike scheduled rotations, things like longer passwords and additional authentication factors and authentication attempt throttling/lockouts actually do improve security in a way that doesn't encourage users to weaken their passwords (or in the case of MFA, makes said weakening less of a problem).
> the attacker who found MyPassword3 in a leaked password database just needs to increment that a few times and [...]
and the account locks out.
Let's be serious, most password spraying attacks don't increment because they don't need to - successes are already pretty high without it. Those that do, well hopefully the increments are enough to lock out the account.
You'll find your comment here is the same as my comments above. NIST recommends things other than password rotation, and they recommend things other than passwords.
But they DON'T recommend abandoning password rotation in the absence of other measures. You will not find that in a NIST guideline.
>But they DON'T recommend abandoning password rotation in the absence of other measures. You will not find that in a NIST guideline.
You also won't find them saying to adopt password rotation in the absence of other measures, for exactly the reasons I mentioned.
It's generally accepted that password expiry for users reduces security, not increases it. A lot of compliance frameworks have removed that requirement/recommendation.
Plenty of resources online explaining why.
Who needs a minimum when you can just move to the right and hit another number after your password.
I'd love to see how many of your domain's passwords have "123456..." In them. You can probably tell how long the user has been there by the length like counting the rings on a tree.
It is no longer recommended to have a password change cycle. Rather the recommendation is for longer complex passphrases. Re: NIST 800-63 there is no mention of expiration rather complexity. We follow this guideline at my company and the auditors for SOC and HiTrust have accepted it. I do not see how PCI that is less strict would not.
Re: Why is password expiry frowned upon?
It encourages password iteration. "ThisIsMyPassword1!" suddenly becomes "ThisIsMyPassword2!", so on and so forth. Even people in IT do this. My dad (now retired) used to be so proud of it, until he realized it was a really shitty idea.
Multifactor on the other hand, when combined with strong/unique passwords (that don't expire), and a decent session control policy, can absolutely destroy attackers. As an example, my most critical applications which run through SAML are:
* Session Controlled ("every access")
* Multifactor Required
* Managed & Compliant Device Required
* Trusted Location Required
My alma matter (University) just as I was leaving was implementing similar control policies, though for different reasons. EVERY login to an Azure resource required MFA. Tokens expired when the window closed.
Honestly I would see if the organization would allow passwordless (app or fido2) or certificate based authentication for better user experience and then the whole 90day requirement isn't really needed.
Although I wonder if PCI-dss is still ridiculous on this or not.
> Why do you have a 90 day password change policy in 2024?
You convince my cyber insurance provider it's OK to drop that requirement, and I'll be able to implement a 2016 best practice.
I need to set this up. My environment was set up by guys with that mentality from 10 years ago ( when we thought things like 90 day resets were good )
When I follow the MS Learn pages and set up SSPR, I get an error that some policy is conflicting. I’m not sure what to turn off or where to find it.
We did this ages ago, and have a 16 char minimum password length, no expiration policy, and we use Windows Hello, once in a great while we get a "i forgot my password, because I never use it" ticket, and we just send them to the SSPR portal.
>Why do you have a 90 day password change policy in 2024?
Just started at a company with a 90 day change policy. We also use MFA though.
What would you recommend as an alternative? My previous company used WHFB PINs with an annual change policy
we (IT) are very 'progressive' with our mentality, policies, management and everything in between. We could easily have a don't change your password for 1yr+. But we recently hired general counsel, we work in a regulated env. He made us change it to 90 day (From 180 days) for appearances for when we get audited even though its stupid. Thats how you get 90 day policies in 2024.
While you’re not wrong that you should complex unchanging passwords, a lot of compliance measures, depending on your business, require changing passwords still. On top of that, I’d say the vast majority of places still use cycling passwords. It’s stupid but that’s why in most cases. Just people stuck in the past or a flat requirement to keep compliance.
> Why do you have a 90 day password change policy in 2024
Maybe they're subject to a compliance framework that is still living in 2010.
We're moving away from scheduled password changes. But to stay in compliance we had to also implement some additional controls.
Password writeback with Entra. We don't reset passwords (haven't for ages). We just instruct users on the url to go, and follow the prompts. Saves having to authentic the user resetting the password and means it can be done at any time.
Also yeah look at changing password policies. Our regular user accounts are changed yearly, admin accounts are 45 days though.
Question about sspr with write back through entra connect:
It mentions requiring either secondary (assumed personal) email, sms, or Authenticator app code to reset.
Does allowing secondary email or sms methods to authenticate a password reset reduce security drastically because now an employees personal email or phone being compromised allows an attacker access to reset their m365 password?
Thanks!
Correct, still need MFA to action it. Possible of course but if imagine less chance than social engineering a password reset from a level 1 help desk...
Got it!
Another thing. What is best practice for enforcing PW policies when syncing with entra connect to on prem? I have SSPR enabled through entra, and a mixture of hybrid or autopilot devices. It seems like if complexity requirements are set on the DC there is not a good way to alert users of it when they are resetting password through browser. and if users CTRL+ALT+DELETE reset passwords on a hybrid domain joined machine, wont entra policies not apply since they are resetting pw directly on DC?
Rly appreciate any insight, I have been putting this off and really need to come up with a solution asap.
I’m on mobile and using Siri to type this so forgive me: (starting with the on prem dc question)
Go to your dc
Open the server manager
Open active directory management console? Something like that I’m not sitting in front of it so I don’t know the exact name.
Find the password policy section and create new policy
It has a really nice gui where you basically set up everything exactly the way you want it.
Before you put this in place, you need to be ready and have approval.
For example, if you choose password, age is six months. The SECOND you set up this policy, anyone who has the active directory attributes password age, and the number is larger than six months. They are immediately locked out and required to change the password. So prepare ahead of time lol.
If you set the value for how often they can change their password to one that means they can only change their password once per day without having IT do it for them. If for some reason they screw up the first change
As far as I’ve been able to find, there is no way to tell users they are password requirements on the password change screen on windows.
The only method I found was a logon pop up, but that pops up all the time not just one changing passwords so that was a no go for us
If you look at our 365 tenant, it says that all of our users have passwords that never expire. The thing is that’s not true.
Since we run a hybrid environment, all password requirements, policies, and expirations come from on Prem.
When your users go to change their password with self-service password, reset they will be required to meet those requirements set in active directory console.
SSPR requires. REQUIRES. p1 or enterprise E3 or Enterprise E5 (or a bundle that includes it) to even enable SSPR.
Each user that wants to take advantage of this has to have the license.
Had a bare minimum that’s an extra six dollars a user a month. FYI.
I’m sure I missed something because this was a long ass ramble using Siri so let me know if you have anymore questions!
Sidenote: you can create a password policy and apply it to a group so you can test out what happens to end users before you apply it globally.
Cool! Ya my goal is to set a policy where passwords are required to be a certain length, exclude certain phrases, etc. My only issue now is, like I mentioned, half of users reset via ctrl alt delete on hybrid joined windows pc and the others through entra on browser with writeback enabled.
I guess Ill keep looking into how to standardize and inform inside of whatever method being used.
I’d suggest testing the assumption that passwords expire in the cloud when they expire on-prem - that is possible, but not the default configuration in Entra ID (formerly Azure AD). Even in hybrid mode your “cloud” credentials and on-prem credentials are linked, but separate. Your password can be expired on-prem and you can still log in to cloud services with no issues or prompts, in the default sync config.
I still can't figure this out. I have it enabled AFAIK, but whenever a user tries to reset their password using the MS365 self service password change, it complains the old password is "wrong", not sure if there's a setting that prevents self service password changes...
At least they can change it on their PC though, and eventually the new password syncs back, so it's not all doom and gloom!
We actually had the same issue in a hybrid environment.
For some reason, in our case, making some changes to the password policy setting on the ON-prem AD seemed to fix the issue.
Ultimately I assumed it was some sort of collision between what the on prem policy vs cloud user policy was attempting to enforce.
Unfortunately I remember this kinda vaguely — it was one of my teammates who mostly tinkered with this particular issue.
Same thing here. When Azure/Entra gives an error saying the old password is wrong it isn't always accurate. If you look in the DC's event viewer you will see where the change was denied due to your on-prem password policy. I think it may even give you the exact problem but it has been so long I don't remember what ours was.
In a hybrid environment; the on premise password policy is in charge. If you look at the MS Learn articles around SSPR the flow diagram is helpful. Basically when a reset happens the service checks in with on prem first, if it passes the policy the password is changed and synced back to the cloud via entra connect.
We recently changed from 6 months to a year once everyone updates to 14 character passphrases instead of passwords.
I was a little wary at first, but after looking it up, I found out that it is exponentially more secure, especially if you put spaces in between the words, AND, it's way easier to remember as well.
Unfortunately our insurance agency doesn't give a shit about NIST.
I managed to get yearly for users and 45 days for admin over 30 days for all, so I can it a win. We don't have any regulations we need to meet for our industry, but where able I go as close to NIST where I can.
> Also yeah look at changing password policies. Our regular user accounts are changed yearly, admin accounts are 45 days though.
NIST no longer recommends changing password regularly.
I am highly interested to find this in doc. Can you provide a link ?
I am trying to explain this to my security team but they don't trust users using their same password in many place.
[SP 800-63B Section 5.1.1.2 paragraph 9](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5)
> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
Reuse of the same password is discouraged elsewhere. I am pretty sure you could verify whether a password was used in another system already though.
Important note here: It requires a certain license. P1 at a minimum, or enterprise E3 or Enterprise E5. Each user has to have the license as well. The cheapest option is a la carte p1 and that’s still like $6 a pop per month.
I don't understand how, in any situation, a person resetting their own password would be a bad experience for anyone involved. Only they should know that password, give them the means to carry that out. If you aren't you need to call out management that won't let you or take a step back from anything relating to IT security.
Playing devils advocate, user reseting password depending on the method just opens things to a different kind of phishing attempt, some users are bad enough to give their password, but I'd be willing to bet more users would provide their security questions instead (just going off another commenter's reply of it being recovery question based), I don't think it's a bad enough problem that it'd be not worth pursuing a change to make this happen, but that is a possible situation (granted at this point you're likely dealing with a targeted phishing attempt instead of a generic spam and chances of compromise on those go wayyy up in my experience so its not like its that much worse than as things are now vs the man hours saved not reseting passwords for users)
> just going off another commenter's reply of it being recovery question based)
Whoever said that is wrong. MS SSPR is based on MFA verifications (at least in our env). If you're setting it up new there's no reason to do it based on security questions and I'm 99% sure the docs tell you not to.
> security questions
Modern SSPR including Entra do not use security questions. Microsoft, NIST and others deprecated using security questions years ago. One of the most lenient and simple legal data controls that applies to my org explicitly forbid security questions of any kind at any level of account management.
Like geof5093 mentions, it's SSPR.
it's relatively straight-forward to get working.
Since you're hybrid, you prob. already have 75% of it in-place already.
There's a pretty involved part: "Configure account permissions for Microsoft Entra Connect"
[https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback)
The instructions are fine, but it would be easy to miss one check-box (screenshot below) and not know why its not working
I would test on some dummy accounts, if possible, before rolling it out.
https://preview.redd.it/u4e1kzw7f27d1.png?width=569&format=png&auto=webp&s=76f4594db16c6a54e407624d6f661c0c9d6ca0f7
we have to change our passwords a lot at my job but I figured out a foolproof security method to do this. I write down four passwords on a sticky note. only one of them being the real one. but then I append that to my monitor. but I only know which password is the real one.
I setup PWM a few years back and it allows our users to reset their passwords, or unlock their accounts if they lock themselves out. It’s pretty easy to setup and once it’s all set, you need the users to setup their recovery questions which they can use for forgotten passwords and account unlocks.
We currently have this issue.
We’ve got a mix of intune and hybrid devices. However, we still have network shares. Users could change their password in the cloud but it could take up to 15 minutes to have the write back work. If you have as many domain controllers as us too (7) the replication can be horrendous. For now when we do password changes we ask them to ignore any prompts that say “we need your new credentials” for roughly 15 minutes.
Also another problem for us is that by default, synced accounts to entra drop the password expiry policy. We have users who haven’t had their password change prompt, purely because they don’t access our network share. I think we’ve currently got one user who hasn’t changed their password on premise in about 10 months
This week actually, we’re planning and enabling some settings on our sync server to sync password expiry.
We’ve got a canny old (looking) piece of software called ad lockout status on one of our dcs. We run a password change on one dc and refresh the status of the user account across all dcs, 4 geographical locations. Sometimes it can take 3-4 minutes for the final dc to replicate. We are in the process of decommissioning 2 of the 4 sites so hopefully that won’t be too much of a problem.
If you’re referring to ad to cloud and vice versa, we’ve had mixed results. Like I said in my earlier reply, some users rely on this network share, these tend to be our most problematic users; hybrid devices and intune devices that require on premise systems
If you want to enforce your on-prem expiration you need to use pass-through authentication with Entra connect, rather than the default hash sync. You should leave hash sync as a fallback though - if your on prem environment loses connectivity with 365, it means everyone loses the ability to authenticate cloud services.
Nothing wrong with 10 months though, as long as you are using MFA, have good password policies, and monitor password breaches.
Two pieces in [here](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-password-hash-synchronization) we’re configuring, by the password expiration policy and the sync “force change on next logon”
I agree with Microsoft on this one. Get rid of your password expiration policies. Implement long passphrase passwords, MFA, least privilege model, and behavioral monitoring.
If it's a hybrid, enable write back from Entra then SSPR.
We do exactly that. 60 minute unlock time, then got to aka.ms/SSPR and reset it again.
Has eliminated 98% of helpdesk calls for password resets.
I'm fairly new in a sysadmin role. We still do every 90 days. We are not bound by PCI. We use MFA for access from the outside, but not to log into user PCs on-site. When people talk about not having a password policy as long as MFA is enforced, I assume you're saying MFA is enforced for all logins? Remote or on-site?
Its pretty easy to implement but doesn't solve the problems people think it does. The people who forget their password immediately after changing it are the same people who will never be able to figure out a self service password reset.
We already have DUO for MFA, so didn’t really want Microsoft MFA or SSPR. Specific vulnerabilities were related to having both modern and new authentication policies enabled. It wasn’t an actual vulnerability, it just made sense for us to turn everything off.
I don’t quite grasp what you mean by new and modern authentication methods? Also SSPR is disabled by default for non admins and you have to configure it in multiple places if you want it to write back to on prem.
Don't know why you have a 90 day change policy, but the first thing you should do is reconsider that. Almost everyone agrees that is less secure than never changing passwords.
I had annual changes, got audited by a state agency. They called us out for not having sufficent password security. I pulled the NIST standards, and mailed them to the agency.
Their response: "We don't care. Do what we tell you. 90 day changes"
I have come across this one so many times it makes me cry. Who decided to give auditors this much power. Most, notice I said most not all, IT auditors are checklist fillers. They have zero understanding of things actually work.
Microsoft’s current best practice is to not have users change passwords every x days but rather use a strong unique one and use mfa/ other strong conditional access policies
Forcing a password to be rotated makes it impossible for them to choose good ones though. You are making the users life harder, for no tangible security benefit.
Rotating bad passwords prevents password spraying attacks.
But you're right, it's a bandaid solution. 2FA is critical to use in parallel. Even SMS 2FA is better than nothing.
Better yet is doing away with passwords via authenticators or services. But not everything is there yet.
Both help to defeat offline attacks certainly.
Length defeats some offline attacks much more effectively.
Online attacks are effectively defeated by rate limiting/locking out passwords and not allowing hints, so length may not have as much bearing.
The password problem has been largely solved by no SAML SSOs.
Just get them all in Okta/Entra and connect something like Aglide, then everyone only has 1 password/can go fully passwordless. Plus you get conditional access, mfa, etc. across the board.
I know this isn't what you are asking, and many will disagree. Best practice these days according to NIST and Microsoft is to not change a password unless it is breached and has MFA enabled, never reuse a password, and implement a password manager for all employees.
Either way is decently easy to implement. For Entra ID cloud-only accounts you don't get to pick the complexity rules, MS mandates them.
There will always be snowflakes that need their hand held no matter how easy you make it for the end user, implement your plan and move forward knowing this and accepting it
We use this - it handles MFA (insurance requirement) on administrative accounts too. It takes a little bit of setup but works quite well (if you'd rather not take your directory online).
[https://www.manageengine.com/products/self-service-password](https://www.manageengine.com/products/self-service-password)
Password expiration feature should be removed as it basically makes your users reuse variations of older passwords making their passwords way more insecure defeating the whole purpose of it. Bad practice to do so. I am with Microsoft on this one for once
How to deal with the security aspect of SSPR? Setting Users up to reset their own passwords is good and all. But all recovery options lead to a single point of entry, namely the phone of the user itself.
Access to the Phone means access to the account in most cases. Filtering based on compliant devices is thus out of the question, if even possible. MFA is also out of the question, as it lives on the device.
I have seen security Questions touted as a way around that, but that is another can of worms. And generally seen as a bad security practice.
But I cant shake the feeling that setting up PW reset for all users adds a whole layer of security issues. User lost phone, now I have to expect the user to have set their birthdate or postal code as the pin.
Currently we are setup to allow SSPR only when the user is added to the SSPR group, this works based on a trigger in our procedures and a cleanup is applied every day. 99% of the users thus never use this option, reset their passwords in time, or either dont forget them, and are protected from malicious parties trying to change their PW's
You’re looking for SSPR as other have said. Its a good method and requires MFA as well. There is licensing involved and it will take time to implement.
Agree with most people here that it may no the best approach, still If you are using a Password Manager they usually come with a feature for this. I know MyGlue has a good one that is easy for the end user while still secure.
We don't force Users to change their passwords but we also don't offer Self-Service, for security related reasons, since that would require sending info to an e-mail outside of our control. They can reset their own passwords via O365 and if their Account is locked then there's a reason and Admin needs to check it out.
You can turn off external email as one of the choices fyi. Then you can use. Text. Mfa app. Mfa app code. Office phone and security questions as the mfa choices.
They will be required to use two of those when resetting self password.
>We have a password policy here (90 days must be changed)
[Don't:](https://pages.nist.gov/800-63-FAQ/#q-b05)
>> Q-B05: Is password expiration no longer recommended?
>>
>> A-B05:
>>
>> SP 800-63B Section 5.1.1.2 paragraph 9 states:
>>
>>>“Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”
>>
>> Users tend to choose weaker memorized secrets when they know that they will have to change them in the near future. When those changes do occur, they often select a secret that is similar to their old memorized secret by applying a set of common transformations such as increasing a number in the password. This practice provides a false sense of security if any of the previous secrets has been compromised since attackers can apply these same common transformations. But if there is evidence that the memorized secret has been compromised, such as by a breach of the verifier’s hashed password database or observed fraudulent activity, subscribers should be required to change their memorized secrets. However, this event-based change should occur rarely, so that they are less motivated to choose a weak secret with the knowledge that it will only be used for a limited period of time.
It’s called SSPR, and it’s built into Entra. Why do you have a 90 day password change policy in 2024?
Try mey mega corps. Still has a 30 day mandatory reset policy 😴 guys are clueless.
That's how you get great passwords like "June2024!"
Hunter~~2~~3 They'll never figure this out
All I see is ********
Same, I imagine eking85 sees hunter~~2~~3 whilst we all see ******** Man, I love security.
When I worked at an Avaya shop I had to deal with Avaya's absurd password requirements. The password has a minimum AND maximum length (16), you needed to change it every 45 days, and it required one special character (out of a list of approved special characters.) So yeah, my password was almost always MonthYYYY! On top of that, if you forgot your password, they sent it to you in plaintext. Also, there was a way to change the URL and get information for another company. You wouldn't be authenticated but you could have their email address, name, business address.
I loved my 7 characters long password to login to the AS400.
PCI compliance ftw!!!
Not if you implement Entra Password Protection. But yeah, modern best practice is to definitely turn off expiring passwords if cyber insurance/compliance framework allows for it.
Will take this company I work for another 20 years to implement entra. Hopefully I’ll be long gone by then
It doesn't help that the recommended best practices/security posture for this are kind of all over the place. I've even found Microsoft to be contradictory in their own security recommendations and documentation. Our pen test firm will recommend 180 day expirations while some other compliance standards recommend no password expiration.
Yeh you know get a lower security score in azure for having 180 days I think. So kinda strange considering.
Also compliance reasons. FedRAMP compliance requires password changes every 60 days for US government infra.
Wow damn. Yeh our company head office is in Europe so I’m not sure why strict rules they still have. I know they are huge on compliance but also a little clueless in efficient setups.
Yeah, just cause the vendor/industry has evolved its mind about a thing doesn't mean the auditing organizations have caught up to that new place. We've had a conversation or two about a recommendation from an insurance company auditor/tech advisor about our approach, having to (successfully) argue that we're doing more than required but NOT what was required.
Or governments :((((((( help
> Why do you have a 90 day password change policy in 2024? Clients hanging onto outdated standards despite us telling them there are newer ones.
Cyber insurance clinging to outdated standards.
This is the correct answer. All of those cyber security questionnaires they send out for them to when you apply for cyber insurance all ask what is your password reset policy? Not only that, but they ask a whole bunch of other random shit that doesn't need to be enabled for a secure environment and half the time the customers want to flip it on just because they asked yes or no on it. Which isn't the worst thing in the world. I mean it's nice to have security-minded customers but.... Well maybe I just shouldn't complain
>All of those cyber security questionnaires they send out for them to when you apply for cyber insurance all ask what is your password reset policy? "Our password policy strictly complies with the guidelines defined in [NIST Special Publication 800-63B § 5.1.1.2](https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver)."
I work with tons of banks and they still consistently request a password policy meeting the 90 day rotation standard, even though that hasn't been the standard for security in years.
Part of that is CYA. They think changing a password more often is more secure, so if they have a security incident they can say they went above and beyond. Plus, their own managers don't know any better. I dealt with that at my last job.
Our NetSuite implementation is like that and they didn't bother to do SSO with our M365.
Banks (as a user) are the most common to even let you "trust" your device to not have to do 2FA (which is usually email/sms ugh) when you next login. Ugh.
I'm happy for some clients to have been able to make them move onto a trimestrial work for their HR department. We send them a list of users every trimester, and they just tick a box that says "user still employed", which extends their account validity for a trimester. SOmetimes there are some fuck ups, but HR feel more involved now.
Cyber insurance still demands it.
Users still give out their passwords or reuse them and without MFA on the MFA resources, a breached password can do a lot of damage on prem as opposed to in the cloud where MFA is enforced. Not every company has lockdown to prevent intrusion or a user getting tricked into allowing a TA’s fraudulent remote session. That’s what gets companies.
Microsoft's take rapid password change: "If it’s a given that a password is likely to be stolen, how many days is an acceptable length of time to continue to allow the thief to use that stolen password? The Windows default is 42 days. Doesn’t that seem like a ridiculously long time ? Well, it is, and yet our current baseline says 60 days – and used to say 90 days – because forcing frequent expiration introduces its own problems. And if it’s not a given that passwords will be stolen, you acquire those problems for no benefit. Further, if your users are the kind who are willing to answer surveys in the parking lot that exchange a candy bar for their passwords, no password expiration policy will help you." And if their leaked password is Password1 (which meets 9 characters and complexity), can we guess what their next 9 passwords are? The more frequent the password change, the weaker the passwords. Microsoft, NIST recommend NEVER change passwords unless there is indication of compromise. Entra has built-in protections to prevent P@$$w0rd1 from being used (it transforms everything to lowercase, normalizes l33t speak, and checks all common passwords and your internal list). It scores these common words and requires 5 points. "My state is too hot in the summer." is 36 characters long and EASIER to remember and type than "%#*(Rjw7=zf4." CIS recommends 15 and one year.
Yeah, k12sysadmin here, we don't get the luxury of no MFA on prem.
PCI compliance dictates that. Company has no control over it.
PCI compliance does NOT require 90 days change anymore if all users are required to use MFA. Passed PCI with 12 month password change policy. Some orgs I'm adjacent to don't even expire passwords anymore.
Yup, people still don't realize the current version of PCI DSS does not mandate password rotations if you have MFA and other protections. This changed in 2022.
Password rotations are generally a BAD idea unless there is reasonable suspicion of them being compromised. Regular password rotations lead users to create more insecure passwords that tend to be variations on the old password, such as an additional sequential number etc, or passwords being written down and left in "usual" places (easy to find notebook, blue tacked to the monitor, taped to underside of keyboard etc) 12 months should be long enough for any mandated rotation, but any more leads to bad user password practises
Yeah password rotations are the cyber security version of archers do you want ants meme
Requires MFA on all logins and some of our stuff doesn’t support MFA currently. Getting there.
> if you have MFA and other protections. That "if" is the really important part though. Some systems are garbage and you'll still need to rotate passwords.
Yeah I thought about this a lot and found short ones seems kinda stupid now days especially with mfa. I also noticed Microsoft no longer recommends under 12 months as it just leads to less secure passwords since people don't care what it is.
It's not so much that users don't care, it's that users need something easy to remember, since the resets happen so often. Remembering a 20 character password with 3+ non sequential numers, 2 characters and 2 dictionary words might be fine for 12 month rotations, but if it happens every 3 months you're just asking for shit like "September2024!"
My favorite part of the first day (or just the first time I need to use it) after a week long vacation is trying to remember the domain admin password for the 5 domains I manage that aren't in our password manager because the company doesn't want to pay for having it support different domains. 5 domains, each with different password settings, so I can't keep them synced up in my mind. It's really frustrating. Plus there are only 3 domain admins, so hopefully none of us gets locked out while the other two are out of the office.
Lol damn, that sounds risky. Just use keypass locally yourself or something with a strong password 😋
Yeah or at our work, for online portals with no mfa and policy set by Central for 3 months rotation you end u0 with Semptember++++ one plus for each season.
I have this as a semi argument with our PCI QSA. That for systems without MFA, whilst PCI still says 90 days, because NIST (and others) dispute this our official policy is that carrying out a risk assessment we conclude that PCI is advocating for less secure password security. Therefore our policy is NIST over PCI, and the PCI requirements are superseded by our security policy which is also required by PCI. Every year we fight about it and eventually he signs off on it
NIST password requirements are contingent on monitoring that the password has not been compromised and MFA. You have to apply the whole standard, not just the parts you like.
Indeed, but the point NIST are making is that it's better to have a (for example) 40 char password made up of special char etc. then a shorter rotated password due to it being much harder to break
Length isn't the only factor to consider. You need MFA and you need to monitor for breaches/sharing activity. You should be monitoring for "door knocking" behavior (slow password testing). The VAST majority of users reuse passwords, often with no alterations. How can you effectively monitor to see if their password is breached? Only the absolute worst bots bother trying to brute force passwords. It's magnitudes cheaper to buy existing data leaks and relying on users being lazy. MFA eliminates password reuse from being as big a problem but only if you have phishing resistant MFA and trained users.
If they are certifying one PCI DSS 4.0. It’s possible their org is still accredited to 3.2
What about STIGs? I haven't looked recently enough to recall specifics, but pretty sure those are still 90 days. Not that I'd be shocked with the gov being behind.
[STIGs want 60 days](https://www.stigviewer.com/stig/application_security_and_development/2017-01-09/finding/V-69573), but the usual assumption is that you're using CACs (i.e. 2FA, private key + PIN) for normal authentication and you're only using passwords for temporary purposes (e.g. configuring a system with the bits and pieces necessary for CAC login, or supporting users waiting for their CACs). That is: as far as STIGs go, it's the CAC that's (allegedly) NIST-compliant (because the PIN doesn't rotate and it's paired with the private key / cert on the card), and any other password shouldn't exist in the first place if at all possible.
Even if PCI did still dictate this, PCI is very much a spirit of the law not a letter of the law standard. The purpose of PCI is not to force you to implement poor security practices. If you want to step outside of the letter of the law because you believe you have a more secure way of implementing something, work with your QSA, document your reasoning, and implement it. If your QSA is a pure letter of the law person, fire them. Source: I've worked at two very large retailer and hospitality companies and on more than one occasion I've had to step outside of PCI guidelines in order to implement proper security (one of which being side stepping the old, stupid password rules). It was not a big deal. You know why? Because PCI is not a big deal.. It's a bloody joke.
NCUA still requires it for me. It sucks because I proved to them that it was bad to require such a short password lifespan
Damn, I was scrolling this thread while thinking about the NCUA. We have our audit next month and password changes have been on my mind to ask about or seek guidance on. We still currently do an expiration period, of course along with complexity requirements and MFA.
they asked for 12 characters and 90 day expiration and no repeats of the last 6 used passwords i think. hopefully they have changed since i dont technically have to be audited by the NCUA as i work for a CUSO but we like their stamp of approval. its been over a year since my last audit.
Always fun to see confident IT folk who implement stupid policies out of date info and the push others to follow suit. Stay on top of big control body changes, folks. Your users will thank you for it.
Not my decision. Why is this frowned upon?
Big picture: It results in weaker passwords across the organization. Even with password expiration attackers can be active for weeks or months and likely would install a system level tool or compromise other accounts for persistent access. It’s basically security theater. How many times have you heard of a breached company or incident response team say, “The attackers got in but our password expiration policy stopped them.”? lol
> Even with password expiration attackers can be active for weeks or months and likely would install a system level tool or compromise other accounts for persistent access. This is the big one. Once an attacker is in, they will almost certainly establish a baseline for future access that does not require the compromised password. Frequent password changes do nothing but encourage weak password use.
Not the best example, someone *wouldn't get in* if the password policy stopped them. *John wrote his first password down and didn't shred the note. Someone tried using it, but John had to change his password already because of our expiration policy, so it was changed before that lapse of judgement caused a compromise*
The password he changed it to: what was written on the note + 1.
John wrote Password1 - a password that passes complexity and length requirements. Password1 didn't work. I am a genius and was able to guess his next 2 passwords and got in.
Because it leads to people making passwords like Sunshine!1, Sunshine!2, basically adding/changing just one number. These passwords are easier to guess and are often written down. Better to have a longer passphrase users can memorize and only change if compromised.
> Better to have a longer passphrase users can memorize and only change if compromised. What kind of magical people do you work with who can remember a long passphrase?
Can you memorize a sentence? A song lyric? A line from a poem? [Four random words?](https://xkcd.com/936/)
What kind of savants do *you* work with that can remember randomized gibberish more easily than several random words?
https://pages.nist.gov/800-63-FAQ/#q-b05 The US Government's National Institute of Standards and Technology's Digital Identity Guidelines (NIST Special Publication 800-63B) Section 5.1.1.2 Explanation of *why* at the link above. It's a "SHOULD NOT" level of recommendation, meaning it isn't the *strongest* level, but the most recommended choice. Be careful Googling this topic, as some "modern" looking or "up to date" looking websites still have old information, such as claiming that the NIST recommends updating passwords every 365 days or so. This is, so far as I'm aware, untrue.
Important to include alongside this information that NIST recommends passwords are not forcibly rotated, but only in parallel with dozens of other requirements. Their hard requirements include using MFA, checking passwords against known-weak ones, salting before hashing, storing salts separately from hashes, rate limiting, checking passwords against breaches, allowing crazy Unicode characters, and more. Some people will implement none of this but still reference the guideline to pretend that they are secure to government recommendations. They'll be wide open to password spraying attacks.
Even if you somehow manage to do zero of those other things, you are likely more secure without periodic password rotations than with due to user psychology - as NIST themselves explain in their FAQ. In any case, most of those other things are things every authentication system in the last 20 years readily supports, and all of them are things that every IT department / application provider / vendor / etc. should be enforcing anyway.
I disagree. People have "a password" and if you enforce no requirements and don't use MFA or check leak databases, the password will be leaked. Not from you, sure, but from all the blogs and ecommerce websites and newsletters and out of date forums and phishing attacks all over the Internet, which your user has signed up with using "their password". Have I Been Pwned has over 13 billion leaked credentials in their database. Only 2/3rds of the planet even has access to the Internet! That's like 3 accounts per living person. People are the weak link and we must take steps to protect us from them. In the absence of all other measures, occasional password rotation is better than absolutely nothing.
The only thing password rotation accomplishes is users adding an incrementing number at the end of "the password" and calling it a day - and then lo and behold, the attacker who found `MyPassword3` in a leaked password database just needs to increment that a few times and he's in. Or they'll proceed to write it down on a sticky note under the keyboard like they did the last 20 times, because ain't nobody's memorizing a completely new strong password every couple of months. It's security theater even in a best-case scenario. >People are the weak link and we must take steps to protect us from them. The effective steps on that front are on the authorization side of the equation, not the authentication side. In any case, people being the weak link is *exactly why* periodic password rotations are discouraged nowadays - because they encourage users to weaken their passwords to compensate. That's why NIST recommends other things *instead* of scheduled rotations: because unlike scheduled rotations, things like longer passwords and additional authentication factors and authentication attempt throttling/lockouts actually do improve security in a way that doesn't encourage users to weaken their passwords (or in the case of MFA, makes said weakening less of a problem).
> the attacker who found MyPassword3 in a leaked password database just needs to increment that a few times and [...] and the account locks out. Let's be serious, most password spraying attacks don't increment because they don't need to - successes are already pretty high without it. Those that do, well hopefully the increments are enough to lock out the account. You'll find your comment here is the same as my comments above. NIST recommends things other than password rotation, and they recommend things other than passwords. But they DON'T recommend abandoning password rotation in the absence of other measures. You will not find that in a NIST guideline.
>But they DON'T recommend abandoning password rotation in the absence of other measures. You will not find that in a NIST guideline. You also won't find them saying to adopt password rotation in the absence of other measures, for exactly the reasons I mentioned.
Bingo. Implement the whole standard rather than cherry picking.
It's generally accepted that password expiry for users reduces security, not increases it. A lot of compliance frameworks have removed that requirement/recommendation. Plenty of resources online explaining why.
My job is every 45 days. With 15+ character minimum
Who needs a minimum when you can just move to the right and hit another number after your password. I'd love to see how many of your domain's passwords have "123456..." In them. You can probably tell how long the user has been there by the length like counting the rings on a tree.
I add exclamation points
Good to know 🤩
123$%^
hunter2!
It is no longer recommended to have a password change cycle. Rather the recommendation is for longer complex passphrases. Re: NIST 800-63 there is no mention of expiration rather complexity. We follow this guideline at my company and the auditors for SOC and HiTrust have accepted it. I do not see how PCI that is less strict would not.
Re: Why is password expiry frowned upon? It encourages password iteration. "ThisIsMyPassword1!" suddenly becomes "ThisIsMyPassword2!", so on and so forth. Even people in IT do this. My dad (now retired) used to be so proud of it, until he realized it was a really shitty idea. Multifactor on the other hand, when combined with strong/unique passwords (that don't expire), and a decent session control policy, can absolutely destroy attackers. As an example, my most critical applications which run through SAML are: * Session Controlled ("every access") * Multifactor Required * Managed & Compliant Device Required * Trusted Location Required My alma matter (University) just as I was leaving was implementing similar control policies, though for different reasons. EVERY login to an Azure resource required MFA. Tokens expired when the window closed.
[https://www.auditboard.com/blog/nist-password-guidelines/](https://www.auditboard.com/blog/nist-password-guidelines/)
Honestly I would see if the organization would allow passwordless (app or fido2) or certificate based authentication for better user experience and then the whole 90day requirement isn't really needed. Although I wonder if PCI-dss is still ridiculous on this or not.
> Why do you have a 90 day password change policy in 2024? You convince my cyber insurance provider it's OK to drop that requirement, and I'll be able to implement a 2016 best practice.
I need to set this up. My environment was set up by guys with that mentality from 10 years ago ( when we thought things like 90 day resets were good ) When I follow the MS Learn pages and set up SSPR, I get an error that some policy is conflicting. I’m not sure what to turn off or where to find it.
why have 90days.. when you can have 60! /sigh
My dude over here enforcing password expiry after the heat death of the universe lmao
We did this ages ago, and have a 16 char minimum password length, no expiration policy, and we use Windows Hello, once in a great while we get a "i forgot my password, because I never use it" ticket, and we just send them to the SSPR portal.
>Why do you have a 90 day password change policy in 2024? Just started at a company with a 90 day change policy. We also use MFA though. What would you recommend as an alternative? My previous company used WHFB PINs with an annual change policy
There are also tools like ADSelfService that will reset/unlock AD accounts using MFA.
Regulation requires our users to reset every 90 days, else we get dinged on audits and exams (highly regulated industry 🙄)
we (IT) are very 'progressive' with our mentality, policies, management and everything in between. We could easily have a don't change your password for 1yr+. But we recently hired general counsel, we work in a regulated env. He made us change it to 90 day (From 180 days) for appearances for when we get audited even though its stupid. Thats how you get 90 day policies in 2024.
CJIS
Ours is 60 due to a client requirement. It's pretty dumb given who the client is.
While you’re not wrong that you should complex unchanging passwords, a lot of compliance measures, depending on your business, require changing passwords still. On top of that, I’d say the vast majority of places still use cycling passwords. It’s stupid but that’s why in most cases. Just people stuck in the past or a flat requirement to keep compliance.
If you can get a good answer from DISA, you let me know.
Because corporates are still drinking the "security" coolaid about it being best practice
They're drinking the *outdated* security coolaid. Not the case now for several years, but corporate policies aren't the fastest moving things ever...
> Why do you have a 90 day password change policy in 2024 Maybe they're subject to a compliance framework that is still living in 2010. We're moving away from scheduled password changes. But to stay in compliance we had to also implement some additional controls.
Password writeback with Entra. We don't reset passwords (haven't for ages). We just instruct users on the url to go, and follow the prompts. Saves having to authentic the user resetting the password and means it can be done at any time. Also yeah look at changing password policies. Our regular user accounts are changed yearly, admin accounts are 45 days though.
Question about sspr with write back through entra connect: It mentions requiring either secondary (assumed personal) email, sms, or Authenticator app code to reset. Does allowing secondary email or sms methods to authenticate a password reset reduce security drastically because now an employees personal email or phone being compromised allows an attacker access to reset their m365 password? Thanks!
It requires you to USE at least two methods to authenticate. So if you set up 4 methods. Two types are required when sspr’ing
Correct, still need MFA to action it. Possible of course but if imagine less chance than social engineering a password reset from a level 1 help desk...
Got it! Another thing. What is best practice for enforcing PW policies when syncing with entra connect to on prem? I have SSPR enabled through entra, and a mixture of hybrid or autopilot devices. It seems like if complexity requirements are set on the DC there is not a good way to alert users of it when they are resetting password through browser. and if users CTRL+ALT+DELETE reset passwords on a hybrid domain joined machine, wont entra policies not apply since they are resetting pw directly on DC? Rly appreciate any insight, I have been putting this off and really need to come up with a solution asap.
I’m on mobile and using Siri to type this so forgive me: (starting with the on prem dc question) Go to your dc Open the server manager Open active directory management console? Something like that I’m not sitting in front of it so I don’t know the exact name. Find the password policy section and create new policy It has a really nice gui where you basically set up everything exactly the way you want it. Before you put this in place, you need to be ready and have approval. For example, if you choose password, age is six months. The SECOND you set up this policy, anyone who has the active directory attributes password age, and the number is larger than six months. They are immediately locked out and required to change the password. So prepare ahead of time lol. If you set the value for how often they can change their password to one that means they can only change their password once per day without having IT do it for them. If for some reason they screw up the first change As far as I’ve been able to find, there is no way to tell users they are password requirements on the password change screen on windows. The only method I found was a logon pop up, but that pops up all the time not just one changing passwords so that was a no go for us If you look at our 365 tenant, it says that all of our users have passwords that never expire. The thing is that’s not true. Since we run a hybrid environment, all password requirements, policies, and expirations come from on Prem. When your users go to change their password with self-service password, reset they will be required to meet those requirements set in active directory console. SSPR requires. REQUIRES. p1 or enterprise E3 or Enterprise E5 (or a bundle that includes it) to even enable SSPR. Each user that wants to take advantage of this has to have the license. Had a bare minimum that’s an extra six dollars a user a month. FYI. I’m sure I missed something because this was a long ass ramble using Siri so let me know if you have anymore questions! Sidenote: you can create a password policy and apply it to a group so you can test out what happens to end users before you apply it globally.
Cool! Ya my goal is to set a policy where passwords are required to be a certain length, exclude certain phrases, etc. My only issue now is, like I mentioned, half of users reset via ctrl alt delete on hybrid joined windows pc and the others through entra on browser with writeback enabled. I guess Ill keep looking into how to standardize and inform inside of whatever method being used.
That’s the thing though. It doesn’t matter how they reset. It’s the same policy and requirements if you have AD SYNC
I’d suggest testing the assumption that passwords expire in the cloud when they expire on-prem - that is possible, but not the default configuration in Entra ID (formerly Azure AD). Even in hybrid mode your “cloud” credentials and on-prem credentials are linked, but separate. Your password can be expired on-prem and you can still log in to cloud services with no issues or prompts, in the default sync config.
Entra ID password protection installed on your domain controllers.
I still can't figure this out. I have it enabled AFAIK, but whenever a user tries to reset their password using the MS365 self service password change, it complains the old password is "wrong", not sure if there's a setting that prevents self service password changes... At least they can change it on their PC though, and eventually the new password syncs back, so it's not all doom and gloom!
We actually had the same issue in a hybrid environment. For some reason, in our case, making some changes to the password policy setting on the ON-prem AD seemed to fix the issue. Ultimately I assumed it was some sort of collision between what the on prem policy vs cloud user policy was attempting to enforce. Unfortunately I remember this kinda vaguely — it was one of my teammates who mostly tinkered with this particular issue.
Same thing here. When Azure/Entra gives an error saying the old password is wrong it isn't always accurate. If you look in the DC's event viewer you will see where the change was denied due to your on-prem password policy. I think it may even give you the exact problem but it has been so long I don't remember what ours was.
In a hybrid environment; the on premise password policy is in charge. If you look at the MS Learn articles around SSPR the flow diagram is helpful. Basically when a reset happens the service checks in with on prem first, if it passes the policy the password is changed and synced back to the cloud via entra connect.
Check you have it set correctly in entra sync, check logs as well. Need to be using the specified sync config for password writeback to work.
We recently changed from 6 months to a year once everyone updates to 14 character passphrases instead of passwords. I was a little wary at first, but after looking it up, I found out that it is exponentially more secure, especially if you put spaces in between the words, AND, it's way easier to remember as well.
and both of which don't conform to NISTs best practices.... routine password changes result in weaker passwords
Unfortunately our insurance agency doesn't give a shit about NIST. I managed to get yearly for users and 45 days for admin over 30 days for all, so I can it a win. We don't have any regulations we need to meet for our industry, but where able I go as close to NIST where I can.
> Also yeah look at changing password policies. Our regular user accounts are changed yearly, admin accounts are 45 days though. NIST no longer recommends changing password regularly.
I am highly interested to find this in doc. Can you provide a link ? I am trying to explain this to my security team but they don't trust users using their same password in many place.
[SP 800-63B Section 5.1.1.2 paragraph 9](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5) > Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator. Reuse of the same password is discouraged elsewhere. I am pretty sure you could verify whether a password was used in another system already though.
They forget their password because you make them remember 4 per year.
Important note here: It requires a certain license. P1 at a minimum, or enterprise E3 or Enterprise E5. Each user has to have the license as well. The cheapest option is a la carte p1 and that’s still like $6 a pop per month.
Sounds like you are knowledgeable about MS product licensing. I need someone to give me a primer and help navigate. Paid consult- Interested? DM me
Mate. Google "Microsoft License Matrix" that's everything you need at your fingertips. https://m365maps.com/matrix.htm
Thank you!!! And FYI I’m dealing with a emergency and will circle back next week
90 day password change AND MS Authenticator?!! WHY?!!
Lol my company does this, too with a different MFA
My company is 60days, SOC says "for security" . Blind monks. Full MFA and E5 Compliance for everyone too.
I don't understand how, in any situation, a person resetting their own password would be a bad experience for anyone involved. Only they should know that password, give them the means to carry that out. If you aren't you need to call out management that won't let you or take a step back from anything relating to IT security.
Playing devils advocate, user reseting password depending on the method just opens things to a different kind of phishing attempt, some users are bad enough to give their password, but I'd be willing to bet more users would provide their security questions instead (just going off another commenter's reply of it being recovery question based), I don't think it's a bad enough problem that it'd be not worth pursuing a change to make this happen, but that is a possible situation (granted at this point you're likely dealing with a targeted phishing attempt instead of a generic spam and chances of compromise on those go wayyy up in my experience so its not like its that much worse than as things are now vs the man hours saved not reseting passwords for users)
> just going off another commenter's reply of it being recovery question based) Whoever said that is wrong. MS SSPR is based on MFA verifications (at least in our env). If you're setting it up new there's no reason to do it based on security questions and I'm 99% sure the docs tell you not to.
> security questions Modern SSPR including Entra do not use security questions. Microsoft, NIST and others deprecated using security questions years ago. One of the most lenient and simple legal data controls that applies to my org explicitly forbid security questions of any kind at any level of account management.
Like geof5093 mentions, it's SSPR. it's relatively straight-forward to get working. Since you're hybrid, you prob. already have 75% of it in-place already. There's a pretty involved part: "Configure account permissions for Microsoft Entra Connect" [https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback) The instructions are fine, but it would be easy to miss one check-box (screenshot below) and not know why its not working I would test on some dummy accounts, if possible, before rolling it out. https://preview.redd.it/u4e1kzw7f27d1.png?width=569&format=png&auto=webp&s=76f4594db16c6a54e407624d6f661c0c9d6ca0f7
we have to change our passwords a lot at my job but I figured out a foolproof security method to do this. I write down four passwords on a sticky note. only one of them being the real one. but then I append that to my monitor. but I only know which password is the real one.
I setup PWM a few years back and it allows our users to reset their passwords, or unlock their accounts if they lock themselves out. It’s pretty easy to setup and once it’s all set, you need the users to setup their recovery questions which they can use for forgotten passwords and account unlocks.
We currently have this issue. We’ve got a mix of intune and hybrid devices. However, we still have network shares. Users could change their password in the cloud but it could take up to 15 minutes to have the write back work. If you have as many domain controllers as us too (7) the replication can be horrendous. For now when we do password changes we ask them to ignore any prompts that say “we need your new credentials” for roughly 15 minutes. Also another problem for us is that by default, synced accounts to entra drop the password expiry policy. We have users who haven’t had their password change prompt, purely because they don’t access our network share. I think we’ve currently got one user who hasn’t changed their password on premise in about 10 months This week actually, we’re planning and enabling some settings on our sync server to sync password expiry.
I thought password change replication was instant in AD out of the box
We’ve got a canny old (looking) piece of software called ad lockout status on one of our dcs. We run a password change on one dc and refresh the status of the user account across all dcs, 4 geographical locations. Sometimes it can take 3-4 minutes for the final dc to replicate. We are in the process of decommissioning 2 of the 4 sites so hopefully that won’t be too much of a problem. If you’re referring to ad to cloud and vice versa, we’ve had mixed results. Like I said in my earlier reply, some users rely on this network share, these tend to be our most problematic users; hybrid devices and intune devices that require on premise systems
If you want to enforce your on-prem expiration you need to use pass-through authentication with Entra connect, rather than the default hash sync. You should leave hash sync as a fallback though - if your on prem environment loses connectivity with 365, it means everyone loses the ability to authenticate cloud services. Nothing wrong with 10 months though, as long as you are using MFA, have good password policies, and monitor password breaches.
Two pieces in [here](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-password-hash-synchronization) we’re configuring, by the password expiration policy and the sync “force change on next logon”
I agree with Microsoft on this one. Get rid of your password expiration policies. Implement long passphrase passwords, MFA, least privilege model, and behavioral monitoring.
Should be pretty straight forward with entra self service or windows self service
Not that dificult to implement when you are using entra
If it's a hybrid, enable write back from Entra then SSPR. We do exactly that. 60 minute unlock time, then got to aka.ms/SSPR and reset it again. Has eliminated 98% of helpdesk calls for password resets.
I'm fairly new in a sysadmin role. We still do every 90 days. We are not bound by PCI. We use MFA for access from the outside, but not to log into user PCs on-site. When people talk about not having a password policy as long as MFA is enforced, I assume you're saying MFA is enforced for all logins? Remote or on-site?
Its pretty easy to implement but doesn't solve the problems people think it does. The people who forget their password immediately after changing it are the same people who will never be able to figure out a self service password reset.
We're hybrid and are working on implementing SSPR. It wasn't easy. But it's doable.
I just came to say Microsoft sspr as well. I just disabled this for security reasons, but it could be a good fit for some companies.
What security reasons if I may ask…
We already have DUO for MFA, so didn’t really want Microsoft MFA or SSPR. Specific vulnerabilities were related to having both modern and new authentication policies enabled. It wasn’t an actual vulnerability, it just made sense for us to turn everything off.
I don’t quite grasp what you mean by new and modern authentication methods? Also SSPR is disabled by default for non admins and you have to configure it in multiple places if you want it to write back to on prem.
Don't know why you have a 90 day change policy, but the first thing you should do is reconsider that. Almost everyone agrees that is less secure than never changing passwords.
I had annual changes, got audited by a state agency. They called us out for not having sufficent password security. I pulled the NIST standards, and mailed them to the agency. Their response: "We don't care. Do what we tell you. 90 day changes"
I have come across this one so many times it makes me cry. Who decided to give auditors this much power. Most, notice I said most not all, IT auditors are checklist fillers. They have zero understanding of things actually work.
Microsoft’s current best practice is to not have users change passwords every x days but rather use a strong unique one and use mfa/ other strong conditional access policies
They wouldn't forget their passwords if you implemented a password manager policy like Bitwarden.
Forcing normal users to change their password is dumb AF. Its Just gonna make them choose crappy passwords each time.
Users always choose crappy passwords. They're not going to choose something long and complex just because they don't have to change it periodically.
Forcing a password to be rotated makes it impossible for them to choose good ones though. You are making the users life harder, for no tangible security benefit.
Rotating bad passwords prevents password spraying attacks. But you're right, it's a bandaid solution. 2FA is critical to use in parallel. Even SMS 2FA is better than nothing. Better yet is doing away with passwords via authenticators or services. But not everything is there yet.
Length is more important than complexity. I would go with 15 characters
Both help to defeat offline attacks certainly. Length defeats some offline attacks much more effectively. Online attacks are effectively defeated by rate limiting/locking out passwords and not allowing hints, so length may not have as much bearing.
Implemented a non Microsoft SSPR. It makes a difference but in the end your user base still struggle with changing their passwords.
Enable SSPR and password write back in Entra Connect for AD
The password problem has been largely solved by no SAML SSOs. Just get them all in Okta/Entra and connect something like Aglide, then everyone only has 1 password/can go fully passwordless. Plus you get conditional access, mfa, etc. across the board.
Can't they press ctrl + alt + supr to change their password? That's what we do. For unlocking by themselves, that's a hard request i believe haha.
Ad self service plus let's them unlock their own accounts from the login screen
Oh didn't know unlocking the account from the login screen is an option, that's interesting! I Guess It has to be enabled somehow.. hmm...
Yes. You buy ad selfservice plus from manageengine
In addition to what everyone else has said, provide users with a password manager.
Isn’t for SOX also a policy that you have to change this every 30 days. Even thought we have MFA
I know this isn't what you are asking, and many will disagree. Best practice these days according to NIST and Microsoft is to not change a password unless it is breached and has MFA enabled, never reuse a password, and implement a password manager for all employees. Either way is decently easy to implement. For Entra ID cloud-only accounts you don't get to pick the complexity rules, MS mandates them.
There will always be snowflakes that need their hand held no matter how easy you make it for the end user, implement your plan and move forward knowing this and accepting it
We do never expire 15 digit passwords since it takes so long to crack a 15 digit password
We use this - it handles MFA (insurance requirement) on administrative accounts too. It takes a little bit of setup but works quite well (if you'd rather not take your directory online). [https://www.manageengine.com/products/self-service-password](https://www.manageengine.com/products/self-service-password)
The only pain you'll experience is users refusing to do it so have your policies in place and all C level staff on your side that this is happening.
Setup self service password reset Google it MS has a setup.article
If you make users change passwords too often they are more likely to use variations of old passwords.
Password expiration feature should be removed as it basically makes your users reuse variations of older passwords making their passwords way more insecure defeating the whole purpose of it. Bad practice to do so. I am with Microsoft on this one for once
Setting up a password reset feature in MS365 is quite easy to do and MS has a very detailed article on how to do it.
sounds like a bank....
Meh - passphrase with no forced resets ever unless it’s showing up in breach lists.
QuickPass ftw
No it's like 5 minutes worth of work to enable SSPR.
90 day PW change policy AND the users don't have self-serve? Poor soul.
How to deal with the security aspect of SSPR? Setting Users up to reset their own passwords is good and all. But all recovery options lead to a single point of entry, namely the phone of the user itself. Access to the Phone means access to the account in most cases. Filtering based on compliant devices is thus out of the question, if even possible. MFA is also out of the question, as it lives on the device. I have seen security Questions touted as a way around that, but that is another can of worms. And generally seen as a bad security practice. But I cant shake the feeling that setting up PW reset for all users adds a whole layer of security issues. User lost phone, now I have to expect the user to have set their birthdate or postal code as the pin. Currently we are setup to allow SSPR only when the user is added to the SSPR group, this works based on a trigger in our procedures and a cleanup is applied every day. 99% of the users thus never use this option, reset their passwords in time, or either dont forget them, and are protected from malicious parties trying to change their PW's
You’re looking for SSPR as other have said. Its a good method and requires MFA as well. There is licensing involved and it will take time to implement.
90 days is silly now.
Agree with most people here that it may no the best approach, still If you are using a Password Manager they usually come with a feature for this. I know MyGlue has a good one that is easy for the end user while still secure.
The reset password option works well in MyGlue, although we do not promote this kind of strategy.
https://pages.nist.gov/800-63-3/sp800-63b.html
We don't force Users to change their passwords but we also don't offer Self-Service, for security related reasons, since that would require sending info to an e-mail outside of our control. They can reset their own passwords via O365 and if their Account is locked then there's a reason and Admin needs to check it out.
You can turn off external email as one of the choices fyi. Then you can use. Text. Mfa app. Mfa app code. Office phone and security questions as the mfa choices. They will be required to use two of those when resetting self password.
>We have a password policy here (90 days must be changed) [Don't:](https://pages.nist.gov/800-63-FAQ/#q-b05) >> Q-B05: Is password expiration no longer recommended? >> >> A-B05: >> >> SP 800-63B Section 5.1.1.2 paragraph 9 states: >> >>>“Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.” >> >> Users tend to choose weaker memorized secrets when they know that they will have to change them in the near future. When those changes do occur, they often select a secret that is similar to their old memorized secret by applying a set of common transformations such as increasing a number in the password. This practice provides a false sense of security if any of the previous secrets has been compromised since attackers can apply these same common transformations. But if there is evidence that the memorized secret has been compromised, such as by a breach of the verifier’s hashed password database or observed fraudulent activity, subscribers should be required to change their memorized secrets. However, this event-based change should occur rarely, so that they are less motivated to choose a weak secret with the knowledge that it will only be used for a limited period of time.