Live data from Hacker News

Let them paste passwords

ncsc.gov.uk

171–180 of 376 posts

Re: Let them paste passwords

#171
post #121

There is a subtle valid use-case. On "change your password" screens, you don't want the second "confirm password" field to be pastle-able to stop this scenario. 1) User tries to type "mypassword" but enters "mypasswor" instead. 2) User copy-pastes "mypasswor" into "confirm password field" 3) User hits "submit". Now when the user tries to login with "mypassword" it fails.

I think the use cases there is more accurately, if the user doesn't paste into the first box AND copies the content, don't let them paste into the second.

I would paste into both boxes and resort to developer tools if I am not allowed.

Re: Let them paste passwords

#172

Earlier quoted context omitted.

What about e.g. sharing a screen during a presentation?

Or cameras you don't know about.

If I have a camera I don't know about in my home then I have bigger issues than a password field on hacker news no?

Re: Let them paste passwords

#173

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).

Though I'm pretty sure I've seen "Your password is too similar to a previous password" before, which suggests some kind of plaintext Levenshtein distance check. "Is the same as" can be fine with a hash, but "Is too similar" is definitely a red flag.

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 "Password1234", the system could truncate the last digit on the new password and see if it matches the current one.

Re: Let them paste passwords

#174
post #121

There is a subtle valid use-case. On "change your password" screens, you don't want the second "confirm password" field to be pastle-able to stop this scenario. 1) User tries to type "mypassword" but enters "mypasswor" instead. 2) User copy-pastes "mypasswor" into "confirm password field" 3) User hits "submit". Now when the user tries to login with "mypassword" it fails.

That's fine. They can still reset their password and type it in properly. It's a minor inconvenience for the really, really rare use case where this happens. For one, you can't copy from a password field so it would have to be typed and copied from an external source. As long as it doesn't leave them in a locked-out state, I see no issues with this.

Re: Let them paste passwords

#175

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…

You are largely correct.

Passwords operate under the principle "something you know". (Unfortunately operating under this principle on the Internet is quite hard, but that's a different story). When you save passwords somewhere it's no longer with the assumption of being just "something you know", but more "something you have". Of course passwords are even less apt as "something you have", because they are hard to secure, both in storage and in use.

Nothing has fundamentally changed. That people can't imagine why someone would want to keep passwords "something you know" is because they don't understand they theory behind passwords. A password manager might seem like a solution, but in reality what you're getting is the worst of both worlds. You don't get the security of "something you have", like a key that can be stored in hardware and verified with disclosing it to the host. Nor do you get the flexibility, at least not as a user, of "something you know".

I actually think it would be a great idea to block password managers and offer an alternative protocol for authentication. That way if they want to keep their users they would have to implement that protocol. Suddenly you would have quite a lot of users using something more secure.

(just a random text on the subject: https://www.cs.cornell.edu/courses/cs513/2005fa/NNLauthPeopl...)

Re: Let them paste passwords

#176
post #82

Earlier quoted context omitted.

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…

> Even in my IT-literate circles password management usage is low You are forked if your manager is ever compromised. It's only a matter of time until a major breach happens with a popular password manager.

The same argument could be made about online banking or any other high-risk online service. Really though, your average manager far more likely to have their machine compromised with malware or fall for a spear phishing attack. There will always be ways to circumvent security, but password managers solve more problems than they create. Regardless if it was your password manager which was compromised, or any other sort of password leak, it's really easy to quickly change all of your passwords once it's secured again. Eschewing good because it's not perfect is a losing strategy.

Re: Let them paste passwords

#177
post #146

Earlier quoted context omitted.

If you can remember it that means you need to change it! I refuse to look at any of my generated passwords. For the services that wont let me paste in, I have a macro that will type whats on my clipboard. Just a simple auto IT script with a WAIT (so I can make sure I focus on the input box) and SEND. My password manager also clears the clipboard if it is equal to the last password copied after a wile (I've never time…

> If you can remember it that means you need to change it! I refuse to look at any of my generated passwords. I'm trying to understand the reasoning for this. Are you dealing with very sensitive information that you have a real reason to fear the rubber-hose cryptanalysis method?

For those not familiar with the rubber-hose method: https://xkcd.com/538/

Re: Let them paste passwords

#178
post #146

Earlier quoted context omitted.

> If you can remember it that means you need to change it! I refuse to look at any of my generated passwords. I'm trying to understand the reasoning for this. Are you dealing with very sensitive information that you have a real reason to fear the rubber-hose cryptanalysis method?

As a consultant, I have been given access to a lot of passwords for clients. From corporate bank accounts to production servers at government agencies. So they are very sensitive, and when my contract is up, I delete the password folder for that client. I started doing that with clients, then eventually ended up continuing it to my personal passwords as well.

You talked about not even looking at generated passwords, which is different from client's passwords. That's the part I didn't understand.

Although, honestly, the other part seems more bizarre. Gov't agencies and other clients are just giving you their sensitive passwords, and trusting you to delete them after the project, at your leisure? How is that not terrible security? Revoking a consultant's security needs to be in the hands of the employers.

Re: Let them paste passwords

#179
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…

That's ludicrous. Is your workstation covered in sticky notes and knickknacks? Are you re-using these passwords? Do you have to buy a new knickknack for every new website you visit that requires a password?

Re: Let them paste passwords

#180
post #68

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…

I agree with all your points except slideshows. Why so much hate against slideshows ?

I don't like them because they make it difficult to copy and paste the whole of the content.
Post reply on HN