Closed jmmcnj closed 6 years ago
Is this not a part of the date and time login and out audit capture?
We are using the OOTB Asp.Net Identity account lockout functionality. It can be configured with the following app settings DefaultAccountLockoutTimeSpan (default true), MaxFailedAccessAttemptsBeforeLockout (default 3), DefaultAccountLockoutTimeSpan (default 15 minutes). For security we do not indicate the account is locked out, only that the login was invalid.
Based on Matt's description of the capability provided by the information system, this item can be closed.
closing based on DOLs decision
we need to revisit this user story.
We are likely to continue with existing MS identity implementation till OCIO IAM is ready. 1) Account lockout needs to be implemented although it is supported by MS Identity framework. https://stackoverflow.com/questions/37020774/implementing-the-microsoft-aspnet-identity-iuserlockoutstore 2) Logging of unsuccessful attempts needs to be implemented. https://stackoverflow.com/questions/27296595/mvc-asp-net-identity-howto-log-to-db-when-user-logs-in
Story to be reopened.
Ensure all the settings mentioned above have been implemented and configured (in .config file). In addition, take a look at these two links below, and ensure functionality as documented in links is implemented (w w/o using code in the links) Think through 2FA and lockout related issues:
Lockout: https://stackoverflow.com/questions/20803109/asp-net-identity-disable-user
MVC 5 release notes for 2fa + lockout: https://blogs.msdn.microsoft.com/webdev/2014/08/05/announcing-rtm-of-asp-net-identity-2-1-0/
LockoutEndDate not populated in the DB - FYI to @dciceman
@mmurthydol tested this user story in QA site for 3 unsuccessful login.
I have also verified the activity being log in the correct table in database.
@EStriegel and @afrimpong : Business and security need to hash out the verbiage. Per our understanding: business verbiage implemented as above. Security likes verbiage to not include "for 15 minutes".
I'd guess any hackers probably already know the NIST/federal guidelines of 15 minutes anyways?
@EStriegel @phirefly Tested and it looks good, however, there is still some question from security about showing the 15 minutes in the message. please provide comment.
@binwang89 My preference is to include the 15 minutes language. Can you check with Harry?
Keeping 15 minute language, unless otherwise instructed by security. Moving to Done
Descripition: In Ref to NIST Control AC-7,UNSUCCESSFUL LOGIN ATTEMPTS () The information system: Enforces a limit of [Assignment: organization-defined number] consecutive invalid logon attempts by a user during a [Assignment: organization-defined time period]; and Automatically [Selection: locks the account/node for an [Assignment: organization-defined time period]; locks the account/node until released by an administrator; delays next logon prompt according to [Assignment: organization-defined delay algorithm]] when the maximum number of unsuccessful attempts is exceeded.
Further discussion with DOL Security Team discovered that the logging of unsuccessful attempts was less important than the lock on accounts after a certain number of attempts.
Discussion with AIS team concluded that lock out based on a certain amount of attempts was already a part of the identity managment framework selected for the project. It would be more effort though to implement the logging of successful attempts, not a huge effort but an additional effort nonetheless.
Tasks:
TODO WHD DIT provide security clarifications on frequency/numbers for the lockout logic
Acceptance Criteria: Existing User who is not logged in, attempts to log in a certain amount of attempts with incorrect passwords and is locked out from accessing their account and needs an Administrator to unlock the account, prompt to user then displays a call in/email for DOL 14c administrator Considerations: