PLAN_003 Account lockout for user authentication

Description

Temporarily locking an account after multiple failed login attempts is a security measure to protect user accounts from unauthorized access. This practice helps prevent brute force attacks, where an attacker systematically tries a large number of password combinations to gain access to an account. By limiting the number of consecutive failed attempts, the system significantly reduces the chances of a successful breach, as the attacker would need to wait for the lockout period to expire before trying again, thereby slowing down their efforts considerably.

Furthermore, account lockout policies act as a deterrent against such attacks. Knowing that repeated failures will lead to a temporary lock, attackers are less likely to target accounts with this protection, shifting their focus to less secure systems.

In addition to security, account lockouts can also alert users to potential unauthorized access attempts. If a user experiences a lockout without having attempted to log in, it can prompt them to change their password and review their account activity for any suspicious behavior.

System requirements

No special hardware or software is required to run this test.

Preconditions

• The entire system (including the reverse proxy, REST API, and all upstream services) is deployed, operational, and accessible online.
• All communications with the REST API are conducted over HTTPS, either through a reverse proxy server or directly with the hosting server.

Input data

Since this test doesn't need real credentials for authentication, create your own input data. In other words, invent a username and password for the login process.

Steps

1. Attempt multiple login requests in a short time period with invalid credentials to trigger account lockout.
2. Observe the API response.

Expected outcome

• The system temporarily locks the account after multiple failed login attempts.
• The error message in the response clearly states that your account has been blocked because of too many failed attempts in a short time.

Verifies software requirements

• REQ_005

Risk control for

• 16. An organisation that is not a licensed care provider gets access to the device
• 17. Users outside the inteded user definition use the medical device
• 26. Data breach or unauthorized access

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Tester: JD-017, JD-009, JD-004
• Approver: JD-005