Live data from Hacker News

Dumb Password Rules

github.com

81–86 of 86 posts

Re: Dumb Password Rules

#81
post #80
post #31

Earlier quoted context omitted.

What? If a person is using a password that contains such a character, they'll know how to type it or at least find it to copy/paste... QWERTY isn't the only keyboard layout. Nor do you need right-alt support to type things like é or ç, you just need to enable the US-International Keyboard layout (on Windows, I'm sure equivalents exist for other operating systems). >Case in point is me setting up new linux boxes and a…

> What? If a person is using a password that contains such a character, they'll know how to type it or at least find it to copy/paste... I have had to deal with people not being able to type their passwords because a character wasn't on their current keyboard of choice (some people use iPads and don't know how to type a # for example) > you just need to enable the US-International Keyboard layout (on Windows, I'm sur…

>you're giving way too much credit to the knowledge of the average computer user.

If they're creating a password with ß in it I'm assuming they know how to type ß, yes. I don't expect the average user to know how to type ß. :)

Re: Dumb Password Rules

#82
post #81
post #80

Earlier quoted context omitted.

> What? If a person is using a password that contains such a character, they'll know how to type it or at least find it to copy/paste... I have had to deal with people not being able to type their passwords because a character wasn't on their current keyboard of choice (some people use iPads and don't know how to type a # for example) > you just need to enable the US-International Keyboard layout (on Windows, I'm sur…

>you're giving way too much credit to the knowledge of the average computer user. If they're creating a password with ß in it I'm assuming they know how to type ß, yes. I don't expect the average user to know how to type ß. :)

And then they travel and use a different device with a different keyboard layout and suddenly they don't know how to type ß anymore.

Re: Dumb Password Rules

#83
post #82
post #81

Earlier quoted context omitted.

>you're giving way too much credit to the knowledge of the average computer user. If they're creating a password with ß in it I'm assuming they know how to type ß, yes. I don't expect the average user to know how to type ß. :)

And then they travel and use a different device with a different keyboard layout and suddenly they don't know how to type ß anymore.

[deleted]

Re: Dumb Password Rules

#84

Earlier quoted context omitted.

Out of curiosity, what bank is this?

The Sparkassen in Germany do this, but they're not alone in doing so. They lock you out after a couple of attempts, so brute-force is out, but it's still dumb.

> so brute-force is out

Until someone gets ahold of a list of the hashed passwords and can brute force them at home without triggering the lockout.

Re: Dumb Password Rules

#85
post #82
post #81

Earlier quoted context omitted.

>you're giving way too much credit to the knowledge of the average computer user. If they're creating a password with ß in it I'm assuming they know how to type ß, yes. I don't expect the average user to know how to type ß. :)

And then they travel and use a different device with a different keyboard layout and suddenly they don't know how to type ß anymore.

Also that ß submitted by one browser is \xc3 \x9f in one browser and \xdf in another and \xe1 in yet another. Sure - if the client behaves correctly, you'd know what it arrives as, but some browsers don't and suddenly the password 'foobar' can be used to log-in, but 'foßbar' can't.

By not allowing non-ascii characters in the first place you remove a whole class of support issues.

Re: Dumb Password Rules

#86

Earlier quoted context omitted.

err in that attack how do they know your original password to change it back? and if they know your password to change it back why bother changing it in the first place, why not just log in as you? AFAIK the reason for password history is where periodic password change is enforced, to prevent a user from just alternating between two passwords. enforced periodic password change is (in the general case) not great for s…

Let's say a service does not require you to change the password. You are then "compromised once, compromised forever", at least until you change the password. Let's say it requires you to change it every month. You are compromised at max for a month, right? If the attacker changes the password, you will notice, and make a different password , which will lock them out since they don't know the new one. So they won't c…

I've done many password audits over the years and all monthly password changes does it make people use sequence passwords (e.g. MyPass1!, MyPass2!, MyPass3!) which are easily guessed by the attacker once they have one instance of the sequence, so really monthly changes add very little in exchange for the hassle they introduce.

The more sensible approach is not to force periodic change and only change where there is a suspicion of breach.

Post reply on HN