Posted On Jan 1, 2021

In my secular profession (yes, I’m religious), I’m a senior IT architect/software engineer with a concentration in Cloud security and identity and access management and governance (i.e., IDAM, IAM, IGA, etc.). What I’m about to share verges on the crux of secured access and user experience.

It’s December 1, 2020, and I am simply baffled that certain use cases are not taken into account when implementing multi-factor authentication, especially within organizations that go to such an extent to secure their access from fraudulent users – it gets to the point of prohibiting authorized users. How so, you ask?

Let’s consider the following contexts:

• Device enrollments
• Between services
• Device Enrollments

Changing Smartphones

When I was switching out my iPhone 11 Pro with the iPhone 12 Pro Max, I realized that I would need to re-register my MFA apps on the iPhone 12. What I didn’t count on was how long t would take for me to complete this. Bearing in mind that I use Okta Verify, Microsoft Authenticator, Google Authenticator, Authy, IBM Verify, and even my cell phone number as 2FA – it was not seamless! To further compound this, I have 10 Okta accounts confined in Okta Verify, 3 accounts with Google Authenticator as 2FA, 3 accounts in my IBM Verify tenant, and 5 Azure/O365/Outlook.com services configured in my Microsoft MFA app. As you can imagine, upgrading iPhones year-to-year now would make this a chore!

In fact, opting for time-based one-time passwords (T-OTP) over short message service (SMS, text messaging) would allow me to upgrade smartphones without worry, but some of these services only support these push notification options (which I do like), or T-OTP inputs (which is like T-OTP/SMS, but without the SMS delivery).

Suffice it to say, it required another 60-70 mins for me to migrate all my MFA accounts using device enrollment, and verification on my “currently upgrading” iPhone while on Wifi (and I missed 3 accounts to boot, which required me to call the service desk of the account to get them to reset my device enrollments).

In conclusion on device enrollments and the smartphone leasing community of uses, there is an opportunity to perhaps use blockchain for “my device” consenting to these service instead of managing MFA devices (includes U2F, etc) in a system or app used by the person rather the service (or a non-blockchain method, but you get the idea).

Lack of Self Service

One of my clients has me set up with 2 accounts – for the sake of this blog, let’s refer to them as parent.com and subsidiary.com. I was set up with [email protected] first, and enrolled my iPhone 11 pro with Microsoft Authenticator as the MFA option for my O365 account profile management. When I switched to iPhone 12 pro max, I follows the same steps I mentioned in the Change Smartphones section above.

However, problems arose when I was provisioned with [email protected], and I was prompted to enroll in the parent company’s mobile device management (MDM) system, (in this case, Azure-based Intune). What I didn’t count on was how Intune would highjack my Microsoft Authenticator application configurations, which included my subsidiary.com account (not to mention my outlook.com account, as well as a few others for other clients or my employer). Since I could not complete the email access configs on the iPhone, I decided to remove the MDM profile – it was at this point I saw what happened to my Microsoft MFA app configurations.

While parent.com Azure allowed me to re-enroll my Microsoft Authenticator app (and also allowed me to chose other 2FA options if my Microsoft Authenticator app is not available), but subsidiary.com did not allow me to re-enroll until I satisfy the 2FA through Microsoft Authenticator app (which blocked me from re-enrolling the Microsoft Authenticator app on my iPhone 12). Confused and having a headache yet? Imagine when I encountered this!

Companies need to think through all use cases – otherwise when user experience becomes cumbersome, the point of relying on these MFA options would not be preferred (in fact, avoided if possible).

Between Services

My MFA is better than yours!

As I mentioned in ny previous Device Enrollment rant, I have quite a number of Cloud services that are protected with MFA with a handful of MFA services.

But what happens if one service prefers to verify your identity using their MFA vs your identity provider’s MFA?

Using the federated trust relationship between parent com and subsidiary.com, let’s assume the following:

subsidiary.com is a SAML2 IdP to parent.com

• I have an MFA with push notification configured in subsidiary.com
• I have an MFA with push notification configured in parent.com

In my case, parent.com IAM architect knows about the MFA options in subsidiary.com, and is not enforcing MFA for the federated SSO from subsidiary.com.

But I talked to a company that wanted to enforce MFA at parent.com regardless of the MFA in the federated SSO with subsidiary.com, giving me the old Russian adage “Trust by verify”.

To simulate late this, I configured my IBM Verify (that uses IBM Verify app for MFA) and my Okta tenant (which uses Okta Verify app for MFA). Now, in my case, I also configured in my Okta tenant (the SAML SP) a rule that requires MFA for users in the admin group only. Here’s an illustrate of the flow:

I request an Okta-protected service

1. Okta redirects me to IBM Verify to authenticate
2. IBM Verify requires MFA completion, based on authentication policy configured, then redirects me back to Okta with a signed SAML assertion in response
3. Okta requires MFA completion, based on authentication
4. Okta grants me access to other services or applications, if I’m authorized
5. As I mentioned earlier, if parent.com IAM architect knows about the MFA options in subsidiary.com, then adding a policy exemption for (or not enforcing) multiple MFAs is possible. But what if that level of detail is unknown (as in social login configurations) or is disregarded?

I posit that a new SAML assertion and OIDC JWT assertion to reflect certified MFA be considered, such as “Trusted by RSA” or “Verified by Okta”, etc with a verifiable record (like Acclaim badges or CRL in PKI).

Original Post: Out of my MFA mind