Using Azure B2C Custom policy email verification with Sendgrid what is lockout period if exceed number of retries?

Question

We are using Azure B2C custom polices. We use Sendgrid to verify users' emails. Users enter their email address in a flow and we send an email containing a 6 digit OTP code to that address. Users then enter the OTP into the flow to confirm the address and their ability to access it.

Users are permitted 5 attempts to enter the 6 digits, if they exceed this they get the message 'You have exceeded the number of retries allowed'.

If users wait for a period they can try again. We have found waits can range from 10 to 20+ minutes.

What is the expected lockout period if a person enters too many incorrect codes? Is this configurable?

Answer 1

Hi @Mike O , Azure uses smart lockout to mitigate risk. The accounts are locked based on the IP of the request and the passwords entered. The duration of the lockout also increases based on the likelihood that it's an attack. After a password is tried 10 times unsuccessfully (the default attempt threshold), a one-minute lockout occurs. The next time a login is unsuccessful after the account is unlocked (that is, after the account has been automatically unlocked by the service once the lockout period expires), another one-minute lockout occurs and continues for each unsuccessful login. Entering the same, or similar password repeatedly doesn't count as multiple unsuccessful logins. Since you're using Sendgrid, these defaults may be different as you mentioned.

To customize the smart lockout settings you can follow this guide.

Please let me know if you have any questions and I can help you further.

If this answer helps you please mark "Accept Answer" so other users can reference it.

Thank you,

James

Answer 2

Hi James,

Thank you for taking the time to respond. My focus is really Sendgrid I think regarding OTP attempts from an email verification.

We integrated Sendgrid using the Microsoft example and it has worked well. But I cannot find any documentation on the behavior to too many entries of the OTP received by the user via email to confirm that selfsame email.

I was hoping someone in the community might have experience with this.

Thanks,

Mike