← Authentication & security

2FA customer communication

Utilizing 2FA for Banno

It’s important your team is aware 2FA will be your biggest call driver at go live. End users who utilize modern apps are typically familiar with 2FA, but less experienced end users may struggle. To assist end users as best as possible, we suggest your customer/member care team be fully trained on Banno 2FA, utilize it themselves, and have the following information on this page.

The weakest point of protection for an end user is before they are signed up for 2FA. Once they activate 2FA it doesn’t matter what phone they use–—they are protected. We recommend minimizing the time frame between credentials being issued and 2FA enrollment. This is most vulnerable during a conversion.

The gap allows a malicious actor who knows a user’s credentials enrolling them in 2FA using a number that the attacker controls. To combat this, we email the user throughout this process at the following points:

  • New device sign in
  • 2FA enrollment
  • Other authentication changes

Even if a malicious actor manages to act during this gap, the end user will be notified immediately and can reach out to your institution for assistance.

For the few institutions that are uncomfortable with this gap, it’s possible to enable core validation to ensure the 2FA number matches the phone number logged in your core. Core validation helps prevent an attacker from enrolling an unknown number, but it causes two problems:

  • Cash management users don’t have phone numbers to validate against, so core validation will not work for them.
  • End users often have valid reasons for using a phone number that does not match what’s on the core, such as having only home numbers logged in the core.

Projects are in progress to add more 2FA options using authenticator apps. Authenticator apps and security keys don’t have an analogous option for core validation, so core validation is not compatible with those further 2FA options. See the public-facing roadmap for information on additional 2FA options.

End user experience

Enrollment

When end users login to Banno for the first time from any platform, they’ll have to enroll in 2FA. As part of the enrollment, ends users provide their email and phone number. Unless the end user selects their device to be remembered by Banno Online, the 2FA phone needs to be accessible each time they login. They’ll also have to choose between three methods of receiving the verification code. We recommend end users receive a text via a mobile phone, but they can also choose to receive a phone call via a landline or a verification code through the Authy app. If the user sets up a new phone number or enters the incorrect number, admins can reset 2FA for users within the permissions section of the Banno portal. Once the user has enrolled, they will not have to re-enroll unless they or the institution chooses to reset their 2FA.

Phone call verification

If the end user selects to receive a phone call instead of a text message, they’ll receive the verification code in the form of a robocall. The robocall provides a single digit for the end user to enter on the phone. Then the robocall provides a seven-digit verification code for the end user to enter in the Banno App (Online or Mobile) they’re using. If the end user doesn’t enter the initial single digit, the verification code isn’t given nor is it left on a voicemail system. If the end user doesn’t answer the robocall, they’ll have to select to have the code re-sent. The robocall phone number may be listed as coming from anywhere in the U.S., because the number pulls from a pool of numbers that Authy controls.

Reset enrollment

End users can reset their own 2FA enrollment in both Online and Mobile by going to the security settings in their profile page. The institution can also reset 2FA by navigating to the end user’s profile in Banno People, clicking Permissions, then scrolling to the bottom of the page and clicking Reset.

Codes

Doesn’t receive a code

If a care team receives a report of the user not receiving a code, it could be one of the following:

  • The main issue we see is the user requests receiving a code via SMS, but enters a landline number. If they report not receiving the code via SMS, and you’ve verified they’re not entering a landline number, instruct them to try another way and receive it via phone call.
  • If the user tries both methods to receive the code, reset and have them verify they entered the correct phone number.
  • If the phone number and method is correct, validate the user isn’t using a phone operating on a prepaid plan. Oftentimes, the money runs out and they no longer receive SMS until adding to the account balance.
  • The user reaches their max attempts. See the FAQ for more detail.
  • If all of the above is validated, the issue’s likely with the carrier.

Views an invalid code

A standard error return message will state, “Too many attempts. Try again later.” There are many reasons why end users might see invalid codes (or token errors). Below is a list common causes:

  • The most obvious reasons are typos (when retyping token codes) and expired tokens.
  • The device’s time isn’t synchronized with the server’s time. This occurs when end users travel. For example, end users need to ensure the device’s time is correct to fix the issue.
  • The account was reset.
  • For the Authy App: If a user resets the account within Authy, all Authy tokens produce invalid otps and the user needs to reinstall the Authy app to fix the issue.
  • End users removed their device. If a user removes a device, all Authy powered tokens from the removed device generate invalid otps. To fix this, the user reinstalls the Authy app.

These reasons might not be the source affecting your reported end users, but it’s a helpful reference.

In general, if the issue occurs inconsistently, we determine it’s a user error. However, if you see certain end users experiencing the issue more often, please direct them to Authy and include their phone numbers, emails and/or Authy ID. Authy happily investigates issues further.

Locked out

End users can lock themselves out of enrolling and verifying 2FA codes. The FAQ provides more details.

Switch profile

If an end user adds more profiles to their mobile app, they will need to set up 2FA for each of them. If the account has already enrolled in 2FA, they will need the verification code sent to that end user.

FAQ


Do we accept other country codes besides the U.S.?
Yes, we do, although core doesn’t support International numbers. Therefore, 2FA validation against core shouldn’t be enabled for institutions who have a lot of international end users. The user should validate with a U.S. number and then use the Authy app to change to an international one.
After a user receives an Authy code, how long is the code valid?
2FA tokens are generally valid for three to six minutes working around issues of time synchronization and drift. Tokens obtained using the app have a longer validity window for this reason, while SMS and voice requests are valid for exactly three minutes.
The user stops receiving SMS text after downloading Authy. How do they “disable” it so they receive texts?
If a user ever installed the Authy app and registered it with the same phone number as they enrolled in 2FA at Banno, no SMS sends unless the user selects “Try Another Way” and selects the SMS option. If the user wants to permanently stop using the Authy app and receive SMS codes again, the user completes this form and uninstalls Authy. They may also need their 2FA enrollment with Banno reset for them to register again.
What happens if the user uninstalls Authy?
Nothing will happen. Authy remembers phone numbers, although the user may need their 2FA enrollment with Banno reset so they can register again.
Can the user receive the code via email?
No, they can’t receive the code via email. According to NIST guidelines, which the FFIEC references regarding cybersecurity, email shouldn’t be used for out of band authentication.
What’s considered a high-risk action?
High-risk actions include the following:
  • Adding a bill payee
  • Adding an external transfer account
  • Changing the password
For high risk actions, why is a password required instead of receiving a 2FA code?
2FA is only used to log into the app. Re-entering the password provides an additional security mechanism. It helps ensure the authorized user utilizes the app and prevents an unauthorized user from hijacking an account.

Once logged into the app, using password entry prevents (for example) another individual who steals the user’s phone and attempts to create a payee. If they receive a 2FA code, the code comes to the very phone the unauthorized user’s on, and they create a new payee.

How can an institution investigate fraudulent activity with 2FA in play?
Examine the activity events in Banno People and find events initiating fraud—there’s quite a bit of data to review. Looking at the IP addresses and device information, compile information on the fraudulent user.

In most cases, the issue is one of the two following causes:

  • The authorized user gives away their 2FA code to someone else.
  • An unauthorized user gains direct access to the phone or device which generates the 2FA code and obtains it inappropriately.

We recommend the FI find the exact activity events initiating the fraud and discuss with the user, ensuring that neither of the above cases is true. If neither of the two causes occurred, we can help look into it further if needed. We’ve experienced occasions when end users told us they didn’t give away the code, but we later learned they did. However, it’s almost always one of the two causes above.

There are also fraud reporting features in Banno Reports:

  • Fraud report - potentially compromised end users
    • This report will indicate a user where a credential stuffing attacker may have correctly guessed the user’s password. 2FA is still in effect, but the account may warrant specific attention.
  • Fraud report - new end users with unverified 2FA enrollment
    • These are end users who enrolled in 2FA and the phone number they used is not on their core record. This report allows an FI to keep core validation turned off, but still manage the risk by reviewing these end users manually.
What if the user has too many invalid attempts and locked out?
  • If the user verifies five wrong tokens in a minute, an error returns with the message, “Too many attempts. Try again later.” The user can retry after five minutes.
  • If the user verifies 20 wrong tokens in a day, an error returns with the message, “Too many attempts. Try again later.” The user can retry after 24 hours.
  • There’s not a manual reset for unlocking an end user. After a suspended user reaches their retry time limit (five minutes or 24 hours), successfully verifying a token removes the suspension.
  • Removing a user from the application and adding them again doesn’t remove the suspension.
With core validation enabled on 2FA, which phone number do we validate against for CM end users?
This validates against the NTID CIF for the business. We generally don’t recommend this as it means all codes send to that one person, which is unmanageable. Upcoming Banno Business functionality will open up more options for core validation.

Additionally, we don’t recommend core validation specific for CM user validation or retail. We’ve seen more issues around this than the help/additional risk this protects. Many institutions see an influx around the core data not being current or correct, so they opt to disable.

A bank says there’s a long delay in getting the code via the automated voice call. End users think they didn’t receive it, but they didn’t wait long enough. Is that an issue you’re aware of?
When we experience this, it’s almost always a carrier issue and unfortunately outside our control.
A user logged in on their phone for the first time and successfully completed the 2FA process. They go home and log in on their laptop/desktop computer. Because they’re logging on a different device, will they go through the 2FA process again? OR will they log in using the new four digit PIN they already established on their phone?
The first time a user logins on each device, they’re prompted for 2FA. A user will be unable to enter their four digit pin into online banking and must use their username and password +2FA. A remember feature prevents the 2FA code from being required on each online login from the same device.
A user already logged in and completed the 2FA process on their phone and laptop. Using their login credentials, the user then logs in from their partner’s phone. Because it’s a new device, will the user go through 2FA again? Will it remember the three devices, so the user won’t run into that again as long as they log in from one of those devices?
The first time a user logins on each device, they’re prompted for 2FA. A remember feature prevents the 2FA code from being required on each online login from the same device.
A user uses their fingerprint or facial recognition to log in, and they forget their ID and password. When they first used the app, did they have to first complete the 2FA process in order to use biometrics? If so, where does Support reset and/or unlock the user’s NetTeller ID?
Before they set up biometrics, they authenticate for the first time with their credentials. You will reset/unlock end users the same as you do today with NT, because we’re using NT under the hood (NT BackOffice).
If a locked account doesn’t exist in Banno People, where is the account unlocked?
The account should be reset/unlocked via NetTeller BackOffice.