Stop asking for passwords

It’s been common practice for a long time to ask for passwords, surely we are migrating to passwordless authentication, but we are not there yet. So, what can we do to improve the security of our applications? What about setting a sign-in frequency?

This is an opinionated post, I’m looking at this from the perspective of a security consultant that wants the best solution for the users, while still preserving security. I want to open a discussion about this topic, so please leave a comment if you have a different opinion.

Problem

I’ve been working with a customer that uses Entra ID for all their user identities. This identity solution from Microsoft works great, it suits their needs. Now they want to connect a new application that supports SAML2 for identity federation. This is great news, Entra ID also supports this an it’s medium complexity to set up. After configuring the application in Entra ID, and configuring the SAML2 part in the cloud application, it worked sometimes.

SAML2 has some mandatory properties that are always sent to the application, one of them is the AuthnInstant property in the <saml:AuthnStatement> object.

The AuthnInstant attribute specifies the time at which the user authenticated with Microsoft Entra ID.

– Microsoft sso saml protocol

In this case the cloud application requires the AuthnInstant to be not older then 10 hours, making a security decision based on the time the user authenticated. This might be a good security practice, back in the days when users only had a password to authenticate.

Time at which the user authenticated

The time at which the user authenticated, was the key to the problem, of the application not working all the time. Microsoft count these events as user autentication events:

• User enters his password at the login page in the browser.
• User uses Windows Hello for Business to authenticate to the laptop.

So if you checked the Remember me checkbox at the Login page, it’s possible that you’re not asked for your password for a long time. This is off course by design, we don’t want to ask for passwords all the time.

Windows Hello also counts as an authentication event, so if you use Windows Hello to unlock your laptop, that would solve the issue. The customer (in the education sector), does not manage all the devices, so they cannot enforce Windows Hello for Business on all devices.

Citing with the service provider

I’ve been working with the service provider to find a solution for this issue. I’ve been asking them to remove the AuthnInstant requirement, but they are not willing to do that. I’ve also been asking them to add a configuration option to disable this requirement or to make the amount of hours configurable, but they are not willing to do that either.

For the customer we solved it by creating a special conditional access policy that force the user to enter their password every 8 hours. This is not a great solution, because it asks the user to enter his password (in a school environment, with a lot of prying eyes) every 8 hours.

Security decisions by service providers

The service provider (the cloud application) is making a security decision based on the time the user authenticated. We (the customer and me) do not care when the user actually entered his password for the last time, in fact the longer ago the better. We care about the fact that the device (or the browser) is trusted, and that the system checks all the conditional access policies before letting the user access the application. Maybe we want to trigger a MFA prompt or force the user to use a hardware key, if the conditional access policy requires it.

These MFA prompts won’t change the value for the AuthnInstant attribute though, because it’s not a new authentication event.

Security decisions are made by the identity provider

I think that security decisions should be made by the identity provider, not by the service provider. The identity provider knows the user, the device and the conditional access policies is has in place. The service provider only knows the user, and when he entered his password for that last time.

Using conditional access policies the IT department can make sure that specific user may or may not access that application from that location, devices or browser.

In a time where we have these policies in place, are switching to conditional MFA and trusted/untrusted devices and locations, it’s time to say goodbye to service providers making security decisions based on a fraction of the information.

Entra ID and the AuthnInstant attribute

As stated above, successfully confirming a MFA prompt does not change the value of the AuthnInstant attribute. In my honest opinion it should, because the moment Entra ID confirmed the user identity, is way more important then the moment when the user entered his password for the last time.

Being able to override the value for this attribute with a special conditional access policy would also solve the issue.

Conclusion

Security decisions should be made by the identity provider instead of the service provider. The identity provider has all the information to make the right decision, the service provider only has a fraction of the information.

This article is highly opinionated, I’m looking forward to your opinion on this topic. Please leave a comment on LinkedIn or Twitter.