In password security, the longer the better. With a password manager, using more than 24 characters is simple. Unless, of course, the secure password is not accepted due to its length. (In this case, through STOVE.)
Possibly indicating cleartext storage of a limited field (which is an absolute no-go), or suboptimal or lacking security practices.
Don’t worry, pretty soon they will just block password managers from autofilling fields on their login page so that you HAVE to remember your password! Then you’ll be happy it can’t be that long, you can only fit so much on a post-it note on the side of your monitor
/s
EDIT: I think there should be a law against blocking password managers for filling in fields. Any brute force bots are going to submit HTTP requests directly anyway; no one is hitting the DOM to do that
I’ve never heard of anyone trying to do that. I couldn’t even imagine how a website could detect a password manager.
I’ve had banks do it in the past. It’s not that they can “detect” the password manager, they just use a method that’s incompatible with them.
They have a fake input field and capture keypress events via JavaScript directly from the dom, then just make it look like you typed in to the input field. They don’t read the password from the input field, they build it up in memory from those key press events.
It also completely breaks accessibility software, which is the main reason I think the industry moved away from doing it for the most part.
I’ve seen a couple of times. It’s the same ones that block copy/paste on password fields. The workaround is to write a short python script using pyautogui or similar to “type” out the clipboard content.