isLockedOut migration /2 (#28150)
* isLockedOut migration /2 * isLockedOut migration /2 * isLockedOut migration /2 * isLockedOut migration /2pull/28275/head
parent
b1369790a9
commit
6255e836ce
|
@ -71,6 +71,12 @@ There are subtle differences in the table structures and fields for both Members
|
||||||
| `PhoneNumber` | `string`| `aspnet_Users.MobileAlias` | `string` |
|
| `PhoneNumber` | `string`| `aspnet_Users.MobileAlias` | `string` |
|
||||||
| `LockoutEnabled` | `bit` | `aspnet_Membership.IsLockedOut` | `bit` |
|
| `LockoutEnabled` | `bit` | `aspnet_Membership.IsLockedOut` | `bit` |
|
||||||
|
|
||||||
|
`IsLockedOut` doesn't map to `LockoutEnabled`. `IsLockedOut` is set if a user had too many failed logins and is locked out for a set time. `LockoutEnabled` enables locking out a user with too many failed sign in attempts. When the user has too many failed sign in attempts, `LockoutEnd` is set to a date in the future, and the user can't sign in until that date. If `LockoutEnabled` is false then a user is never locked out for too many failed sign in attempts. Per [OWASP](https://owasp.org/www-community/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies), *Temporary account lockout after several failed attempts is too simple of a target for DoS attacks against legitimate users*.
|
||||||
|
|
||||||
|
For more information on lock out, see [OWASP Testing for Weak Lock Out Mechanism](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism).
|
||||||
|
|
||||||
|
Apps migrating to Identity that wish to enable failed login lockout should set `LockoutEnabled` to true as part of the migration.
|
||||||
|
|
||||||
> [!NOTE]
|
> [!NOTE]
|
||||||
> Not all the field mappings resemble one-to-one relationships from Membership to ASP.NET Core Identity. The preceding table takes the default Membership User schema and maps it to the ASP.NET Core Identity schema. Any other custom fields that were used for Membership need to be mapped manually. In this mapping, there's no map for passwords, as both password criteria and password salts don't migrate between the two. **It's recommended to leave the password as null and to ask users to reset their passwords.** In ASP.NET Core Identity, `LockoutEnd` should be set to some date in the future if the user is locked out. This is shown in the migration script.
|
> Not all the field mappings resemble one-to-one relationships from Membership to ASP.NET Core Identity. The preceding table takes the default Membership User schema and maps it to the ASP.NET Core Identity schema. Any other custom fields that were used for Membership need to be mapped manually. In this mapping, there's no map for passwords, as both password criteria and password salts don't migrate between the two. **It's recommended to leave the password as null and to ask users to reset their passwords.** In ASP.NET Core Identity, `LockoutEnd` should be set to some date in the future if the user is locked out. This is shown in the migration script.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue