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

401–410 of 450 posts

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

#401

Post by Vexs »

banana_giraffe wrote: post #353
oneeyedpigeon wrote: post #350

Earlier quoted context omitted.

I'm intrigued as to how you 'pronounced' that. Did you say "open parens" and "caret", and did they understand what you meant? Also, is having to divulge your password really the best way of verifying your account? Do they advise you to change your password immediately after going through this rigmarole?

I would have rattled off something like "oh open paren sea cap why colon caret you equals" and so on. Honestly I have no idea if they parsed the sentence, or decided "gibberish from phone equals gibberish on screen .. good enough" They didn't advise me to change my security question, no doubt because the name of my favorite childhood pet isn't likely to change.

Huh, never thought about it, but that's a pretty good argument against random security questions.

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

#402

Post by Vexs »

bbotond wrote: post #200
Merad wrote: post #169

Earlier quoted context omitted.

I imagine he/she is referring to how most "security questions" use info that we typically don't hesitate to give out in casual conversation, even with total strangers.

Man I hate those security questions with a passion. They are super weakly protected backdoors into your account. Here's how I deal with sites that require them: site: "What is your first teacher's name?" me: "'Fx| The answer is a password equivalent, so I just treat it like a password.

Someone pointed out that if you talk to a CS rep and try to say that off, they'd just hear gibberish- meaning if someone tried to get at your stuff, they would just have to spout off gibberish and the CS rep would probably accept it.

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

#403

Post by Vexs »

superuser2 wrote: post #224
rsync wrote: post #206

Earlier quoted context omitted.

"If you know somebody's email, and you have a plausible reason to have a conversation with them, you can very easily take over their email account and reset the password on every account attached to it." Not if they self provide their own email (by running their own mailserver).

The same security question nonsense happens at server/VPS providers too.

You can run a email server off a raspberry pi these days.

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

#404

Post by zhengyi13 »

phlo wrote: post #375
ianferrel wrote: post #339

Earlier quoted context omitted.

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

Either you employ some sort of malware detection on your login page. Modern trojans mostly inject stuff into web pages, so things like Trusteer Pinpoint will scan the DOM and report back anomalies. Based on those reports you block the user from logging in or send them to a safe sandbox so they can't do any damage to their accounts. Alternatively, you can work with your clients' ISPs. Most malware still exhibits visib…

802.1x at the ISP? That'd be a very interesting proposition.

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

#405

Post by nommm-nommm »

Vexs wrote: post #403
superuser2 wrote: post #224

Earlier quoted context omitted.

The same security question nonsense happens at server/VPS providers too.

You can run a email server off a raspberry pi these days.

Not if you want other people to read your email, its going to go right to their spam filter.

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

#406

Post by delecti »

rsync wrote: post #208
nothrowaway wrote: post #55

If it helps anyone, this Chrome extension has worked every time I've tried it: https://github.com/jswanner/DontFuckWithPaste (I usually keep it disabled, but enable it when I'm about to use a site that has paste disabled on any fields.)

"If it helps anyone, this Chrome extension has worked every time I've tried it: https://github.com/jswanner/DontFuckWithPaste" Shouldn't chrome itself be a "don't fuck with paste" tool ? As the world moves to the browser as the OS (essentially) it's imperative that the browser respect end user wishes and behave as a sentry against malicious websites and malicious website behavior.

Most of the time websites disable paste by registering "onPaste" events. How do you allow websites to keep doing that when necessary, but not allow the websites that break the paste?

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

#407

Post by nommm-nommm »

ry_ry wrote: post #110
limelight wrote: post #30

Earlier quoted context omitted.

> Just disregard the segment of your users who don't use password managers? No, I recognize that most users probably don't use password managers. But I'm not convinced that disabling pasting helps much. For one thing, I don't actually think it's that common for someone to copy a mistyped password. Browsers disable copying from password fields, so they would have to type it in a third place and copy it into the fields…

You can get/set HTMLInputElement.value on [type="password"] anyway so if you wanted to shim the PW field copy/paste functionality back, you could just create a bookmarklet or something. Edit, threw an example together. Ignore the horrible code ;P Http://jsfiddle.net/6gc2d6hb Type in one of the PW fields then double-click it. Doesn't overwrite populated PW fields.

I just open up firebug and edit the DOM to add value='mydesiredpassword' to the password field(s).

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

#408

Post by nommm-nommm »

djrogers wrote: post #368
gruez wrote: post #69

Earlier quoted context omitted.

Unless the login page needs JavaScript to work (like SPA)

No, this should still work. Kid the page, let JavaScript run. Kill js, paste your password, then re-enable js before hitting submit

Or just directly edit the DOM.

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

#409

Post by mankyd »

DavidSJ wrote: post #340
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…

I often use copy/paste to prevent typing errors. I save the password in some keychain software, then I copy/paste the password from that software into one of the password fields, and type it myself into the other.

Yes, I am the same, but there's [at least] two different types of users here. I use a password generator + manager. I never type a password, so I never mis-type a password.

My father, on the other hand, hunts and pecks and I can't get him to use a manager despite my best protestations. Having to retype his password certainly avoids mis-types on his part, even if it encourages other bad behaviors in the process.

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

#410

Post by cocoflunchy »

eloisius wrote: post #247

TradeKing went full idiot and disabled entering your password by keyboard completely. They implemented an on-screen keyboard and there's no way to opt out. Their support forum is full of angry customers, people who can't use their screen readers anymore, etc. They argue [1] it's to protect their customers from key loggers. [1]: https://community.tradeking.com/forum/categories/suggestions...

Every bank in France does this too... and my bank (BNP) also forces me to change my (6-digits) password after 80 logins for "security reasons", which only has the effect of me choosing easy-to-remember passwords.
Post reply on HN