Should a mobile banking app force clients to change their password periodically, e.g. every 3 months?

Question

Is there an internet bank that forces users to change their passwords periodically?

In Poland, none of the banks forces a change of the password for Internet banking. Of course, banks educate and suggest changing the password every month, for example, but the user is not forced to do so.

Should my banking app force a password expiry to better protect my user's accounts?

Answer 1

The bottom line is: if you are subject to a standards body, follow their guidance. If not, do a security threat assessment.

For instance, government agencies under the US Department of Commerce must, by law, follow the NIST's Digital Identity Guidelines, SP 800-63. For our discussion, the important document is SP 800-63B, covering authentication and lifecycle management. However, if you're processing payment card information directly, then the standard to follow is the Payment Card Industry Data Security Standards (PCI DSS).

Highlights from the NIST standards:

• 8 characters minimum
• All printing characters in ASCII and Unicode accepted (Support UTF-8)
• Smallest allowed maximum length is 64 characters
• No password hints
• No previously leaked passwords, dictionary words, repetitive or sequential characters, or context-specific words (such as their username again). (Half a billion previously leaked passwords are available for download at Pwned Passwords, or can be checked without leaking your user' desired passwords with the Pwned Passwords API)
• Rate limit failed authentication on a host (unique IP address) AND account level
• Do not impose rules that force multiple character types (i.e., requiring lower case, upper case, numbers, and symbols). (As above, you must still accept multiple character types.)
• Do not require passwords to be changed arbitrarily, such as periodically
• Require passwords to be changed if there is evidence of compromise
• Permit users to paste passwords (encourages use of password managers)
• Allow the user the option (but not default) to display their passwords in plaintext while entering it
• Use an encrypted channel (such as TLS)
• Store passwords in a salted and hashed form using a one-way key derivation function. (That is, it's not just SHA-256. At a minimum, something like PBKDF2 or better (Balloon, bcrypt, Argon2, etc.))
• Salt will be at least 32 bits, generated using a cryptographically secure PRNG, and will be unique to each password.

Many of these requirements are in direct conflict with the PCI standards. If you handle payment card information directly (that is, any of your customer service representatives handle credit/debit cards over the phone), then the system that they use to handle those payments has a whole different set of requirements.

Highlights of the PCI standard are:

• 7 characters minimum
• Force multiple character types in the same password
• Change passwords every 90 days
• Can not re-use the last 4 passwords
• Users can not set their first password, nor the password immediately after a reset
• Passwords must be changed when entering a first or reset password
• Accounts locked for at least 30 minutes or until an admin resets the lock if authentication fails 6 times
• Sessions expire after 15 minutes of idle time
• Use an encrypted channel (such as TLS)

Further, the NIST standards state that you should use 2-factor authentication wherever it's possible, such as the Time-based One Time Password standard (a.k.a., Google Authenticator), printable sheets of single-use tokens, and U2F devices that perform cryptography inside a device like a USB stick.

If you're neither an employee of the US federal government nor handling payment cards directly, and there are no standards bodies that have rules specific to your country, your industry, or practices that your company is using, then you need to do a security threat assessment, including cost/benefit analysis, and design your authentication system around that.

Your conclusions may likely be different from mine. I personally follow the NIST standards as much as it makes sense. I found it very low cost and low risk to use the Pwned Passwords API to let my users know if they used a previously leaked password. However, unlike the NIST standards, I do allow my users to have a previously leaked password, showing a message stating that the password was successfully changed, but that it had been included in X number of data breaches in the past and may be used by hackers in the future. I use the message as an opportunity to raise awareness of the dangers of password reuse, introduce the concept of password managers generating truly random passwords, and I get to show off my Yubikey U2F dongle. I have the luxury of being face-to-face with most of my users, though.

Answer 2

I'd like to summarize the discussion in comments.

The answer is no: a mobile banking app doesn't force clients to change the password and don't have to do this.

In this forum, the changing password periodically as good practice was discussed a lot of time. Mobile banking app is the same as any other web services. The fact is that changing a password is rescinded for a while now. So, it is more secure for users through suggesting they use password manager generated random passwords, and making 2FA: the Google Authenticator app, U2F USB keys, and one-time-use printable recovery tokens.