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

341–350 of 376 posts

Re: Let them paste passwords

#341

Post by teekert »

pwg wrote: post #216
jmkni wrote: post #83

Earlier quoted context omitted.

I use a password manager to generate long, complex passwords for every service I use (as complex as the service will allow). For sites that disable pasting, I have developed quite a skill at copying the password character by character from my PM into the password field. I'm even starting to remember a couple of them. Incredibly frustrating.

> For sites that disable pasting, For Firefox, setting the "dom.event.clipboardevents.enabled" about:config option to false prevents clipboard paste events from reaching javascript. No more blocked pasting after you toggle that option, even if the website attempts to do so.

Came here to say this, this should be the top post.

Re: Let them paste passwords

#342

Post by jhasse »

ben_jones wrote: post #201
jhasse wrote: post #194

Earlier quoted context omitted.

Allowing apps to create virtual keyboards with which they may manipulate all other apps might not be a good idea. That's why it won't work with Wayland for example.

I mean your password manager already has all your passwords. The argument can be made that you can trust the man who already has a knife to your throat.

True, I trust my password manager. But having the ability to create virtual keyboards at all might be a risk for the apps I don't trust.

Re: Let them paste passwords

#343

Post by ajanuary »

joshvm wrote: post #78
thesuitonym wrote: post #58

Earlier 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…

We had a gem at my last university (UCL): you must rotate your password every few months, your password can't be anything like any of the previous ones (i.e. previous ones are stored, and they're not hashed), your password must contain special characters etc. Except.. it can only be 8 characters long. Anything else gets truncated (they explicitly said so). The mind boggles. I have no idea where this limitation comes…

My University also had an 8 character restriction. When I asked them about it, they said it was because they wanted a single password across all of the systems, and some of them were really old and had an 8 character restriction, so that had to propagate up to everything else.

Re: Let them paste passwords

#344

Post by anonymouz »

consp wrote: post #340
matthewmacleod wrote: post #337

Earlier quoted context omitted.

I've certainly never encountered a web app that hashes locally before sending. I suppose it could work if this was at the account creation or password management stages, but you couldn't implement it at the login stage for obvious reasons. I'm having trouble imagining what scenario client-side hashing would protect against.

Man in the middle attacks fetching for plaintext passwords -- edit: using a KDF would improve it even more.

If the client only sends the hash to the server, a MitM also only needs to capture the hash.

Re: Let them paste passwords

#345

Post by croon »

consp wrote: post #340
matthewmacleod wrote: post #337

Earlier quoted context omitted.

I've certainly never encountered a web app that hashes locally before sending. I suppose it could work if this was at the account creation or password management stages, but you couldn't implement it at the login stage for obvious reasons. I'm having trouble imagining what scenario client-side hashing would protect against.

Man in the middle attacks fetching for plaintext passwords -- edit: using a KDF would improve it even more.

Sure, but if they've MITM:ed your trusted certs, aren't you already boned in so many ways?

Re: Let them paste passwords

#346

Post by anonymouz »

ryanisnan wrote: post #303
pixeloution wrote: post #75

Earlier quoted context omitted.

Just to add to the above comment, a diceware passphrase is MUCH harder to break than most people realize. For example, compare the possible number of combinations: Diceware, 6 words 2.2 x 10^23 Diceware, 5 words 2.8 x 10^19 Diceware, 4 words 3.6 x 10^15 a-zA-Z0-9, symbols, 10 4.3 x 10^19 a-zA-Z0-9, 10char 8.4 x 10^17 a-zA-Z0-9, 8char 2.2 x 10^15 A 6 word diceware phrase has 100 million more combinations than the 8 ch…

This kind of assumes that you're trying to crack a password with the operating assumption that words are indeed not used, that every character is random, and that you wouldn't use some sort of word library to construct passwords.

No, it doesn't. It assume that you know exactly that the password is a Diceware password. The standard word list has 7776 entries, giving 7776^6 ~ 2.2*10^23 combinations for a 6 word passphrase.

Re: Let them paste passwords

#347

Post by joshvm »

kbenson wrote: post #299
spinsser wrote: post #297

Earlier quoted context omitted.

Why would they need to store the hash for all the combinations? Why not generate a list of similar passwords to the new password, hash them all using the same salt of the previous password and then compare them.

Depending on what is considered "similar", every extra password character may exponentially increase the number of similar passwords.

Well in my case, there was only an 8 character limit, so there was a least a bound on it. I didn't investigate how far you could deviate from an old password before it was allowed though.

Re: Let them paste passwords

#348

Post by joshvm »

Osiris wrote: post #308
jameshart wrote: post #84

Earlier quoted context omitted.

> your password can't be anything like any of the previous ones (i.e. they're not stored hashed) That's... not necessarily the case. You can implement that check by only storing hashes of previous passwords, or of patterns derived form them that are also forbidden (e.g. store a bcrypt of every previous password converted to all lowercase and with numbers and symbols removed).

That's unnecessarily complex. Just ask for the old password when doing an expiration reset. Validate the old one then compare that against the proposed new one.

Actually, that's a very good point - you did indeed have to submit the old and new passwords. I want to say that they checked against older passwords too, but I might be misremembering.

Re: Let them paste passwords

#349

Post by rypskar »

wapz wrote: post #326
Johnny555 wrote: post #173

Earlier quoted context omitted.

When I've seen that "your password is too similar..." warning, it was with a system that required entering my current password to set a new password, so no need to store a previous version in plaintext. Though another way around it is to apply a set of common transformations to your new password, hash it and see if it matches the previous one. I.e. if your current password is "Password123" and you try to set it to "P…

Aren't passwords hashed on the client side before sending it across the network? That would make your way around not work (unless that's done on the client side also after verifying from the server that it's correct).

Hashing it on the client side will make the hash the password. So the stored hash can be used as password by turning off the client side hashing, for instance by turning off javascript. You use https to avoid sending the password in cleartext over the network

Re: Let them paste passwords

#350

Post by snakeanus »

glandium wrote: post #306
marksomnian wrote: post #110

Earlier quoted context omitted.

.+@.+\..+

One (probably forgotten) reason people validated email addresses with convoluted regexps is that there are multiple (actually valid per RFC) email addresses formats that can do nasty things. Like explicitly specifying a series of mail servers to go through. They're (hopefully) deprecated and rejected by most servers nowadays, though.

> hopefully

Why?

Post reply on HN