AWS Cognito user pools with MFA and advanced security off leave identity perimeters open

Defaults that define the boundary

A technical analysis published on dev.to makes a focused argument about AWS Cognito: the user pool is where an application's identity boundary actually sits. It authenticates customers, issues the JWTs the application trusts, and brokers sign-in through social identity providers. Everything else a team does for security — encryption at rest, network isolation, audit logging — only matters after the pool has decided that a session gets to call the API at all.

The problem, according to the analysis, is that a user pool created through the console or with aws cognito-idp create-user-pool starts life with two safety features switched off: MfaConfiguration and UserPoolAddOns.AdvancedSecurityMode both default to OFF. The settings look like small checkboxes that can be flipped later, the author notes, and in that state they routinely reach production.

What password-only sign-in invites

With MFA off, a password is the entire authentication factor. The analysis lays out three attack patterns that become trivial as a result. Credential stuffing replays email and password pairs from breach dumps against the sign-in endpoint, and successful guesses produce sessions indistinguishable from legitimate ones. Password spraying inverts the approach: one weak password is tried across many known usernames, and because Cognito's per-user lockout only fires after repeated failures against a single account, a spray that hits each account once never trips the threshold. And a password recovered through phishing is all an attacker needs to sign in directly.

Advanced security is the layer that would catch these attempts, the dev.to piece explains. When enabled, it runs a risk model over every sign-in — unusual location, impossible travel, credentials known to be compromised from external feeds — and can respond by challenging the user, blocking the attempt, or sending a notification. It is also a paid feature, and the author argues that is precisely why it frequently stays off: the risk engine AWS built into the service goes unused because of an extra cost many operators decline.

The HackerOne takeover chain

The analysis points to a HackerOne disclosure it refers to as the bomma report as a concrete example. That chain relied on two pool settings: email was used as a username alias, and email changes were not verified. An attacker who could modify a victim's email address — through a separate flaw such as parameter pollution in a profile-update endpoint — could then trigger the standard forgot-password flow, reset the credential, and take over the account.

MFA would have broken that chain, the author argues. With it on, the attacker would also need the victim's second factor. With advanced security on, the unusual-location sign-in that follows a password reset would have triggered an additional challenge. With both disabled, finishing the reset completes the takeover.

Detection and remediation

The author frames the requirement as an invariant: customer-facing Cognito user pools must enforce MFA, with a carve-out for internal pools whose upstream identity provider already handles second factors. To make that checkable, the piece demonstrates a policy control — CTL.COGNITO.MFA.001, severity high, in a tool called Stave — that flags any user pool where MFA is not enforced, along with a before-and-after example in which a reported violation clears once both switches are turned on.

The remediation itself is short. Two CLI calls do the work: set-user-pool-mfa-config with --mfa-configuration ON and software-token MFA enabled, and update-user-pool with --user-pool-add-ons AdvancedSecurityMode=ENFORCED. The analysis recommends encoding the same settings in Terraform — mfa_configuration set to ON, a software-token block, and advanced_security_mode set to ENFORCED — so the configuration survives recreation of the pool.

On the mode choice, the author distinguishes AUDIT, which only records what the risk model would have done, from ENFORCED, which actually challenges or blocks. AUDIT can be reasonable for a new rollout while a team observes what the engine would catch; steady state should be ENFORCED.

Why it matters

Identity is the front door: no amount of downstream hardening compensates for a pool that hands valid tokens to anyone presenting a working password. The attacks described require nothing exotic — breach data, a weak-password spray, or a profile-update bug — and the defaults make them viable out of the box. Against that, the fix is two API calls plus an infrastructure-code edit, which is why the analysis singles MFA out as the change with the most impact for the least effort in this cluster of misconfigurations.