Recently an Okta customer was interested in being able to set a fixed Recovery Question for a subset of its employees. In particular they wanted to use an attribute from their source of truth as a security answer. Having a fixed security question and answer based on an employee attribute does have security drawbacks however in this case the customer deemed the risk to be worth it. This post will present one way to address this problem and also highlight parts of configuration that are required to leverage a security question for recovery. I would personally file this under just because you can doesn’t mean that you should but I present the solution here for your reading pleasure
Setting up Security Questions for Recovery
There are two main configuration items that need to be completed to setup and use Security Questions for Recovery. Enable Security Questions as a Authenticator and configure the Password policy to define how self service recovery can be completed.
The Security Question authenticator can be configured by navigating to Authenticators under the Security menu in the Admin Console and then selecting “Add authenticator”. You should configure it only for recovery as shown below. The official documentation can be found here if you need more details.
To configure the recovery options you should click on Actions -> Edit on the Password row of the Authenticators list. You can then add a new Policy or edit an existing one. I recommend adding a new policy specific to the group of users that you want to target. In this way you can have stronger self service recovery options for other users such as leveraging possession based factors. Inside your password policy you can then add a rule, like the one shown below to enable users to recover their account with a question. The documentation for this can be found here.
Now that you have enabled the security question authenticator and created a rule that allows it to be used as a recovery option we need to move onto creating the workflows needed to create the recovery question and also ensure it can not be changed.
Creating Users with Specific Recovery Question
We are going to leverage a custom profile attribute to store the security question answer for the user permanently. Instructions for how to add a profile attribute in OIE can be found here. Essentially within the Admin console navigate to Directory -> Profile Editor, find the Okta Profile and then hit add attribute. You should then get a popup similar to the below. In this case we are leveraging a badge number and note that we are specifying to hide the attribute. This means a user will not be able to see it, nor even be aware that such an attribute exists. Do note however that admins who have permission to view the user profile will be able to see it.
There are a number of ways to provision users within Okta. This blog will not detail all of the available options. When testing out this design I modified the Workflows Template provided here and described in this video Okta Workflows: Google Sheets as a Source. In my case I added Badge Number as a column in the spreadsheet and leveraged the with Recovery Question option in the Okta Create User Widget then I added the desired question as below.
If you wish to add or change an attribute for an existing user then you can leverage the Update User card to perform the same action as above. This is shown in the next section where we overwrite a users changes.
Preventing uses from changing the question
A proactive user my go into their account settings and try to change or remove the Security Question from their “Security Methods” aka Authenticator list as shown below. In this case we can catch this event and leverage a workflow to add the desired question and answer back.
This event appears in the System Log as shown below. Here we note the event type user.mfa.factor.deactivate and that the reason contains which factor was reset.
Knowing the above we can build a workflow that leverages the User MFA Factor Deactivated Okta event trigger. We filter the event details and confirm that the “SECURITY_QUESTION” string is present in the reason string. The workflow only continues if the string is found. We then leverage the Read User card to retrieve the hidden profile attribute, in this case the Badge Number. Once we have retrieved this information we can use the Update User card to add back in our Recovery Question. In this case we’re retrieve the Badge Number from the user profile and using it to recreate our chosen recovery question and answer, “What is your badge number?”
This flow will be triggered immediately when a user changes their security question within their user profile. Thus ensuring that the desired question is maintained.
Conclusion
As can be seen here the use of workflows and Okta System event triggers make it straightforward to automatically create or replace a users security question. This solution could be extended to create your own pool of fixed security questions and then randomly assign the type of question to each user potentially decreasing the risk of fixed questions. It could also be used to allow security questions to be captured in an alternative application and then added to Okta as needed. Remember that Workflows give you great power but with that you also get great responsibility. Use the tools wiesely.
