Great Overview Nick. Loved the Star Wars analogy for describing token Theft :) You make a really good point about the browser on an unmanaged device. I suppose this is another reason why we should be blocking users from logging on to web browsers using their personal accounts.
I’m a little confused about what you say around the 11:10 mark. If the user signs in fram a compliant device - the user is granted an access token. Surely that token would be able to replay from another browser? Why wouldn’t it? Once I have your authenticated session from your hybrid joined compliant device - entra will let me in. Or am I misunderstanding something?
Yea you are correct, that is a misquote on my part.(updated the video snippet) This worked in testing but it was related to CAE with risky user detection not because of device compliance. This will only help mitigate it if you pair the device with other policies/protections, that reduce this happening like enabling Local Security Authority (LSA) protection on the device.
Microsoft added a template for this as normal MFA is so utterly useless. The template is called "require mdm-enrolled and compliant devices to access cloud apps for all users (Preview)"
Compliant devices etc… won’t protect you from token theft. You authorize from your compliant device and recieves a token. If I steel that token on the way to you I can replay that token in my browser
Thank you for sharing. The information is very impressive, as is the description of the necessary conditions to apply the methods for preventing token theft.
Nick - would rolling up MFA to Passkeys solve this problem upfront? Where if the session token is stolen from a user enrolled with Passkey - the thief would not be able to use it because they couldn't authenticate with device that the Passkey is on due to lack of proximity?
Sorry no. Passkeys would block attempts to steal the tokens or cookies when the actual authentication happens. What Nick explains here is abusing the token from the client after that phase. No matter HOW the token ended up on the client, it can be stolen by malware. Passkeys are great, but does not protect from this kind of attacks as it happens after that has taken place. Let's hope Microsoft (and others) start supporting the Device Bound kind of tokens broader!
@@LivingInCloud1 Thank you for the explanation. I was similarly unclear about whether or not passkeys would solve the problem. I find it a bit annoying that it requires purchasing a rather expensive P2 license just to over come what is a flawed implementation using tokens. Seems like the ability to bind a token to a device should be available to anyone that cares to implement it.
I never use Compliant devices in a CA because it's too buggy. Devices fall off of compliance all the time. I much prefer to use Azure registered and joined. Make sure you pair that policy with one asking for MFA to enroll a device to be safe.
That is what I am afraid of, too... i.e. I have set the Minimum OS version and all of a sudden ALL my devices are non-compliant because of that. While I KNOW for a fact that ALL devices are above the version I set. I triple checked, the version is entered correctly. Still haven't figured out what the issue is.
start gradually, exclude known BYOD (Entra Reg) and target only Office 365 cloud app. Then ratchet up to include all cloud apps. When an org allows BYOD, just exclude those allowed from this policy. In your Intune Device Compliance increase the non-compliant grace period to say like 30 days to allow IT initially adjust and take time to fix the non compliant issues.
It sounds like there is no fix for people who use their home computers to get remote access to company resources unless MS allows token binding to non joined machines?
So I understand all the concepts for the Conditional Access policies to prevent token theft except for the compliant devices policy. In theory if the user is already authenticated with a compliant device and the attacker grabbed that token wouldn't they be able to login since that token already satisfied the compliant devices policies? I didn't think device compliance was actively checked besides the initial login unless you had something like session timeouts where you needed to reauthenticate as it expires. I do get the premise that a compliant device would be harder for an attacker to compromise and grab a token due to corporate security.
I have never seen an answer to this. If it only checks compliance during the initial authentication, that doesn’t do anything to prevent stolen tokens from being reused from a different device.
Thanks for the video; it was very informative. I have a question: MCAS has its own policies for protecting against stolen access tokens by implementing "session access". Would you recommend using those policies in addition to Entra ID, or should we rely solely on Entra ID? Or is that different as it seems the MCAS session policies are very granular...
![Why Your Conditional Access Policies Are Failing [5 Major Pitfalls]](http://i.ytimg.com/vi/IHaGbM7L7b0/mqdefault.jpg)
Awesome....Thank you for explaining and showing! This is exactly what i needed to make our environment secured.
Great Overview Nick.
Loved the Star Wars analogy for describing token Theft :)
You make a really good point about the browser on an unmanaged device. I suppose this is another reason why we should be blocking users from logging on to web browsers using their personal accounts.
I’m a little confused about what you say around the 11:10 mark. If the user signs in fram a compliant device - the user is granted an access token. Surely that token would be able to replay from another browser? Why wouldn’t it? Once I have your authenticated session from your hybrid joined compliant device - entra will let me in. Or am I misunderstanding something?
Yea you are correct, that is a misquote on my part.(updated the video snippet) This worked in testing but it was related to CAE with risky user detection not because of device compliance. This will only help mitigate it if you pair the device with other policies/protections, that reduce this happening like enabling Local Security Authority (LSA) protection on the device.
Microsoft added a template for this as normal MFA is so utterly useless. The template is called "require mdm-enrolled and compliant devices to access cloud apps for all users (Preview)"
Compliant devices etc… won’t protect you from token theft. You authorize from your compliant device and recieves a token. If I steel that token on the way to you I can replay that token in my browser
@hullan666 If they steal the token from the device via a virus but it stops evilginx phishing sites which are the norm.
Superb presentation, elevated with Star Wars. Good work nick ❤
Thank you for sharing. The information is very impressive, as is the description of the necessary conditions to apply the methods for preventing token theft.
10 minutes in and find out that security settings are hidden behind more licensing. Thanks Microsoft.
Nick - would rolling up MFA to Passkeys solve this problem upfront? Where if the session token is stolen from a user enrolled with Passkey - the thief would not be able to use it because they couldn't authenticate with device that the Passkey is on due to lack of proximity?
This is my question as well. Can the token be stolen and used on P1 if using Passkey on Microsoft Authenticator?
Sorry no. Passkeys would block attempts to steal the tokens or cookies when the actual authentication happens. What Nick explains here is abusing the token from the client after that phase. No matter HOW the token ended up on the client, it can be stolen by malware. Passkeys are great, but does not protect from this kind of attacks as it happens after that has taken place. Let's hope Microsoft (and others) start supporting the Device Bound kind of tokens broader!
@@LivingInCloud1 Thank you for the explanation. I was similarly unclear about whether or not passkeys would solve the problem. I find it a bit annoying that it requires purchasing a rather expensive P2 license just to over come what is a flawed implementation using tokens. Seems like the ability to bind a token to a device should be available to anyone that cares to implement it.
@@paulmckenna9477 Indeed, once that takes hold we will be in a very good place. Phishfree logins + Device bound token = LOVE!
I never use Compliant devices in a CA because it's too buggy. Devices fall off of compliance all the time. I much prefer to use Azure registered and joined. Make sure you pair that policy with one asking for MFA to enroll a device to be safe.
That is what I am afraid of, too... i.e. I have set the Minimum OS version and all of a sudden ALL my devices are non-compliant because of that. While I KNOW for a fact that ALL devices are above the version I set. I triple checked, the version is entered correctly. Still haven't figured out what the issue is.
start gradually, exclude known BYOD (Entra Reg) and target only Office 365 cloud app. Then ratchet up to include all cloud apps. When an org allows BYOD, just exclude those allowed from this policy. In your Intune Device Compliance increase the non-compliant grace period to say like 30 days to allow IT initially adjust and take time to fix the non compliant issues.
It sounds like there is no fix for people who use their home computers to get remote access to company resources unless MS allows token binding to non joined machines?
So I understand all the concepts for the Conditional Access policies to prevent token theft except for the compliant devices policy. In theory if the user is already authenticated with a compliant device and the attacker grabbed that token wouldn't they be able to login since that token already satisfied the compliant devices policies? I didn't think device compliance was actively checked besides the initial login unless you had something like session timeouts where you needed to reauthenticate as it expires. I do get the premise that a compliant device would be harder for an attacker to compromise and grab a token due to corporate security.
I have never seen an answer to this. If it only checks compliance during the initial authentication, that doesn’t do anything to prevent stolen tokens from being reused from a different device.
Qpo
Thanks for the video; it was very informative. I have a question: MCAS has its own policies for protecting against stolen access tokens by implementing "session access". Would you recommend using those policies in addition to Entra ID, or should we rely solely on Entra ID? Or is that different as it seems the MCAS session policies are very granular...