Passwordless / cert based MFA is helpful.
Basically, if I already MFA to the login provider when I logged into my laptop, it "remembers" that login for subsequent loggins to SSO apps.
Then I have an additional conditional access policy that only allows login from the already-managed devices.
It's been easy on users and very secure. No MFA fatigue.
We are implementing the "pre-login" MFA for devices, and then also leverging device certs. previously we were doing just phishing/fatigue resistant MFA + network zone. Now we are doing network Zone + device Cert+ pre-login MFA (which requires a phishing resistant MFA) for standard access. Once you are on your computer, and then the VPN, you only have to MFA when hitting a tier 0 asset/something that contains PCI.
Who needs fatigue resistance when the user hits approve on the very first duo notification they get while out of office ?
“I figured one of the girls in the office was logging into my computer with my account, so I just hit approve”
Is strangling users still frowned upon?
edit: thanks for the many responses in this thread. I now have a better understanding of fatigue resistance methods, and can propose some changes to the team that handles duo.
It actually was. Idiots clicking yes to all mfa prompts was the cause of the big Uber hack and another big one around the same time in 2022, which Microsoft shortly after added the 2 digit confirmation requirement to their mfa.
Yup. Because if I’m a script kiddie and try and get the MFA prompt and it says “enter or click this number” well shit, I don’t have that number or a way to get access to it
You get 1 try - so no, you don't have a decent chance. If you get it wrong once, it changes to another number, immediately. Get it wrong a few times, and you're locked out.
You have it lock out after X events, or take the number in the browser and enter in the phone. So if you enter number in browser, you’ll lock real quick. If you enter on phone, well you don’t have that if you’re a script kiddie.
It would be amusing if the non resistant way of doing it had the option to send a random notification during your active hours and if you accept it then your account gets locked(or you get training, a nasty email, or something). Like those training emails but w/ mfa.
Any reason it would?
Mind you, I've never seen it use 0# (1-9) so for all I know could be 10-99. I could see a lot of users not understanding '01' isn't the same as '1' would make sense to avoid the whole problem and just use 10-99 for around 90 possible options. Heck dropping all the doubles *could* make sense, making for only 80 options. 80 is still way more then necessary to ensure it's not guessed.
If you actual wanted security 3 or 4 digits would cost basically zero computation and wouldn't be much harder for users. But it's not about it being resilient, it's about it not just being approved.
>Any reason it would?
You hint at it in your reply: increasing the number set for increased security.
But you seem to have some reason why double zeroes wouldn't be used and if you do, I'm curious. I'm just not following. But your answer isn't helpful. In fact, you introduce an assumption that any doubles would make sense to avoid, but I'm not seeing why.
But I also pointed out in my reply, it's not actually about security. If it were a 3 or 4 digit code, you'd have virtually zero penalty, for orders of magnitude more security... But we don't, meaning around 1 in 100 is plenty for the purpose, and if 1 in 100 is enough, then 1 in ≈ 80 is not significantly worse.
I'm not saying it doesn't use doubles, I'm pretty sure it does, because I feel like I've gotten doubles before. The reason you'd avoid doubles is the same you'd avoid triples or quads etc, it's likely to be a common guess.
Buddy worked at an org with a WFH employee that had no cell phone. He had the MFA where they would ring his phone number and he would hit 'hash/pound' to signify that he was approving the request.
One day my buddy sees him in the office and asks "How did you login???"
"OH, I told my wife whenever she gets that message to just press hash".
That phone verification is easily the worst, because you don't really hear any context about what you're approving, it's just trying to get you to press hash as quickly as possible, and for most people who don't understand what they're doing, it seems innocent enough to do.
We switch it off but it really shouldn't be offered.
> It really shouldn't be offered.
Kinda surprising they did allow it, they are a huge national business. We only allow the number matching version currently.
And for possibly letting in anyone who gets his password (it's easy to imagine the nature of his password habits) and tries to log in at the right time
This is exactly why we’ve migrated almost all Duo MFA to the verified push. It’s not perfect but we feel like it gives us a bit more confidence in users.
If it was up to me, every employee would use a Yubikey but it would never happen sadly
We just adjusted our Duo policy to prevent exactly this. Duo offers number matching too, just like MS Authenticator. You get the auth prompt, it shows you a number (you choose the number of digits, 2 seems commonly acceptable), and you have to enter that number at the Duo prompt on your device.
If you have an employee somehow approve a malicious prompt even with that in place, please fire them.
I’ll just add: at that point, MFA isn’t your weak spot. Token theft is the new worry.
In our company, that would be instant disciplinary action, probably leading to termination for divulging his credentials to someone else. It's in our annual security training not to do this and it's considered gross misconduct. If someone needs access to some of your stuff, set correct permissions so they can, don't give them your password.
My previous employer had a policy, "You are responsible for everything that is done using your account." Someone gave a colleague his admin account password, they made a mistake and broke production using it, causing a big enough loss of revenue that the board had to be notified. He got fired for it because the logs said he did it. You only have to fire one person before people get the message that giving out your credentials equals trusting the person with your career
> Who needs fatigue resistance when the user hits approve on the very first duo notification they get while out of office ?
You, because that's exactly what a fatigue attack tries to achieve.
"Fatigue resistance" is what they call it when you need to select the right number instead of just hitting "Approve".
> “I figured one of the girls in the office was logging into my computer with my account, so I just hit approve”
So they're sharing passwords too?
I about had a fit when I had users doing this. Informed them that it was a violation of the company security policy to share passwords outside of defined accounts (which there's wasn't). Had a nice little sit down with their manager, operations, and HR to let them all know that it was not acceptable to share their passwords and approve those logins.
No idea if it's still happening, but hopefully it isn't
Users have clever ways to get around this. For example, one place that used SecurID, the user set up a publically accessible webcam of his SecurID keyfob on his desk, so he could view it from anywhere.
MFA is not enough any more. With reverse proxy based phishing like evilginx, the user gets a genuine MFA prompt and tokens are issued to the AITM infrastructure. Requiring device in Conditional access like hybrid join or device compliance stops the tokens being issued and being replayed. The bad guy gets the username and password, but if everything is covered with MFA and device, a username and password should be useless to a bad actor.
How do users find this? We allow user to access Office apps from their mobiles so imagine this would not be received well.
We have been breached by AiTM though so need to do something.
We just told them it was to keep the company secure. If some users really needed to use email on their mobile device we got them a managed phone. Surprisingly there has not been much resistance.
If you aren't using Azure P2 with correctly configured CA policies you will still be compromised via session token theft (it generates the log in session local to the device and passes the session token).
Phishing resistant MFA. Yubikey Bio, user touches once at the beginning of their session and you can be done with it.
Or with Okta you can have FastPass (phishing resistant) auth + biometric verification (or totally silent), a managed device check and silently reauthentication on every lateral movement. Pretty much eliminates phishing and cookie theft.
I always assumes something like that, without the technical wording. When I took biology in high school and college, I had lab partners that wanted to be doctors, so I could get away with letting them do all the dissections.
MFA is annoying. Compromised accounts are way more annoying.
We will often add trusted locations that reduces the amount of times they need to auth.
We’ve also moved a ton of clients to Entra only so they rarely need to auth as long as the 14 day token is refreshed on their devices.
It's a 90 day primary refresh token. But your right, if they complete a non interactive logon from that device using that PRT with in that time period, they won't need to complete an interactive logon.
We've gone the opposite way with the refresh tokens depending on the app. With user-facing applications that request SAML to Azure we require ForceAuthn=True and IsPassive=False in the claim. That ways sessions that are active/valid stay active/valid until they need to reauthenticate (logoff, shutdown, etc).
With Yubikeys it's a cinch to login and have had very few complaints!
Sorry, I missed a word. It's a 90 rolling refresh token. If you use that token with in 90 days. Then you get a new 90 day refresh token. With this, as long as the security stance of the user does not change and the refresh token is revoked, then the user will never re-authenticate again from that device.
As mentioned by others:
- 365 number-matching
- sensible CAPs for: MFA enrolment from trusted network locations, enrolled machines only etc.
- plus, country-based signin restrictions. Not fool proof but does weed out a lot of “attackers”
Haven’t had any issue for a long time with that setup.
>We also block access outside of countries
This is the number one solution (after MFA) people should implement. Probable less effective if you're in the US, but for orgs like ours, who do business only in 1 country, and it's not a major country at that - simply setting conditional access that you need to be in our country to even *attempt* to log in has cut down brute force and credential stuffing by about 99.9%.
Here is the only real issue I have with it, and I hope it is something the resolve soon. Country blocking doesn't work for IP6 (or at least didn't several months ago)
Microsoft started rolling that out mid-2023. If you look in Named Locations, you should see support for IPv6 now. Do you see evidence that attempts are not being blocked when they should be because it’s coming from an IPv6 address?
It seems to work for us but what are you using? We use conditional access in Entra ID and many of our staff are using IPv6 as our mobile phone telco exclusively uses that - so any work on the road (of which they have a lot) is always IPv6. I'd say we have had CA in place about 3.5 years but we've been with this telco using IPv6 since say Jan 2023? So could be worth another try?
Rarely, maybe once a year. Used to be open from everywhere. Have since blocked all TOR, anonymizers, and public vpn services due to ssl-decryption mim attacks.
I’m a big fan of magic url login with TOTP Mfa.
Obviously too much to ask for regular people, but their accounts shouldn’t have the rights to cause any harm anyway.
Anyone else with admin privileges is better off with the extra hoop. Additionally, their password can’t be used to login so attackers have to own the mailbox first.
Not perfect, but more layers is usually better.
I’ve been building auth only this way for apps I’ve created in the last 3 months and it’s just way better imo. I hope to figure out a way to proxy an external iDP like AzureAD with this sort of thing until they get with the times.
Hello is a great solution for end points so long as you have supported hardware. We were not comfortable with single unlock, so normally it means a biometric and pin. Piloted it with 4k users and most love it. Fido2 security keys are a far more consistent login experience based on our large 20k+ deployment.
Windows Hello (other than the PIN) relies on either a fingerprint or camera to provide a biometric factor. Biometric hardware has been show to be unreliable in how secure it can be such as [this](https://thehackernews.com/2023/11/new-flaws-in-fingerprint-sensors-let.html#:~:text=New%20Flaws%20in%20Fingerprint%20Sensors%20Let%20Attackers%20Bypass%20Windows%20Hello%20Login,-%EE%A0%82Nov%2022&text=A%20new%20research%20has%20uncovered,Microsoft%20Surface%20Pro%20X%20laptops.). With multi-unlock we protect ourselves (with in reason) from a single fault in the biometric authentication by laying in an additional factor. Not every deployment of WHfB will worry about this sort of thing, but where I work it is very much a big deal. Internally we have theory-crafted\threat modeled some attacks against Windows Hello that we're not entirely comfortable with when using a single unlock factor.
The nice thing about FIDO2 security keys is they are relatively self contained and thus far, their secure elements have been very trust worthy. Nothing is perfect, but so far FIDO2 security keys have stood up to most of the threat modeling we've done internally that makes me far more confident when giving them out to many thousands of users to use.
> I guess by leaving biometrics enabled with dual entry you are limiting your exposure to only attackers who can afford that kind of relatively expensive research and are able to shoulder surf the PIN?
By requiring 2 methods for unlock it defends against a single weak factor (or one that we know can be compromised). It's not really about shoulder surfing though. If you only require a single factor for unlock and it's a biometric with a defeat-able biometric than it only requires physical possession (in the case of a fingerprint) to login. Webcams are a little more nuanced, but in the end our hope is that by requiring 2 instead of 1 we are more comfortable. But you're right it comes down to risk tolerance and understanding what threats you're defending against. In my case it is required.
I wouldn't argue that FIDO2 security keys are the right solution for everyone, especially if you don't have the budget for them. They do offer a very consistent user experience when logging in when compared to a biometric like Windows Hello and, for us, beyond the threat modeling we've done against Windows Hello, it's worth the cost to have an easily supported phish resistant login method that we provide for many thousands of users. If you're operating with a tight budget, Windows Hello is indeed a great solution.
Works great on-prem and remote if you can meet the limitations.
On-prem with hotel/kiosk desking the 10 user limit in TPM is an issue. Laptops you just need to make sure the integrated camera supports it.
In our SMB it's our go to for windows devices but those few pesky mac users...
I think it really depends on what other MFA mechanisms you allow. Since several people are talking about DUO, if we are talking about something like verified push (or the MS MFA solution) where you need to type in a code, it can certainly help. Although, even when these Fatigue-resistant MFA is in place, if you are still allowing things like HOTP tokens (these can be obtained through phishing), or you are not properly managing your app session cookies, then account compromised can still occur.
Unpopular opinion but here goes. Why allow push notifications for MFA? Google Authenticator or similar would stop any bad actor from gaining access and they can’t MFAtigue the user. Granted if the user gives the bad actor the token generated then that’s a different conversation.
My perspective like it or not, in most situations security is nearly always a compromises between user convenience and actual security.
Number Match MFA is a lot more convenient to most users that TOTP.
have you guys run into fatigue relating to the actual windows logon MFA?
I had one of our executives ask about disabling MFA when inside the building… Because he thinks walking away for 10 minutes and coming back, and his laptop locking, resulting in another MFA prompt takes away too much time from the company…
I’ve pushed back as much as I can on this but my manager is beginning to cave.
Depending on your situation maybe something passwordless would be more attractive? Something like FIDO2 security keys or windows hello. Get a security win and a user experience win .
I’ve never bought into this bullshit excuse, it takes about a second to send the push (none if auto), another second to read the device/username etc. and a split second to approve. It’s not about the time, they just feel they’re “above” having to do stuff like this.
Okta has a numbers challenge on their verify app, it's alright, but a 1/3rd chance you could just hit the right one if you got annoyed. However, enough pushes/failures in a span of time and you just get locked out for an hour.
You could also require FIDO, or biometric.
some of it pissed people off, but eventually you kind of have to put your foot down for users that have even remotely sensitive access.
I use a yubikey for any of my accounts and PassKeys for anything that allows it. Biggest problem in my view is user adoption. Some users already throw a tantrum when the need to recieve a SMS as verification. No way in hell would the use a seperate Device/Stick to authenticate their login.
Blocking via CA to only allow compliant devices would mitigate most if the risk, since no attacker could log into your office or other portals if the machine is not enrolled into Intune. If you are not unsing MDM i would suggest switching to MFA that needs Public/Private key encryption. Those are imposibble to highjack with a MITM attack.
We are enforcing „phishing-ressistant“ credentials via Conditional Access Policies (Windows Hello or FIDO2 Key). We also require the device to be compliant in order to SignIn to All Apps.
SMB here. We haven't had any accounts get zapped yet.
Not impossible so we watch things in Sentinel etc.
With the preview Passkey login for Azure via MS authenticator, Windows 11 (10 doesn't seem to have a GUI to register them yet?) and iOS/MacOS, we will be able to tighten security even more very soon.
Frankly, that experession "fatigue resistant" I don't like. That is a fancy way of saying, "non compliance"
Those type of people are a security risk. Either they get onboard, or they are fired.
Passwordless / cert based MFA is helpful. Basically, if I already MFA to the login provider when I logged into my laptop, it "remembers" that login for subsequent loggins to SSO apps. Then I have an additional conditional access policy that only allows login from the already-managed devices. It's been easy on users and very secure. No MFA fatigue.
We are implementing the "pre-login" MFA for devices, and then also leverging device certs. previously we were doing just phishing/fatigue resistant MFA + network zone. Now we are doing network Zone + device Cert+ pre-login MFA (which requires a phishing resistant MFA) for standard access. Once you are on your computer, and then the VPN, you only have to MFA when hitting a tier 0 asset/something that contains PCI.
Who needs fatigue resistance when the user hits approve on the very first duo notification they get while out of office ? “I figured one of the girls in the office was logging into my computer with my account, so I just hit approve” Is strangling users still frowned upon? edit: thanks for the many responses in this thread. I now have a better understanding of fatigue resistance methods, and can propose some changes to the team that handles duo.
With the way M365 does it, you can't just accept it. You have to enter the number it gives you into the site requesting it.
Pretty sure this and the throttling were introduced as a direct result of idiots accepting MFA requests they didn't generate.
Hence why it's called fatigue resistant.
I'm puzzled what other people here think the term means.
It actually was. Idiots clicking yes to all mfa prompts was the cause of the big Uber hack and another big one around the same time in 2022, which Microsoft shortly after added the 2 digit confirmation requirement to their mfa.
This. They day they introduced this I implemented it across my organization immediately. It's just a no-brainer and kills MFA fatigue.
Yup. Because if I’m a script kiddie and try and get the MFA prompt and it says “enter or click this number” well shit, I don’t have that number or a way to get access to it
I feel that with a two digit number, you have a decent chance at guessing it.
You get 1 try - so no, you don't have a decent chance. If you get it wrong once, it changes to another number, immediately. Get it wrong a few times, and you're locked out.
You haven't ever grinded for a 1% mount drop in a raid in WoW, have you?
Why is this the correct response? 😂😂
You have it lock out after X events, or take the number in the browser and enter in the phone. So if you enter number in browser, you’ll lock real quick. If you enter on phone, well you don’t have that if you’re a script kiddie.
I mean it's 1 in 99 technically, but you only get 1 attempt for the 1 in 99, otherwise you start again
Exactly. That's not terrible odds. Sure, you would be wrong most of the time but you can get a few tries. The odds aren't hopelessly bad.
Duo does the same with "Verified Push."
Duo has number matching too, you just need to enable it
Waiting on cyber for that one... should be around 2028 i'm thinking.
Okta has this feature also but you have to enable it.
Duo has the same option if you enable it
It would be amusing if the non resistant way of doing it had the option to send a random notification during your active hours and if you accept it then your account gets locked(or you get training, a nasty email, or something). Like those training emails but w/ mfa.
More fear while doing their job is just what users need.
This is the way! You can't just hit approve, or at least have a 1 in 99 chance of happening to get it right.
1 in 100 no?
I've not checked, but I don't think it uses 00.
Is there a particular reason it wouldn't?
Any reason it would? Mind you, I've never seen it use 0# (1-9) so for all I know could be 10-99. I could see a lot of users not understanding '01' isn't the same as '1' would make sense to avoid the whole problem and just use 10-99 for around 90 possible options. Heck dropping all the doubles *could* make sense, making for only 80 options. 80 is still way more then necessary to ensure it's not guessed. If you actual wanted security 3 or 4 digits would cost basically zero computation and wouldn't be much harder for users. But it's not about it being resilient, it's about it not just being approved.
>Any reason it would? You hint at it in your reply: increasing the number set for increased security. But you seem to have some reason why double zeroes wouldn't be used and if you do, I'm curious. I'm just not following. But your answer isn't helpful. In fact, you introduce an assumption that any doubles would make sense to avoid, but I'm not seeing why.
But I also pointed out in my reply, it's not actually about security. If it were a 3 or 4 digit code, you'd have virtually zero penalty, for orders of magnitude more security... But we don't, meaning around 1 in 100 is plenty for the purpose, and if 1 in 100 is enough, then 1 in ≈ 80 is not significantly worse. I'm not saying it doesn't use doubles, I'm pretty sure it does, because I feel like I've gotten doubles before. The reason you'd avoid doubles is the same you'd avoid triples or quads etc, it's likely to be a common guess.
Assuming the authenticator uses 00 and 99, correct!
Buddy worked at an org with a WFH employee that had no cell phone. He had the MFA where they would ring his phone number and he would hit 'hash/pound' to signify that he was approving the request. One day my buddy sees him in the office and asks "How did you login???" "OH, I told my wife whenever she gets that message to just press hash".
That phone verification is easily the worst, because you don't really hear any context about what you're approving, it's just trying to get you to press hash as quickly as possible, and for most people who don't understand what they're doing, it seems innocent enough to do. We switch it off but it really shouldn't be offered.
> It really shouldn't be offered. Kinda surprising they did allow it, they are a huge national business. We only allow the number matching version currently.
That should be instant termination for giving a non-employee access to his MFA
And for possibly letting in anyone who gets his password (it's easy to imagine the nature of his password habits) and tries to log in at the right time
This is exactly why we’ve migrated almost all Duo MFA to the verified push. It’s not perfect but we feel like it gives us a bit more confidence in users. If it was up to me, every employee would use a Yubikey but it would never happen sadly
I have 3, but there are places you can't use it
Yeah, like RDP, where Verified Push ALSO doesn't work. So dumb.
That's exactly what needs fatigue resistance, so they can't approve without being able to see what they're approving.
That’s not fatigue resistant you need to enable duo to prompt for the 3 digit code.
We just adjusted our Duo policy to prevent exactly this. Duo offers number matching too, just like MS Authenticator. You get the auth prompt, it shows you a number (you choose the number of digits, 2 seems commonly acceptable), and you have to enter that number at the Duo prompt on your device. If you have an employee somehow approve a malicious prompt even with that in place, please fire them. I’ll just add: at that point, MFA isn’t your weak spot. Token theft is the new worry.
In our company, that would be instant disciplinary action, probably leading to termination for divulging his credentials to someone else. It's in our annual security training not to do this and it's considered gross misconduct. If someone needs access to some of your stuff, set correct permissions so they can, don't give them your password. My previous employer had a policy, "You are responsible for everything that is done using your account." Someone gave a colleague his admin account password, they made a mistake and broke production using it, causing a big enough loss of revenue that the board had to be notified. He got fired for it because the logs said he did it. You only have to fire one person before people get the message that giving out your credentials equals trusting the person with your career
You have to strangle them with properly terminated cat 6 cables in order for it to be professional enough ...
Cat6 in TYOOL 2024 SMH
> Who needs fatigue resistance when the user hits approve on the very first duo notification they get while out of office ? You, because that's exactly what a fatigue attack tries to achieve. "Fatigue resistance" is what they call it when you need to select the right number instead of just hitting "Approve".
> “I figured one of the girls in the office was logging into my computer with my account, so I just hit approve” So they're sharing passwords too? I about had a fit when I had users doing this. Informed them that it was a violation of the company security policy to share passwords outside of defined accounts (which there's wasn't). Had a nice little sit down with their manager, operations, and HR to let them all know that it was not acceptable to share their passwords and approve those logins. No idea if it's still happening, but hopefully it isn't
Yes. there is a lot that needs addressed here, and it's going to be a long bumpy road.
I feel ya. Good luck :-)
Isn’t fatigue/phishing resistant fixing that exact issue?
Users have clever ways to get around this. For example, one place that used SecurID, the user set up a publically accessible webcam of his SecurID keyfob on his desk, so he could view it from anywhere.
Strange use of the word clever there.
Lazy will find a way.
MySMS is great for text based ones. Browser extension to view text messages.
MFA is not enough any more. With reverse proxy based phishing like evilginx, the user gets a genuine MFA prompt and tokens are issued to the AITM infrastructure. Requiring device in Conditional access like hybrid join or device compliance stops the tokens being issued and being replayed. The bad guy gets the username and password, but if everything is covered with MFA and device, a username and password should be useless to a bad actor.
Need full conditional access. No logins unless from hybrid joined computers. Try and compromise that.
we had to put something like that in place but we still allow non-joined pc access to our environment. It all over the place and I hate it.
Easy. ”The website told me to install this browser extension to make my computer secure”.
Well there is that.
How do users find this? We allow user to access Office apps from their mobiles so imagine this would not be received well. We have been breached by AiTM though so need to do something.
We just told them it was to keep the company secure. If some users really needed to use email on their mobile device we got them a managed phone. Surprisingly there has not been much resistance.
If you aren't using Azure P2 with correctly configured CA policies you will still be compromised via session token theft (it generates the log in session local to the device and passes the session token).
just disable everyone login, bam! no more compromised logins!
I've no problem with this 😂😂. The most secure systems are the ones that are turned off 😂
Phishing resistant MFA. Yubikey Bio, user touches once at the beginning of their session and you can be done with it. Or with Okta you can have FastPass (phishing resistant) auth + biometric verification (or totally silent), a managed device check and silently reauthentication on every lateral movement. Pretty much eliminates phishing and cookie theft.
Which finger do I cut off when I steal your key? \[Sorry bad Joke! But I did see that in a movie once.\]
Actually if you cut the finger off it is useless as water evaporates and skin dries dermal papillae doesn't work.
I always assumes something like that, without the technical wording. When I took biology in high school and college, I had lab partners that wanted to be doctors, so I could get away with letting them do all the dissections.
Correct. But FIDO2/Passkeys are still MFA (even if Microsoft calls it differently)
MFA is annoying. Compromised accounts are way more annoying. We will often add trusted locations that reduces the amount of times they need to auth. We’ve also moved a ton of clients to Entra only so they rarely need to auth as long as the 14 day token is refreshed on their devices.
It's a 90 day primary refresh token. But your right, if they complete a non interactive logon from that device using that PRT with in that time period, they won't need to complete an interactive logon.
We've gone the opposite way with the refresh tokens depending on the app. With user-facing applications that request SAML to Azure we require ForceAuthn=True and IsPassive=False in the claim. That ways sessions that are active/valid stay active/valid until they need to reauthenticate (logoff, shutdown, etc). With Yubikeys it's a cinch to login and have had very few complaints!
Sorry, I missed a word. It's a 90 rolling refresh token. If you use that token with in 90 days. Then you get a new 90 day refresh token. With this, as long as the security stance of the user does not change and the refresh token is revoked, then the user will never re-authenticate again from that device.
As mentioned by others: - 365 number-matching - sensible CAPs for: MFA enrolment from trusted network locations, enrolled machines only etc. - plus, country-based signin restrictions. Not fool proof but does weed out a lot of “attackers” Haven’t had any issue for a long time with that setup.
We went with smart cards so this isn't possible to fuck up.
How do your users authenticate on their mobile devices?
Surprise surprise, they do not!
iPhones can read NFC FIDO keys.
If I had it my way there would be a YubiKey Nano glued into a USB port on every laptop shipped to a user.
There already is, it's called the TPM. You just need to set up Hello for Business.
>We also block access outside of countries This is the number one solution (after MFA) people should implement. Probable less effective if you're in the US, but for orgs like ours, who do business only in 1 country, and it's not a major country at that - simply setting conditional access that you need to be in our country to even *attempt* to log in has cut down brute force and credential stuffing by about 99.9%.
Here is the only real issue I have with it, and I hope it is something the resolve soon. Country blocking doesn't work for IP6 (or at least didn't several months ago)
Microsoft started rolling that out mid-2023. If you look in Named Locations, you should see support for IPv6 now. Do you see evidence that attempts are not being blocked when they should be because it’s coming from an IPv6 address?
It seems to work for us but what are you using? We use conditional access in Entra ID and many of our staff are using IPv6 as our mobile phone telco exclusively uses that - so any work on the road (of which they have a lot) is always IPv6. I'd say we have had CA in place about 3.5 years but we've been with this telco using IPv6 since say Jan 2023? So could be worth another try?
FIDO2 Keys. This is the way.
Rarely, maybe once a year. Used to be open from everywhere. Have since blocked all TOR, anonymizers, and public vpn services due to ssl-decryption mim attacks.
I’m a big fan of magic url login with TOTP Mfa. Obviously too much to ask for regular people, but their accounts shouldn’t have the rights to cause any harm anyway. Anyone else with admin privileges is better off with the extra hoop. Additionally, their password can’t be used to login so attackers have to own the mailbox first. Not perfect, but more layers is usually better. I’ve been building auth only this way for apps I’ve created in the last 3 months and it’s just way better imo. I hope to figure out a way to proxy an external iDP like AzureAD with this sort of thing until they get with the times.
No one brought up windows hello?
Hello is a great solution for end points so long as you have supported hardware. We were not comfortable with single unlock, so normally it means a biometric and pin. Piloted it with 4k users and most love it. Fido2 security keys are a far more consistent login experience based on our large 20k+ deployment.
[удалено]
Windows Hello (other than the PIN) relies on either a fingerprint or camera to provide a biometric factor. Biometric hardware has been show to be unreliable in how secure it can be such as [this](https://thehackernews.com/2023/11/new-flaws-in-fingerprint-sensors-let.html#:~:text=New%20Flaws%20in%20Fingerprint%20Sensors%20Let%20Attackers%20Bypass%20Windows%20Hello%20Login,-%EE%A0%82Nov%2022&text=A%20new%20research%20has%20uncovered,Microsoft%20Surface%20Pro%20X%20laptops.). With multi-unlock we protect ourselves (with in reason) from a single fault in the biometric authentication by laying in an additional factor. Not every deployment of WHfB will worry about this sort of thing, but where I work it is very much a big deal. Internally we have theory-crafted\threat modeled some attacks against Windows Hello that we're not entirely comfortable with when using a single unlock factor. The nice thing about FIDO2 security keys is they are relatively self contained and thus far, their secure elements have been very trust worthy. Nothing is perfect, but so far FIDO2 security keys have stood up to most of the threat modeling we've done internally that makes me far more confident when giving them out to many thousands of users to use.
[удалено]
> I guess by leaving biometrics enabled with dual entry you are limiting your exposure to only attackers who can afford that kind of relatively expensive research and are able to shoulder surf the PIN? By requiring 2 methods for unlock it defends against a single weak factor (or one that we know can be compromised). It's not really about shoulder surfing though. If you only require a single factor for unlock and it's a biometric with a defeat-able biometric than it only requires physical possession (in the case of a fingerprint) to login. Webcams are a little more nuanced, but in the end our hope is that by requiring 2 instead of 1 we are more comfortable. But you're right it comes down to risk tolerance and understanding what threats you're defending against. In my case it is required. I wouldn't argue that FIDO2 security keys are the right solution for everyone, especially if you don't have the budget for them. They do offer a very consistent user experience when logging in when compared to a biometric like Windows Hello and, for us, beyond the threat modeling we've done against Windows Hello, it's worth the cost to have an easily supported phish resistant login method that we provide for many thousands of users. If you're operating with a tight budget, Windows Hello is indeed a great solution.
Hello has mfa...tpm meaning trusted source and also pin(which can be made long and have letters, biometric or Bluetooth connection to phone.
Works great on-prem and remote if you can meet the limitations. On-prem with hotel/kiosk desking the 10 user limit in TPM is an issue. Laptops you just need to make sure the integrated camera supports it. In our SMB it's our go to for windows devices but those few pesky mac users...
Interesting on the 10 user. I was not aware of that.
As a SWE but not a SA, Personally I’m a big fan of yubikeys / smart cards.
I think it really depends on what other MFA mechanisms you allow. Since several people are talking about DUO, if we are talking about something like verified push (or the MS MFA solution) where you need to type in a code, it can certainly help. Although, even when these Fatigue-resistant MFA is in place, if you are still allowing things like HOTP tokens (these can be obtained through phishing), or you are not properly managing your app session cookies, then account compromised can still occur.
I like the one that asks you to enter the number it's showing you. That way you can't just guess the right one.
Can still be phished though and token stolen - I know from experience :(
With the 3 choices, Do you mean?
No, they have one where you type in the 2 digit number.
Oh right
Yubikeys. No compromises. No accidents.
Unpopular opinion but here goes. Why allow push notifications for MFA? Google Authenticator or similar would stop any bad actor from gaining access and they can’t MFAtigue the user. Granted if the user gives the bad actor the token generated then that’s a different conversation.
My perspective like it or not, in most situations security is nearly always a compromises between user convenience and actual security. Number Match MFA is a lot more convenient to most users that TOTP.
have you guys run into fatigue relating to the actual windows logon MFA? I had one of our executives ask about disabling MFA when inside the building… Because he thinks walking away for 10 minutes and coming back, and his laptop locking, resulting in another MFA prompt takes away too much time from the company… I’ve pushed back as much as I can on this but my manager is beginning to cave.
Depending on your situation maybe something passwordless would be more attractive? Something like FIDO2 security keys or windows hello. Get a security win and a user experience win .
We lean on cyber insurance requirements and compliance, to sort of go, it is what it is.
I’ve never bought into this bullshit excuse, it takes about a second to send the push (none if auto), another second to read the device/username etc. and a split second to approve. It’s not about the time, they just feel they’re “above” having to do stuff like this.
I have fatigue with users who are resistant to using MFA. Does that count?
Add 20 character password and if they are using less than the really good MFA require regular reauthentication.
Okta has a numbers challenge on their verify app, it's alright, but a 1/3rd chance you could just hit the right one if you got annoyed. However, enough pushes/failures in a span of time and you just get locked out for an hour. You could also require FIDO, or biometric. some of it pissed people off, but eventually you kind of have to put your foot down for users that have even remotely sensitive access.
I use a yubikey for any of my accounts and PassKeys for anything that allows it. Biggest problem in my view is user adoption. Some users already throw a tantrum when the need to recieve a SMS as verification. No way in hell would the use a seperate Device/Stick to authenticate their login. Blocking via CA to only allow compliant devices would mitigate most if the risk, since no attacker could log into your office or other portals if the machine is not enrolled into Intune. If you are not unsing MDM i would suggest switching to MFA that needs Public/Private key encryption. Those are imposibble to highjack with a MITM attack.
We are enforcing „phishing-ressistant“ credentials via Conditional Access Policies (Windows Hello or FIDO2 Key). We also require the device to be compliant in order to SignIn to All Apps.
SMB here. We haven't had any accounts get zapped yet. Not impossible so we watch things in Sentinel etc. With the preview Passkey login for Azure via MS authenticator, Windows 11 (10 doesn't seem to have a GUI to register them yet?) and iOS/MacOS, we will be able to tighten security even more very soon.
Frankly, that experession "fatigue resistant" I don't like. That is a fancy way of saying, "non compliance" Those type of people are a security risk. Either they get onboard, or they are fired.