By default, Narmi does not implement permanent blocks based on a number of failed login attempts because it provides a vector for denial of service (DoS) attacks by malicious actors. Instead, we implement rate limiting, which is a strategy for limiting requests to prevent malicious activity. We also allow financial institutions to set custom risk rules to lock an account after a certain number of failed logins, should you choose to do so. For more information on the DoS risks of selecting the account lock-out option, please see Denial of Service (Dos) Risk below.
Rate Limiting
Rate limiting puts a cap on how often someone can repeat an action within a certain timeframe, for instance, when trying to log in to an account. Rate limiting can help stop malicious bot activity and reduce strain on web servers.
Rate limiting looks at several factors, but generally limits users to the lesser of:
6 incorrect attempts in 60 seconds block further attempts
22 incorrect attempts in 512 seconds (8.5 minutes) block further attempts
30 incorrect attempts in 4,096 seconds (1 hour 8 minutes) block further attempts
46 incorrect attempts in 32,768 seconds (9 hours 6 minutes) block further attempts
58 incorrect attempts in 262,144 seconds (3 days 49 minutes) block further attempts
Rate-limiting is calculated on a rolling basis. That means when six login attempts have occurred in the same minute, these attempts start clearing in the order that they happened, not all at once. As time passes, the number of login attempts will fall beneath the limit threshold, allowing the user to log in again. It's important to note that by default, rate limiting only blocks users from logging in temporarily. Once they drop beneath the threshold, their accounts will behave as normal. Additionally, while rate limiting prevents login attempts, it does not prevent other behaviors, such as resetting a password. That is, if someone gets rate limited from trying too many passwords, they will not be prevented from resetting their password and using the new password once they are no longer rate limited.
Rate-limiting happens on a per-user level, so the system will know the user is being rate-limited regardless of platform, browser, IP address, etc. Once the user is rate-limited, they receive an onscreen message directing them to contact support or go to the home page.
Risk Rules for Failed Logins
Denial of Service (DoS) Risk
A Denial of Service (DoS) attack is a form of cyberattack in which a malicious actor aims to make a device or network resource unavailable to its intended users.
By default, Narmi does not implement permanent blocks based on a number of failed login attempts because it provides a vector for DoS attacks by malicious actors, gives limited protection compared to using a rate-limiting strategy as described above, and is a poor user experience.
Users that are locked will receive a generic error that their credentials are incorrect when attempting to login and will only be able to unlock their user by contacting the financial institution support team.
If a risk rule for failed logins is added, Narmi highly recommends using a threshold of 100 failed login attempts as it conforms to NIST guidance while limiting the likelihood of false positives.
If your financial institution would like a user to be locked rather than just temporarily blocked, you can set risk rules. For example, you can opt to add a User rule that locks an account after a specific number of failed logins in one day. If a user is locked due to a risk rule, any action they make in Narmi Banking immediately following the lock directs them to the login screen. Attempts to log in will result in a generic error that their credentials are incorrect. Only a staff user with permission to unlock a user can give the user access.
Note: Unlocking a user does not reset the number of failed login attempts that trigger a risk rule.
To set up a risk rule for failed login attempts:
From Narmi Command, select Configurations > Risk manager > Add rule.
On the page that appears:
Select User Rule.
Add a Description of the rule for your staff.
Select Add condition and choose a condition from the menu. This example uses Failed login velocity (day), but you can select the option for week or month instead.
Select the operator greater than or equal to, and enter the desired number of login attempts. For this example, we enter 5.
Select Add action and choose Lock user from the menu.
Select Submit to save the rule.
For step by step instructions on setting up risk rules, as well as a full list of conditions, go to Risk Manager.