1) Do not limit the length of the password to some arbitrarily small number.
2) Do not validate email beyond the simplest, "includes an @ and a period. Email is validated by sending a confirmation link.
3) Don't get so stupid with the "secure password" special character crap. Some of us use super long, but memorable passwords, which are more secure than your bull#@!+&$
I think in general the advice is that there should not be any limitations on special characters anywhere in the tech stack at all. (Including a broken UI that won't let you input special characters.)
The situation you described sounds more to me like a very poorly written application.
Sharing details, as many “sacred cows” are slain:
- User-generated passwords should be at least 8 characters in length
- Machine-generated passwords should be at least 6 characters in length
- Users should be able to create passwords up to at least 64 characters
- All ASCII/Unicode characters should be allowed, including emojis and spaces
- Stored passwords should be hashed and salted, and never truncated
- Prospective passwords should be compared against password breach databases and rejected if there’s a match
- Passwords should not expire
- Users should be prevented from using sequential (ex. “1234”) or repeated (ex. “aaaa”) characters
- Two-factor authentication (2FA) should not use SMS for codes
- Knowledge-based authentication (KBA), such as “What was the name of your first pet?”, should not be used
- Users should be allowed 10 failed password attempts before being locked out of a system or service
- Passwords should not have hints
- Complexity requirements should not be used, ex. requiring special characters, numbers, uppercase, etc.
- Context-specific words, such as the name of the service, the user’s username, etc. should not be permitted
- Users should be prevented from using sequential (ex. “1234”) or repeated (ex. “aaaa”) characters
This one can be counterproductive for the same reasons as the complexity requirements that this list prohibits. It reduces the space of available passwords and might block a strong but memorable password that coincidentally has an invalid subsequence somewhere in it.
- Two-factor authentication (2FA) should not use SMS for codes
This has its problems but depending on the situation you might have few alternatives available and some form of 2FA might still be much better than none. Apparently my government, my bank, and several well-known online services all share this view.
Most likely, the bank is doing it wrong because of bad old policies and lack of security education in the security and risk groups. The well known online services use your number to tie to data broker feeds. Not sure about your government, but likely inertia and misinformation.
Disclosure/disclaimer: megabank CTO opinions are my own
As of today, probably 3/4 or more of the online services I use that have serious security requirements are favouring SMS-based 2FA over just using ID and password as they used to. This can get a bit annoying, but it's obviously more secure than not doing it.
I got bit by this recently.
I decided to update my Bank of America password, and so generated a 30-character password.
Bank of America's password change page accepted the 30 character password. But then I couldn't log in because Bank of America's login page won't allow passwords longer than 20 characters.
I ended up having to call Bank of America on the phone and the rude web site tech guy said that he's been there 10 years, and 20 characters has always been the limit.
1 - If that's true, then don't let me change my password to 30 characters.
2 - Why would a bank insist on a password scheme that is clearly LESS secure than a reasonable alternative.
Full stop. Require email confirmation to complete signup. If the address can receive email, it's valid, it doesn't matter what's in it.
Periods are not required, either!
On the other hand, while it's definitely feasible to take a wordlist and make random permutations of sticking words together, I think in general that sort of password is used less often.
100% Agree password managers are the way to go, but for people that aren't using them I would definitely suggest long/multiple random words together over short LEETspeek with special char number tacked onto the end style password.
https://github.com/NotSoSecure/password_cracking_rules https://github.com/praetorian-inc/Hob0Rules
We're excited for other factors to gain more prominence (e.g TOTP, face id, touch id), but in the current world it's hard to recommend against a password factor, as long as you're following NIST guidelines to compare against password breach corpuses.