Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

troyhunt.com

Post reply on HN
Print view View original

41–50 of 450 posts

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

#41

Post by danjc »

lisivka wrote: post #19
fit2rule wrote: post #13

One reason to dissuade users from using the clipboard to paste passwords is this: the password stays in the clipboard. Not all users realize this, and so .. don't 'clear' the clipboard after logging in .. which means their password is still available to anyone else who might use that computer.

So, login form can just clear clipboard instead in onsubmit() handler.

That's an interesting idea actually. My first response was that you can't freely interact with the clipboard but you can set it provided you do it in response to a js event so in theory that is possible. The only problem is that you'd need to be sure the clipboard did actually contain the password because of course you can't read it. I guess you can log whether onpaste fired and then if the login button is clicked with a second or two, clear the clipboard.

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

#42

Post by morgante »

ioquatix wrote: post #36
morgante wrote: post #12

Earlier quoted context omitted.

That's still not a very good reason. If you're security conscious, you shouldn't be typing passwords at all. You should generate them from a password manager and paste them into the field both times. It boils down to security theater making us all less secure.

If you are security conscious at all, you'd be generating a public/private key pair for website authentication, only using HTTPS and potentially preferring TOR. I mean, a username+password field is SO FAR from good security practices, it's almost a joke.

I assume you're being farcical, but I would love if more sites offered authentication schemes beyond usernames and passwords.

These days, I will refuse to log in to any website which doesn't support https.

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

#43

Post by onion2k »

khattam wrote: post #16

>Sometimes you want to use the same credentials on multiple domains of the same service and auto-fill only works against the domain the pattern was recorded on. That's why you should use Lastpass.

That assumes the user has a choice. Many corporate environments don't let users install software so Lastpass isn't an option.

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

#44

Post by level3 »

limelight wrote: post #39
level3 wrote: post #31

Earlier quoted context omitted.

How is that a solution to the problem of user error (i.e. mistyping)? Are you making an implicit assumption about password manager use and mistyping, that somehow your heuristic will be able to differentiate? That seems like a lot of work for something that may be prone to mistakes, while also delivering an inconsistent user experience, for the sake of some (unstated) assumptions about security that may not be founde…

It actually makes a lot of sense. People will almost never manually type out high security (>20 random characters) passwords themselves. So if someone enters a high entropy password, you can fairly confident that mistyping is not an issue.

I'm not quit convinced about that.

1) Aren't there people using generators like Diceware that don't do the password management part?

2) The industry's definition of "high security" is constantly changing. Password strength measurement makes assumptions about what is and isn't guessable, and a lot of that depends on what techniques the common brute-force crackers are employing. So finding the right heuristic is also problematic.

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

#46

Post by ejcx »

I always assumed this anti-pasting was a requirement of some braindead auditor who insisted that this was a necessary security mechanism.

If they aren't, there's a lot of "debt" in the passwords space, like Troy mentions. This is just something that will get better as websites get better. Webapps are much more complicated today than 5 years ago, on average, and as complexity increases things like user auth will get better and more homogeneous. This is especially true if Google and Apple have their way with the Credential Management RFC and get people to have a reason to save their passwords with chrome.

"Passwords" are getting better but we need another 5 years to get us there.

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

#47

Post by onion2k »

dandelany wrote: post #33

Not that I think it's a good reason, but I think the rationale behind disabling paste is to prevent users from implementing their own "password managers" via a .txt file full of passwords on their Desktop (more common than you'd think).

I'd rather a user has a strong password that they paste from a file than a weak password they can type easily. If their machine is hacked then it's game over anyway. At least using a txt file of strong passwords means their account is secure if the online service is compromised.

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

#48

Post by danjc »

danjc wrote: post #41
lisivka wrote: post #19

Earlier quoted context omitted.

So, login form can just clear clipboard instead in onsubmit() handler.

That's an interesting idea actually. My first response was that you can't freely interact with the clipboard but you can set it provided you do it in response to a js event so in theory that is possible. The only problem is that you'd need to be sure the clipboard did actually contain the password because of course you can't read it. I guess you can log whether onpaste fired and then if the login button is clicked wi…

And by 'clear', I mean add a textbox, set its value to an explanatory message '{app} cleared the clipboard because it contained your password' and then execCommand on it.

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

#49

Post by digi_owl »

morgante wrote: post #15

The worst is websites which not only disable pasting but don't even let you type your password in. Instead you have to use their janky on-screen keyboard to fumble your way through login. I got so fed up with TradeKing (which has horrible security practices in general) that I close my account.

Gah, i have seen one too many asian made online game do this.

First you enter a password, then you have to enter a pin using a on screen numpad with jumbled placements.

And likely the game will be doing all manner of things client side, thus it is cheaters all over the place.

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

#50

Post by morgante »

level3 wrote: post #44
limelight wrote: post #39

Earlier quoted context omitted.

It actually makes a lot of sense. People will almost never manually type out high security (>20 random characters) passwords themselves. So if someone enters a high entropy password, you can fairly confident that mistyping is not an issue.

I'm not quit convinced about that. 1) Aren't there people using generators like Diceware that don't do the password management part? 2) The industry's definition of "high security" is constantly changing. Password strength measurement makes assumptions about what is and isn't guessable, and a lot of that depends on what techniques the common brute-force crackers are employing. So finding the right heuristic is also p…

> 1) Aren't there people using generators like Diceware that don't do the password management part?

I'm not sure they're actually that common. Moreover, if someone is sophisticated enough to use a password generator I assume they have some sort of system for ensuring integrity.

Also, if you're worried about someone changing their password to something they don't know, simply force a relogin and have effective password reset mechanisms.

> 2) The industry's definition of "high security" is constantly changing.

Industry might be getting more serious about encouraging higher security passwords, but standards for high security passwords haven't really changed much. People are just becoming less tolerant of low-security ones.

In terms of estimating security, you can use something like https://github.com/dropbox/zxcvbn which does a pretty good job of evaluating entropy and resistance to brute force attacks. Ultimately, a password with sufficient entropy will be resistant to any brute force cracker.

Post reply on HN