Authentication vulnerabilities such as weak passwords or poor implementation can leave digital accounts susceptible to takeovers, breaches, and malicious attacks. We aim to provide the most secure banking experience for your financial institution and your users by implementing Django's built-in authentication framework in conjunction with two-factor authentication and rate limiting. For Symitar customers, we also support using the Symitar core as an authentication source. This can aid in a seamless user conversion when the previous digital banking provider stores the username and password on Symitar.
This article describes password security, failed login attempts, and two-factor authentication.
In this article:
During Digital Banking enrollment, users must create a username and password to access their account. This section describes the requirements and password validators we use to ensure the creation of strong passwords.
Username and Password Requirements
Usernames must be less than 150 characters and may contain letters, numbers, or any of the following special characters: _, @, +, ., -. Usernames are not case sensitive. User passwords can be 4,096 characters or fewer. The minimum password length can be configured by the financial institution, but we highly recommend a minimum password length of at least 10 characters.
By default, we apply the following password validators:
- User similarity – Ensures that the password is not too similar to the user's username, first name, last name, or email
- Common password – Ensures that the password is not in the 20,000 most common passwords
- Numeric password – Ensures that the password is not entirely numeric
Each password validator provides help text to explain the requirements to the user, validates a given password, and returns an error message if it does not meet the requirements.
Additional Password Conditions
Each financial institution has the ability to set their own requirements for the parameters below. Minimum requirements can be set for each character that is expected to occur within a password.
- Password number minimum – Validates whether the password meets the minimum amount of numbers required during the password generation
- Password uppercase letter minimum – Validates whether the password meets the minimum amount of uppercase letters required during the password generation
- Password lowercase minimum – Validates whether the password meets the minimum amount of lowercase letters required during the password generation
- Password symbol minimum – Validates whether the password meets the minimum amount of symbols required during the password generation
Note: There is no default expiration of a user's password. We do not prompt users to change their passwords after a given amount of days.
Failed Login Attempts
Narmi does not set default limits on failed password attempts. However, we implement rate limiting, which is a strategy for limiting network traffic to prevent malicious activity, and we also allow financial institutions to set custom risk rules to lock an account after a certain number of failed logins.
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 blocks further attempts
- 22 incorrect attempts in 512 seconds (8.5 minutes) blocks further attempts
- 30 incorrect attempts in 4,096 seconds (1 hour 8 minutes) blocks further attempts
- 46 incorrect attempts in 32,768 seconds (9 hours 6 minutes) blocks 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 intemporarily. Once they drop beneath the threshold, their accounts will behave as normal. Additionally, while rate limiting prevents login attempts, it does not prevent other behavior, 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-account 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
If your financial institution would like an account 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 Digital Banking immediately following the lock directs them to the login screen.
To set up a risk rule for failed login attempts:
1. From the Admin Platform, select the cog wheel menu, then select Manage Risk Settings.
2. On the page that appears, select the plus sign to create a new rule.
3. In the dialog that appears:
- Select User Rule.
- Add a Description of the rule.
- Select the Condition – This example uses Failed Login Velocity Day, but you can select the option for Week or Month instead.
- Use the operator Greater Than Or Equal To, and enter the desired number of login attempts in the text box.
- From the Action menu, select Lock User.
Select Submit to save.
For step by step instructions on setting up risk rules, as well as a full list of conditions, go to Manage Risk Settings.
Two-factor authentication (2FA) is an extra layer of security where a trusted device is used to ensure that only you are accessing your account, even if someone else knows your password. 2FA is set up when enrolling in an Digital Banking account, where you specify a trusted email address, phone number, or authentication app (such as Google Authenticator) to receive verification codes. Each time you log in to your Digital Banking account, a verification code is sent to your trusted device. You enter that code in the Verification code box provided to complete verification. If you do not receive the code, you can select Resend code to have the code sent to your trusted device again.
There are four types of authentication methods that can be configured by a user within the Alerts & Security settings of their account. The authentication methods shown are configurable by your financial institution in the Admin Platform under Institution Settings > Permitted Two-factor Authentication Methods. For example, you can choose to remove the email authentication method.
- Email – A verification code will be sent to the user's email upon logging in. This is the default method for authenticating users.
- Phone (text or landline) – A verification code is delivered via Short Message Service (SMS) for mobile numbers or a voice call for landline numbers. Texts will include the financial institution short name for additional security and a better user experience. Only U.S. phone numbers are supported. Those without access to a U.S. phone number can use a time-based one-time password (TOTP) app, like Google Authenticator.
- TOTP App – Users can enter verification codes generated by time-based one-time password (TOTP) apps, such as Google Authenticator, Duo Mobile, or Microsoft Authenticator.
- Recovery Codes – Recovery codes are for users who don't have access to any of their enabled devices and can't receive a two-factor authentication code. The recovery codes should be stored in a safe and secure location.
To access the authentication settings on a web browser:
1. Select the name in the upper right corner, then select Settings.
- In the Alerts & Security section, select More.
3. Scroll to the two-factor authentication section.
Add authentication method allows users to add a TOTP app, a phone number, or their default email address to receive verification codes.
An app on your phone – Use this method to enter verification codes generated by time-based one-time password (TOTP) apps, such as Google Authenticator, Duo Mobile, or Microsoft Authenticator. Users can scan the QR code that appears, enter the code generated by the app, and select Enable.
Text or landline – Use this method to receive verification codes by SMS text or voice call. Enter a U.S. number and select Verify now. Enter the code received and select Activate.
- Your email address – Use this method to receive verification codes at the email address on file. Select Verify now, enter the code sent to the email address, and select Activate.
When users cannot access any of their enabled devices and can't receive a two-factor authentication code, they can select Add recovery codes to get backup codes. Select Activate these codes to start using them. The recovery codes should be stored in a safe and secure location.