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

Let them paste passwords

ncsc.gov.uk

Post reply on HN
Print view View original

241–250 of 376 posts

Re: Let them paste passwords

#241

Post by maxxxxx »

acdha wrote: post #227
maxxxxx wrote: post #142

Earlier quoted context omitted.

You are probably right about cherry picking. I know a lot of experts are aware of the problems but from an end user perspective security usability is still horrible and inconsistent.

No argument there — it's really interesting seeing the divide ultimately becoming users and experts on one side and people who are not experts but are setting policies anyway on the other.

"people who are not experts but are setting policies "

That seems to be the key issue.

Re: Let them paste passwords

#242

Post by deathanatos »

> Justification 3: 'Passwords would hang around in the clipboard'

Password managers could wipe the clipboard, if it still contains the password, after a defined amount of time, such as 60 seconds.

(If you think that's "confusing", show a notification that explains the behavior; "clipboard wiped" or something.)

Re: Let them paste passwords

#243

Post by WorldMaker »

Santosh83 wrote: post #25
alvarosevilla95 wrote: post #13

Please correct me if I'm wrong, as this is all conjecture. I feel passwords used to be thought of as a combination of characters that you keep in your head, and should only leave your head when being entered in a password field. Preventing paste discourages storing your password in a file called passwords.txt, and accidentally pasting it somewhere else as well. Of course, we now understand passwords should have some…

Could be, but it's flawed reasoning anyway. Preventing copy/paste won't prevent people from storing their passwords in passwords.txt. Nobody other than those who use very simple, high risk passwords can remember them all. It has to be stored somewhere. Preventing copy/paste seems like a completely useless step (security wise) that only causes unnecessary bother.

Also, depending on threat model, a passwords.txt clear text file can be perfectly cromulent security that is better than many alternatives (password reuse, weak passwords). It's not going to stop people with physical access to your machine or attackers specifically targeting you looking for weaknesses in your documents. But vulnerability to some threat models is not vulnerability to all of them and it's okay to take a security stance with known vulnerabilities.

Similarly with Post-It Notes and physical written Notebooks of passwords. If your threat model isn't concerned about people with physical access to those notes, and you are comfortable with the physical security of those notes, that can be perfectly acceptable for you, and an overall better security stance from bad passwords.

"Don't write down your passwords", has always been bad advice, from that perspective. "If you write down your passwords, keep them safe" is slightly more accurate.

Re: Let them paste passwords

#244

Post by Merad »

discreditable wrote: post #7

On Chrome you can use "Don't Fuck With Paste" to override these bad forms: https://chrome.google.com/webstore/detail/dont-fuck-with-pas...

In Firefox you block them by going to about:config and changing dom.event.clipboardevents.enabled to false.

Re: Let them paste passwords

#245

Post by eridius »

NoGravitas wrote: post #240
eridius wrote: post #230

Earlier quoted context omitted.

But that's not a feature of email in general. That's a feature of gmail, and a few other email providers that have followed suit. For email in general, foo@bar.com and foo+baz@bar.com are distinct emails that may go to different users.

I wouldn't say "a few other email providers that have followed suit". As far as I know, that's always been a feature of Postfix, and common with Sendmail before that. And qmail offered "-" for the same purpose (as well as providing a facility for filtering/redirecting mail based on -extensions).

The point is that foo+bar is a convention that many providers follow and not an actual rule of email, and therefore blocking that doesn't make sense because you'll block legitimate addresses too.

Similarly, mail providers can come up with all sorts of different conventions if they want. For example, when setting up a new domain in FastMail, it offers the ability to accept anything@user.dom.ain and turn that into user+anything@dom.ain, and it offers user@anything.dom.ain which it will deliver to user@dom.ain. So here we already have two new conventions that sites can't possibly detect as alternatives to the normal foo+bar@dom.ain.

Re: Let them paste passwords

#246

Post by apostacy »

acdha wrote: post #117
maxxxxx wrote: post #38

This whole discussion is a good example for everything that's​ wrong with computer security. Instead of coming up with solutions that make it easy for people to follow good practices the "experts" make it even more cumbersome. Most people just want to use the computer and not think about security.

You're cherry-picking pretty heavily: there's a lot of cargo-culted password advice but the current push for user-friendlier password management practices and fundamental model changes (e.g. two-factor with U2F) has been lead by security experts who have, for many years, been loudly reminding everyone that usability is a security requirement rather than an inherent conflict.

I think that the problem is just that the people making these decisions are not security experts, but web designers.

Re: Let them paste passwords

#247

Post by mderazon »

I don't care much when it happens on a website, because I can bypass that easily, but it's enraging when I see this practice in mobile apps.

For example, my bank's app don't let you paste passwords. I have a strong random password which basically means I can't access it from my phone...

Re: Let them paste passwords

#248

Post by aaronmdjones »

sillysaurus3 wrote: post #10
discreditable wrote: post #7

On Chrome you can use "Don't Fuck With Paste" to override these bad forms: https://chrome.google.com/webstore/detail/dont-fuck-with-pas...

I was hoping this would also prevent websites from messing with the input to the clipboard. It's a bit annoying to copy a sentence from a website only to have "Read more on XYZ!" appended to it.

In Firefox you can disable this by setting dom.event.clipboardevents.enabled to false.

Re: Let them paste passwords

#249

Post by dj1yfk »

eridius wrote: post #233
benchaney wrote: post #125

Earlier quoted context omitted.

Strictly speaking, the dot in the latter space isn't actually necessary. It needs to be a resolvable domain, but if you bought a TLD you could be "name@tld"

Can you actually attach an MX record to a tld?

https://gist.github.com/ddol/1445736

Re: Let them paste passwords

#250

Post by apostacy »

mderazon wrote: post #247

I don't care much when it happens on a website, because I can bypass that easily, but it's enraging when I see this practice in mobile apps. For example, my bank's app don't let you paste passwords. I have a strong random password which basically means I can't access it from my phone...

Chase.com is one of the worst. The desktop version of the site does all sorts of browser fingerprinting with javascript. It does things like tries opening up websockets to random local ports, and stuff like that.

I had to just throw up my hands and do all of my access to chase.com through a sandboxed browser profile, where I could automate logins.

Post reply on HN