Furthermore many sites make it difficult to use a password manager because it's hard to block automated password guessers and not interfere with password managers trying to enter passwords.
My old bank used to "encrypt" your password as you typed it into the input field, on keydown it would take the character you typed and — and I'm not making this up — ROT13 it. This had the effect of making it impossible to paste anything into the input field since the script would capture your ctrl+v and replace it with the letter "i".
The icing on the cake is that when I called to complain about it, the support agent insisted in very sombre tones that it was a measure to stop keyloggers. I don't use that bank any more.
The only problem with that is that the stupid ROT13 step wouldn't be performed so the site would reject your login attempt anyway. It was one of the dumbest design decisions I've ever seen, honestly.
I'm guessing the solution would've then been to 1) disable the update event and 2) paste the ROT13'd password, either into the browser or into the input field value via the inspector.
Like you, whenever I run into sites that do weird things like that, I always find it hard to shake a bit of suspicion about how their backend is implemented (or not, depending on the case). For instance, when they start rejecting characters like "%" or "'" which have special meaning in SQL. I can't help but wonder if they're storing things in plain text.
I've run into at least two vendors I can think off the top of my head that limit what characters you can use for a password. That always makes me uneasy, and I don't buy anything from them on principle. Who knows what else they're doing that's not immediately obvious.
My guess is if you did that and pasted "password" you would get "passworq" and then your password would be wrong according to their "encryption" method.
This reminds me of the time I was trying to explain to the Verizon store rep why I was concerned that my SIM suddenly went offline, and they told me "Oh hun, nobody steals a phone number!"
The web developers that think like this are bad at web development, and likely security. Why would anyone trying to brute force your authentication portal care about using your UI?
This is giving me bad ideas about making the UI (and only way to log in) be to send the password 1 character at a time as it's typed, and then using some form of ml to try and identify probable bots.
You'd probably mostly catch password managers and people copy-pasting passwords though. If you had per-user fingerprints also people typing on a new device...
I’m pretty sure that would be unmanageable, but love to see it tried..
Are you thinking of each character acting more like a number in a combination lock and needing to be provided to the app sequentially to be checked? I dont get how you distinguish between password managers and bots or API dictionary attacks on the same interface?
>This is giving me bad ideas about making the UI (and only way to log in) be to send the password 1 character at a time as it's typed, and then using some form of ml to try and identify probable bots.
at that point you might as well outsource that sort of fingerprinting/behavior analysis to some service like recaptcha.
Sounds like a great way to create a huge security flaw for your users and their passwords, or a nifty method by which your attackers can DoS your site.
The icing on the cake is that when I called to complain about it, the support agent insisted in very sombre tones that it was a measure to stop keyloggers. I don't use that bank any more.