B2C conditional access on locations in custom policies

Question

We successfuly enforced conditional access through B2C custom policy based on the doc and on the sample (link also in the doc). The problem with conditional access is that they are evaluated AFTER a user actualy signin (login-NonInteractive). It is specified in every documentation like the one about conditional access on locations :

Conditional Access policies are evaluated when:

• A user initially signs in to a web app, mobile or desktop application.

The problems with that is that a hacker can verify user / password from a leaked list from somewhere else (Twitter for example) by simply using the link on the POST method in the self asserted page. It only has to connect once from a browser, get StateProperties, X-CSRF-TOKEN and the Cookie from Chrome console (network view) and use it in a script to attack. You can try with Postman.

Trust me, it works. So my question is : is there a way to prevent this? Like evaluating risks BEFORE the actual login would be a starting point. Or maybe limit whatever is in that StateProperties to a certain amount of calls. Because it seems to be valid for way to long (hours). At somepoint the call doesn'y work anymore and just refreshing those 3 properties makes it work again.

Answer 1

Hi Patrice Côté ,

Yes, Conditional Access policies are evaluated after the users enter their credentials. This is because the Conditional Access policy needs to identify who the user is in order to apply the policy. So the user needs to authenticate and the conditional access policy will either block or allow the user based on whether the user has met the conditions. Reference: Conditional Access Overview.

Conditional access prompts for additional verification after the initial first-factor authentication and then provides or blocks access accordingly.

However, one option as an additional layer of protection would be to use Identity Protection risk policies to block the users by identifying risky behavior. For example, you can Enable user risk policy for password change to require users to update their passwords before signing in. The risk is assessed based on whether their usernames and passwords match pairs that have been identified as compromised.

If you are concerned about DDoS attacks, Azure DDoS Protection is an additional layer of protection that can be applied. [https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-protection-overview
Let me know if this helps meet any of your requirements. You can also leave feedback directly for the product team in the Ideas forum. I'm happy to reach out on your behalf as well if you would like to share more details about your business case.

Updating the answer:

Smart lockout would probably provide the closest solution to what you are looking for, since it applies to primary authentication attempts. Conditional Access and Identity Protection only apply after the primary authentication is successful [https://learn.microsoft.com/en-us/azure/active-directory-b2c/threat-management

-

If the information helped address your question, please Accept the answer. This will help us as well as others in the community who might be researching similar concerns.

Answer 2

Thanks again @Marilee Turscak-MSFT ! We enforced Smart Lockout afterward. Limited it to 5 tries. Still, a hacker with a list of username/password will probably be able to validate some of them as people don't change passwords and reuses the same over and over again. But I understand that, as of today, those are the tools we can use. Hope your development teams and product manager for B2C will discuss about that topic and maybe it will inspire them for the evolution of the plateform.