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

331–340 of 376 posts

Re: Let them paste passwords

#331

Post by cm2187 »

kbenson wrote: post #268
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).

Manager: We need to ensure people aren't using similar passwords on reset, but we can't store the password unhashed. Developer: Similar passwords? Or Same passwords. Similar is hard. M: Similar. Can't let people be lazy with their passwords. D: Well, if we really have to do it, I guess we could store a bunch of hashed variations of the password, but... M: Good! Let's do that. D: ...but that could be a massive amount…

It's funny because "DecemberSixteen" is very different from "MarchSeventeen" as a password from a characters point of view but is trivial to extrapolate if you know the guy has to change password every 3 months.

Re: Let them paste passwords

#332

Post by cm2187 »

Buge wrote: post #168
stanmancan wrote: post #94

Earlier quoted context omitted.

Not true, they most likely convert all characters to a certain case before they hash it, so even if you entered PASSworD123 they convert to password123 and then hash. I believe I read that Facebook stores a few commonly mistyped versions of everyone's password. Actual password, typed as if caps lock was on, things like that.

That reduces password entropy and makes the hashes easier to crack.

Well, does it? Even if you crack it you don't have the correct casing. So you don't have the original password. Of course doesn't help if every other website converts to lower case too.

But if you use bcrypt you can partially compensate by using a higher work factor.

Re: Let them paste passwords

#333

Post by libeclipse »

> Justification 1: 'Password pasting allows brute force attacks'

This really pisses me off every time I see it.

JavaScript is client-side code. If the attacker you're protecting against can't trivially bypass this bullshit "security" feature in three seconds, then he/she is not something you should be concerned about.

Attackers like that probably have other skills like counting to 5 with a 60% accuracy, and pointing out their own nose with a 40% accuracy. (Just like you do if you have this on your website.)

Re: Let them paste passwords

#334

Post by Gustomaximus »

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…

I worked at a bank that still has online banking password requirement of 6 characters... though must contain a number so totally secure.

Internally they still use Lotus notes 7.? last I heard. And storage limit was something like 100Mb if I recall correctly.

Re: Let them paste passwords

#335

Post by BlackFly »

nathas wrote: post #307
dennisgorelik wrote: post #305

Earlier quoted context omitted.

Why do you think that "Passwords have no requirements" is a sign of incompetence?

Length seems like a reasonable requirement, e.g. it can't be "asd"

I'm pretty thankful on some websites when there are no password requirements. Like the article states, sometimes I am not coming back to that website. In truth the real annoyance for me is requiring an account. I wish more companies would just let me order without storing account details.

Re: Let them paste passwords

#336

Post by pmontra »

isometry wrote: post #296
pmontra wrote: post #95

Earlier quoted context omitted.

I guess it comes from old UNIX passwords (80s and before). They were limited to 8 characters if my memory doesn't fail me. But they were already stored with one way encryption.

Your memory's fine. man 3 crypt => https://linux.die.net/man/3/crypt

Thanks.

That prompted me to google up a summary of the password length limits of various operating systems https://security.stackexchange.com/questions/22721/password-...

Re: Let them paste passwords

#337

Post by matthewmacleod »

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

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.

Re: Let them paste passwords

#338

Post by dainichi »

syncsynchalt wrote: post #153
SamBam wrote: 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?

More because you'll develop a resistance to changing the password, since you'll have to start over on memorizing the new one.

AFAIK the benefit of changing passwords regularly is highly debatable anyway. If so, I think "Don't change it, since you would have to memorize the new one" is more logical advice.

Re: Let them paste passwords

#339

Post by the_watcher »

thesuitonym wrote: post #58
artursapek wrote: post #4

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…

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…

Nothing drives me crazier than random restrictions on my password. I get that there's probably justifiable reasons to limit the number of characters, but if it's a character found on a standard keyboard, it should be available.

Re: Let them paste passwords

#340

Post by consp »

matthewmacleod wrote: post #337
wapz wrote: post #326

Earlier quoted context omitted.

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

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.

Post reply on HN