Live data from Hacker News

Let them paste passwords

ncsc.gov.uk

361–370 of 376 posts

Re: Let them paste passwords

#361
post #82

Of course it reduces security. It makes you resort to either 1.) typing it out manually while you can't see if you made a mistake 2.) using developer tools to set the 'value' attribute directly "SPP" discourages use of a password manager. End of story. I also see this pattern used on banking websites for inputs like an account number. This drives me crazy as well for the same reason. The computer can get it right mor…

It's interesting that a lot of us are assuming that pasting encourages the use of password managers. However; I worry that this is a very BIG assumption. Even in my IT-literate circles password management usage is low. In my non-IT circles it is non-existent, and not because of SPP particularly; I suspect SPP (which I agree is silly) derived from an understanding that allowing an average person to paste passwords mea…

> In my non-IT circles [password management] is non-existent, ... an average person to paste passwords meant they stored them in passwords.txt on their desktop.

But that is password management, it's just crap password management.

There's certainly an argument that a plaintext-on-desktop stored list of high-entropy passwords is better than a single in-(human)-memory low-entropy password. With the recent wannacrypt reminder, that argument's slightly diminished, though.

I think the highest impact (i.e. fn of quick/low effort, high reward) suggestion to non tech-literate folk is to use 2FA on their email account. I like and usually suggest Authy, mainly because it's available as a Chrome app too whereas e.g. Google Authenticator is just on Android/iOS. (I assume it's clear, but email account as opposed to something else since it's so near universally treated as the fallback option.)

That's a good base for them to start using 2FA everywhere else it's possible, too.

Re: Let them paste passwords

#362
post #276

Earlier quoted context omitted.

longer passwords don't hash to longer values (within any reasonable variation of order of magnitude in input size). That would defeat the purpose of hashing

But a longer password would require more combinations for similarity than a short password.

Ah. Thanks for clarifying.

Still, permutations longer hashes don't require substantially more space. Password storage is a completely trivial fraction of total storage -- Compare to a single photo, or a video!

And further still, they don't need to _store_ all the hash variations

https://security.stackexchange.com/questions/53481/does-face...

Re: Let them paste passwords

#363
post #308

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.

That doesn't help. Your new password might be the same as the twice-previous password.

Re: Let them paste passwords

#364

Earlier quoted context omitted.

Exercising your memory is good for more than just passwords, you know.

Like I said. Amazing.

And some people run marathons when they have a perfectly serviceable automobile. Remembering many passwords is not particularly remarkable. I am far more impressed by those who [uselessly] memorize thousands of digits of pi.

Why would anyone do that, when those digits can so easily be calculated or referenced from data files? Why do anything that is not strictly necessary? Why try to bench press more weight than last time? Why try to improve your chess game? Why learn a new programming language?

Because different people like different things. I am not required to like the things you like.

And I like proving to myself that I still can remember things without a helper daemon to keep track of them for me. I like that little bit of paranoid fantasy I have that makes me think that the men in black suits would have to take the pipe wrench to my kneecaps to get at my passwords, so I don't think about how the security at all these sites requiring password is so piss-poor that it would be easier to bypass all passwords in lieu of cracking just one of mine. In the end, the problem mentioned by the article is that very few people implementing computer security measures have any idea how to truly secure their data, so they do stupid shit like block clipboard pasting into password entry fields, or allow accounts to be hijacked by a spoofed SMS 2nd factor, or try to roll their own crypto without the requisite number of CS and math PhDs.

Re: Let them paste passwords

#365
post #256

Here's another weird restriction: password length limits. I've had websites tell me I can't use more than 8 or 16 characters. Even if they let me use a thousand characters that's just going to get hashed to the same length anyway, right? Even worse: sites that silently truncate your pasted password to the maximum length. When all you see is those little dots and the password is wider than the text field, it's very di…

> Even if they let me use a thousand characters that's just going to get hashed to the same length anyway, right?

That assumes they're not storing your password in a VARCHAR(16) field, which is what I always assume when I see a max password length restriction like this. Or perhaps they're using the ridiculous LANMan hash algorithm [1].

[1]: https://en.wikipedia.org/wiki/LAN_Manager#LM_hash_details

Re: Let them paste passwords

#366

Earlier quoted context omitted.

Fully qualified domains actually end in a . If you're allowing sally@google then you must also allow sally@google. To be valid

No you don't. Email addresses explicitly require any periods in the domain to have at least one (non-period) character after the period. From RFC 5322, the relevant grammar production for the domain looks like dot-atom-text = 1*atext *("." 1*atext) (where atext is letters, digits, or a set of specific punctuation characters that doesn't include periods).

Ah, I wasn't aware that email addresses defined that differently. it looks like it's also the same way as part of obs-domain as defined by the addr-spec part of that. RFC 822 also seems to say the same thing, it's been way too long since i've tried to read those RFCs.

Re: Let them paste passwords

#367
post #220

Earlier quoted context omitted.

well, string+{whatever1}@gmail.com mails are redirected to string@gmail.com. So a user can just open account for string@gmail.com and then use that to open thousands of user accounts on the site that allows "+" on the email field. (I used to do this on sites that allowed limited number of free downloads after which you had to pay)

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.

That is fair, but maybe the providers just want to stop account spamming on their sites, can you blame them for that?

Re: Let them paste passwords

#368
post #367

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.

That is fair, but maybe the providers just want to stop account spamming on their sites, can you blame them for that?

Depending on your email provider, there are a ton of different ways to create brand new email addresses. Blocking off the single pattern of foo+bar@example.com just punishes legitimate users without causing any problem for spammers. Besides the fact that foo+bar@example.com may in fact be a legitimate unique email address, there's also just the case of people who routinely use username+sitename@example.com when signing up for anything as a way of tracking where incoming email is coming from.

Re: Let them paste passwords

#369
post #362

Earlier quoted context omitted.

But a longer password would require more combinations for similarity than a short password.

Ah. Thanks for clarifying. Still, permutations longer hashes don't require substantially more space. Password storage is a completely trivial fraction of total storage -- Compare to a single photo, or a video! And further still, they don't need to _store_ all the hash variations https://security.stackexchange.com/questions/53481/does-face...

Wow, it slipped my mind entirely that you could do the permutations when you create the new password but before verifying, rather than after creating a password. That's a great idea, and embarrassingly obvious in retrospect.

Re: Let them paste passwords

#370
post #27

Earlier quoted context omitted.

Oh, come on. All of them? If you're like me, that’s hundreds. Are you a memorization savant? Are you creating low-quality passwords? Mine are actually long and random (generated NOT by me and NOT four Dr Seuss words)

You just make up a story and use one of the knickknacks you keep near your workstation as a memory trigger. For instance, if I needed a new strong password, I could use, "This#jar#once#held#1111#M&Ms,#but#now#it#is#empty." The only thing I need to remember there is the story of the jar and the padding character I used in place of spaces. If I really had to, I could put "#" on a sticky note under the jar. But of cours…

You could also ... use spaces?
Post reply on HN