(Not saying that simplifying several errors into one message is always bad. I think it's reasonable to just return a 500 without any info for everything that's caused by an unexpected exception on the backend.)
Most recent was setting a password for Rakuten Bank, saving it to my browser password manager, saving it to an offline password manager, and then two days later attempting to login and being told my password has too many characters. What.
It annoyed the hell out of me though when I was trying to put the required special character on the end of my too-long password after a required password change, and the only error message I got was that the special character was missing.
I worked for the online investment banking arm of one of the big Canadian banks a few years ago. Their passwords could only be eight characters long. At one point, I was tasked to do some work on their IVR system and discovered that your phone password was entered by pressing the corresponding letter key on your phone keypad. But they didn't say "2 for A, 22 for B, etc." which really confused me. How did it know the passwords were correct?
And that's when I had a terrifying realization and tested it out on the website - they weren't magically converting your phone presses into ascii characters. No, they were converting your password into the corresponding numerics and saving that. Every single user password was a 6-8-digit number.
They upgraded their whole login system around the time I left that company, including implementing 2FA. Though their 2FA was SMS-based rather than using an known authenticator app system, so it still wasn't perfect.
This sounds like an erronious error, ie the error message displayed is not the correct error message. There was definitely an error but the error was not that you tried the same password as your current.
I hate erronious errors with a vengance, because they not only break user workflow but they break helpdesk work flow as well then it gets escellated to an engineer who quite often cant fix the actual erronious error but knows what the actual issue is and fixes that anyway.. meaning the erronious error never gets fixed and will mow hang around to chew up everyones time all over again.
such a silly way to waste so much time, over and over.
What exactly is this based on?
I know I've seen that listed as a requirement (well, actually can't be one of the last 3) on some systems that have annoying password requirements.
You want some indication that any leak of your current password actually hasn't been mitigated. A failure message that your password hasn't actually changed (due to being identical) is functionally the same as allowing the password change and giving a warning that the passwords were identical (modulo some back-end details like if the password salt has changed and if the password change date has been updated).
For umlauts, restricting the amount of support calls from people abroad where the keyboard doesn't have them.
For others, particularly when mainframes or other truly old legacy systems are involved, encoding issues somewhere along the transport chain.
It is really hard to listen to any security recommendation from anyone in the industry when there are SO MANY bad password rules that restrict what actual good long passwords are. Length restrictions, restrictions on special characters or UTF-8, password rotation rules. These examples of bank logins at major banks absolutely blow my mind.
and is site-specific with some leetcode subs or a magic number suffix is about the strongest password for login and for long-term user security and usability.
Maybe in another 15 years the security people at corporations will get their act together?
Maybe sometime we'll get legislation with some actual teeth on login security?
Password managers usually are either password-protected themselves or have biometrics, which suffice to deter random thieves. In fact, password managers are not going to show your password in the first place, they are going to silently fill in password prompts. The password cannot be clipboard-stolen, screen captured, or key logged. It is even more difficult to fish you (if the password manager doesn't detect the right program id/URL, it won't fill your password in -- unlike you).
If someone is looking over your shoulder with a supercamera he can get one password. If you are using a password manager, that's it. If you were using "an algorithm" to derive your passwords it is now possible he can now easily guess ALL your passwords. Most people aren't that good remembering good "algorithms" anyway. Maybe he needs to capture two passwords to do so?
Unless your algorithm is truly good, in which case you likely have to store it somewhere and that becomes your "password manager", which shares the same cons as a password manager itself. You are even at risk of your "algorithm" being guessed through a couple big password DB leaks, which are sadly ridiculous common, and this by itself puts you more at risk than worrying about supercameras.
I however don't have anything good to say re password managers that sync passwords over a centralized service, or worse, do so without proven E2EE.
My favorite is:
1. I go to a website I haven’t used in a while but know I have an account on
2. I sign in with my email and what I’m sure is the right password for that site (algorithmically generated from site URL)
3. Password not valid
4. Ok, maybe this was an older version my my algorithm from way back
5. Password not valid
6. Fine, hit password reset
7. Get reset email and click it
8. Enter algorithmically generated password as new password
9. Error, can’t have that special character
10. Fine, per my rules, replace that special character with next one
11. Sorry, can’t reset password to your current password
12. Aaaaaargh.