Magic Link user not found email manipulation - domain extraction about amazon-cognito-passwordless-auth HOT 3 CLOSED

That piece of code is related to user enumeration prevention. It basically returns a bogus email address, that will be masked.

The story is that when requesting a magic link we return the masked e-mail address in the public challenge parameters. This is nice so the user knows where the magic link is sent to (in case the user does not sign-in with magic link but e.g. with username). Unfortunately this opens the door for user enumeration. Which is why we mask the e-mail addresses.

The code you pasted comes into play when a non-existing user signs in, and the user pool is configured with preventUserExistenceErrors=true (note, the default is false). To prevent user enumeration Cognito will then appear to proceed with the sign-in (event though it will never work) and call the custom auth lambda with event.request.userNotFound = true (so we know it is a non-existing user). In that case we don't have an e-mail address to mask and return as public challenge parameters, so we use the fake username to create a dummy e-mail address.

Now that I explained this to you I think we should remove sending back the e-mail address if the user pool is configured with preventUserExistenceErrors=true.

from amazon-cognito-passwordless-auth.

@ottokruse - thanks for the reply - for us the Cognito User Pool is not our System of Record for users (as passwordless makes this possible).

Given CloudFront distribution and latency based routing, our plan is to fire up regional stacks in various regions (as needed based on redundant geographical customer footprint or jurisdictional separations - e.g. due to GDPR) with an immutable architecture, leveraging Dynamo DB Global Tables (with said GDPR separations). Such that we'll create a new User Pool with that stack along with requisite lambdas and regional replicate of Global Table(s) etc.

As such in our Login controller, we can check email as a know user is in the DB and AdminCreateUser and any existing but missing users in the User Pool, before we InitiateAuth since User Migration trigger is incompatible with Custom Auth!

We'd bomb out before the InitiateAuth. Or do you suggest we Initiate the auth anyway to get the effect of the preventUserExistenceErrors=true?

Albeit thinking, we should also be denying magic link auth anyway that have a passkey/fido credential registered per security posture issue #68

well look out for the fix you mention above at the end.

from amazon-cognito-passwordless-auth.

We have gotten rid of sending back the email address as public challenge parameter in #134

from amazon-cognito-passwordless-auth.