UserManager.AccessFailedAsync results in overflow if DefaultLockoutTimeSpan is too large

[bgi-jerry-king]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When using ASP.NET Identity, under certain conditions, the method UserManager.AccessFailedAsync() fails with an overflow exception if the DefaultLockoutTimeSpan is too large.

An example scenario of where this may occur is, when a call is made to SignInManager<TIdentityUser>.TwoFactorySignInAsync() that results in a failed MFA sign-in, the method UserManager.AccessFailedAsync() will be called.

The problem is this line:

await store.SetLockoutEndDateAsync(user, DateTimeOffset.UtcNow.Add(Options.Lockout.DefaultLockoutTimeSpan),
    CancellationToken).ConfigureAwait(false);

The use-case here is that, the DefaultLockoutTimeSpan was being set to TimeSpan.MaxValue as a way to basically enforce lockouts are not automatically removed as a way to lock an account for investigation of suspicious activity for certain operations - such as entering many invalid MFA codes over and over again.

Expected Behavior

I think this should be more forgiving or have a way to set an indefinite lockout timespan. The only alternative currently available is setting to something large, but arbitrary, such as TimeSpan.FromDays(50000) which just looks worse - if you see 12/31/9999 as an end date, you have an idea that it's basically forever, but if you see 2/4/4737, for example, it doesn't mean anything.

So in UserManager either update the call to something like this:

var now = DateTimeOffset.UtcNow;
DateTimeOffset lockoutEnd = now > DateTimeOffset.MaxValue - Options.Lockout.DefaultLockoutTimeSpan? DateTimeOffset.MaxValue : now.Add(Options.Lockout.DefaultLockoutTimeSpan);

await store.SetLockoutEndDateAsync(user, lockoutEnd,CancellationToken).ConfigureAwait(false);

Or a new option added to specify an endless lockout.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

.NET 9

Anything else?

No response

[dotnet-policy-service]

Looks like this issue has been identified as a candidate for community contribution. If you're considering sending a PR for this issue, look for the Summary Comment link in the issue description. That comment has been left by an engineer on our team to help you get started with handling this issue. You can learn more about our Help Wanted process here

[mikekistler]

The proposal to add an option for permanent lockout seems like the better choice.

[bgi-jerry-king]

The proposal to add an option for permanent lockout seems like the better choice.

I don't disagree that that wouod be morr clear, but that still leaves the door open for unexpected runtime overflow exceptions of someone does happen to specify a large DefaultLockoutTimeSpan.

I feel as though both changes probably should be made.