I absolutely do. It's not that the password was wrong. It's that they wanted to invalidate all existing passwords and make you change it.
The easiest way to do that is for them to force everyone through the "forgot password" workflow. Zero or minimal code changes. They don't want to make a new, but very similar , "we had a security breach and are requiring you to change your password" workflow. They just don't care that they're blaming you for their problem.
We require our users use a password that is in between 8 and 14 characters, contains more than 2, but not exceeding 4 special characters, and at least 3 uppercase letters, 3 numbers with 0 repeating digits.
And while requiring special characters, they only allow some special characters. So you just turn off special characters in the generator and then add an exclamation mark at the end
Try to reset password by auto-filling a new one from my password manager
New password set successfully! Yay!
Try to login again… fail. Wrong password… fucking what…?
Realize that their password field was clipping the password length off at some max length not fucking mentioned anywhere, so I have no clue what the actual password is without trial-and-erroring, which then results in an account lockout again
I’m a programmer and this kind of blatant stupidity from massive companies pisses me off to no end. MAKE YOUR PASSWORD REQUIREMENTS CLEAR. MAKE YOUR UX CLEAR.
Fucking Spotify. Tried to reset my password - 'There is no record of this email address'
Tried to make new account with same email - 'You cannot create a new account with an existing email'
:|
More likely it's happening because the password change field silently truncates your input and the login field doesn't, or vise-versa, because whoever designed the web page or system is stupid.
That is a possibility. But then actually setting a completely new password shouldn't work, yes? Because when you go to use it, it won't work.
I doubt that's the "more likely" scenario.
Tons of people have reset a login more than once, and then forget, which is what leads to this scenario.
When they forget the new password, but re-remember a previous one, they try to use it to log in. When that fails, they go to reset it again, and they try to set it back to the password they remember. Which doesn't work, because it is a previous password. But at the same time it is also not the current one.
The supposed catch 22 is that if it can't be their new password, it should work to log in. And if it can't be used to log in, then they should be able to set it as their password.
In reality the password has already been used, but before a previous reset. So it is neither a valid new password, nor the current password. This does not occur to people.
This can happen in any correctly configured service that prevents password re-use, and is therefore the far more likely scenario.