TL;DR - high confidence that a password not meeting the requirements was accepted during a master password update, now unable to log in to account (and the account recovery OTP was used to kick off the update...)
I was helping a user recover their account as they had forgotten their master password. I was present during the entire process, they had originally mismatched their new password field. I had them delete both fields and enter the new password again specifically to avoid the possibility of a repeated typo being submitted, and the user took their time to enter the new password in both fields this time. So, I'm highly confident the password submitted for the update was as intended by the user.
However, using the updated password fails to login. After several tries from the user, I had the user share the password with me to try myself and some variations of it (i.e. with caps on) without success. I verified that the update was successful, or atleast reported as such by LastPass, as a notification email alerting the user that their master password had been updated was received.
The part that has me scratching my head is that the password submitted (and apparently accepted) for the new master password does not meet 2 of the requirements. If it was just one, I could see a repeated typo possibly meeting the requirement and it then being accepted, but this password did not contain a special character nor a number. Additionally, the only 2 of the characters neighbor a 'shift' key, and 4 of them are in the top row next to a numeric key. More so, none of the keys neighboring a numeric key follow a character neighboring a shift key, so it's hard to see how a typo leading to a special character would happen once, let alone in both fields for the new password.
Now, as is my understanding, the account recovery token/OTP is not generated until after the first login. As we used the previous OTP to get to this point, and are unable to log in using the new password, we are unable to use the account recovery process. If we are to assume that the password was indeed accepted but contained some repeated type, we could possibly get lucky with trying some more variations. However, it also find it entirely possible there may exist a bug with validation on the front end not matching validation on the back end, potentially allowing for form submission and triggering the confirmation email, while failing to update the db. As to what state that would have left the actualy password field, I have no idea, though I did have the user try loging in using any/every password they may have used as a master password previously (for science I suppose I'll try a blank password in a moment).
So, any ideas on where to go from here? 😅
Thanks in advance for your time and help!
