The “Cobra Effect” that is disabling paste on password fields

Post by Frank2312 » Mon, Jun 27, 2016, 12:42 PM UTC

foxylad wrote: post #369

MRSallee wrote: post #317

I doubt that the motivation for preventing paste in a "confirm password" context is to prevent workarounds to character limits. Why does the "confirm password" field exist anyway? It exists to remove the risk of input error. They want to avoid you locking into a mistyped password and not being able to recover. To this end, it makes some sense to prevent copy/paste, as a user may simply copy their mistyped password an…

This raises the interesting question of why we obscure the input when changing passwords. Showing the new password would allow people to check and correct it, so you'd only need one input. Given that the contents of a password input can easily be revealed, the only security obscuring the input provides is from an attacker who can see the screen but not the keyboard, and has no physical access to the device - a pretty…

Post by CiPHPerCoder » Mon, Jun 27, 2016, 1:09 PM UTC

ianferrel wrote: post #339

jameshart wrote: post #322

Earlier quoted context omitted.

It seems astonishing to me to attempt to include in your threat model "login must be secure even on a system which has malware on it". If a system is infected with a keylogger, the LAST thing you want to do is allow the client to log in.

How would you prevent a client from logging in from an infected system?

Post by AlexandrB » Mon, Jun 27, 2016, 1:15 PM UTC

foz wrote: post #100

I believe that copy and paste is needed in login forms, as a UX expectation. Typing a secure random password is really painfully hard, especially on mobile. Sometimes password managers don't recognize the target form fields correctly, so copy/paste is the next step. The act is even encouraged through the use of convenient helper buttons in the password managers. However. In MacOs Sierra, Apple will introduce the Univ…

Post by chrisweekly » Mon, Jun 27, 2016, 1:31 PM UTC

Post by Vexs » Mon, Jun 27, 2016, 2:16 PM UTC

GhotiFish wrote: post #356

pierrec wrote: post #186

Earlier quoted context omitted.

It's a ridiculous practice and storing the passwords in plaintext is deplorable. Banks have your phone number, (which can't simply be changed online) and that is the best additional line of security. The scrambled on-screen keyboard / n-th character request only poorly "protects" against cases where the attacker has full root access to the customer's machine (how would it protect against phishing?), and in those case…

you know. It occurs to me that you could actually do this without storing the password in plaintext! All you'd have to do is iterate every potential answer into a bloom filter and store that. The math gets a little hairy around the 50 character mark as you'd have 117600 operations to do to construct the bloom filter, and it gets worse if you expect more characters. Here's how you would construct it. For every 3 choos…