Adjust Cognito security policy for blocking suspicious login attempts

[landonshumway-ia]

We had a staff user that was attempting to login for the first time to the beta environment and failed multiple times over the course of several days while traveling. This combination caused the Cognito threat protection system to block the user from logging in as it was flagged as a risk of account takeover. We have some configuration we can set to determine when a user should be blocked, or when they should just be required to use MFA (which we already do by default for prod and beta)

The purpose of this ticket is to determine what configuration options we have available and configured those desired changes in Cognito, if any, as determined by management.

This may be part of MVP launch, or we may decide to address it if more issues like this pop up, as it should only require minor configuration changes to implement.

Notes

Questions

Assumptions

Estimate

3

Implementation Notes

[landonshumway-ia]

This has now happened a second time, as there was another staff user that was traveling while failing to enter their password and the system flagged them as suspicious. Pulling this up in backlog to address:

[landonshumway-ia]

As part of this ticket, we currently have a support gap for how we intend to help practitioners recover access to their account in the event that they lose access to their MFA option (ie their phone breaks) Right now, if a user loses access to their MFA, they have no way to gain access back into their account without technical support intervention. This is going to create massive overhead for support and increases risk of the social engineering attacks where bad actors attempt to reset MFA of users to compromise existing accounts.

Cognito does offer MFA options to allow the user to select between TOTP tokens (ie authenticator apps) and email. I attempted to prove this out through the beta environment, but I hit a hurdle in the managed login UI that I was not able to work around at the time:

Whoever picks up this ticket needs to verify if this is an option for us, since allowing users to use email as an alternative option for MFA would significantly reduce the risk of users losing access to their account. Long term, we will likely need to look into options for allowing user's to update their MFA option through the UI, so they can manage their MFA setup if they need to use an alternative authenticator app for example.

[jusdino]

After doing some research, it appears that email-based MFA is not a viable option for either staff or practitioner users, as it would require significant changes to account recovery configuration, including enabling phone-based account recovery and making collection of user phone numbers mandatory.

[jusdino]

Awaiting a decision on whether we will stop blocking any of the low/medium/high risk events. After discussion, we decided to wait a few weeks and see how often these events cause problems.

[StacyNGriffin]

Closing. Covered in other ticket.