There is a subtle valid use-case. On "change your password" screens, you don't want the second "confirm password" field to be pastle-able to stop this scenario. 1) User tries to type "mypassword" but enters "mypasswor" instead. 2) User copy-pastes "mypasswor" into "confirm password field" 3) User hits "submit". Now when the user tries to login with "mypassword" it fails.
Let them paste passwords
131–140 of 376 posts
Re: Let them paste passwords
#132There is a subtle valid use-case. On "change your password" screens, you don't want the second "confirm password" field to be pastle-able to stop this scenario. 1) User tries to type "mypassword" but enters "mypasswor" instead. 2) User copy-pastes "mypasswor" into "confirm password field" 3) User hits "submit". Now when the user tries to login with "mypassword" it fails.
It's a shame that password managers are mostly used by tech savvy people, as they are probably the most secure way to deal with passwords we've come up with so far.
Re: Let them paste passwords
#133Earlier quoted context omitted.
I hate hidden passwords, it's stupid. I'd notice someone shoulder surfing so I'd prefer if they wheren't starred out by default with starring out as an option if I do have people around.
What about e.g. sharing a screen during a presentation?
Re: Let them paste passwords
#134Everyone's talking about password at sign-in or credit card numbers but that's not the only use case for paste restriction. The more common place I've seen it is email address confirmation (or PW confirmation), which while probably unnecessary, is not the worst thing in the world. You are retyping an address that's displayed in the field above. Less intrusive than a captcha.
Blocking pasting in a password confirmation input accomplishes nothing because you're already blocked from copying the contents of the first password input anyways. All it does is inconvenience people who use password managers.
Re: Let them paste passwords
#135Of course it reduces security. It makes you resort to either 1.) typing it out manually while you can't see if you made a mistake 2.) using developer tools to set the 'value' attribute directly "SPP" discourages use of a password manager. End of story. I also see this pattern used on banking websites for inputs like an account number. This drives me crazy as well for the same reason. The computer can get it right mor…
Re: Let them paste passwords
#136There is a subtle valid use-case. On "change your password" screens, you don't want the second "confirm password" field to be pastle-able to stop this scenario. 1) User tries to type "mypassword" but enters "mypasswor" instead. 2) User copy-pastes "mypasswor" into "confirm password field" 3) User hits "submit". Now when the user tries to login with "mypassword" it fails.
Re: Let them paste passwords
#137There is a subtle valid use-case. On "change your password" screens, you don't want the second "confirm password" field to be pastle-able to stop this scenario. 1) User tries to type "mypassword" but enters "mypasswor" instead. 2) User copy-pastes "mypasswor" into "confirm password field" 3) User hits "submit". Now when the user tries to login with "mypassword" it fails.
When changing your password, if you're pasting at all, it's from another (presumably correct) source -- so pasting is fine, whether once or twice.
Re: Let them paste passwords
#138Earlier quoted context omitted.
Other signs that a site was built by incompetent developers (Or had too much management interference--Devs aren't always to blame!): Only works with Internet Explorer Doesn't work with Internet Explorer Password must have one of 4-10 special characters, but not other special characters. (e.g.: Must contain !, @, ^, &, or parentheses, but not ;, ", etc) Passwords have no requirements Right-click is disabled Video play…
I agree with all your points except slideshows. Why so much hate against slideshows ?
Re: Let them paste passwords
#139Another annoyance is having to enter 2nd,4th,7th etc letter of the password using a dropdown. ARrrgh.
Re: Let them paste passwords
#140There is a subtle valid use-case. On "change your password" screens, you don't want the second "confirm password" field to be pastle-able to stop this scenario. 1) User tries to type "mypassword" but enters "mypasswor" instead. 2) User copy-pastes "mypasswor" into "confirm password field" 3) User hits "submit". Now when the user tries to login with "mypassword" it fails.