Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Password Rules

portal.cs.oag.state.tx.us

Post reply on HN
Print view View original

151–157 of 157 posts

Re: Password Rules

#151

Post by dekz »

peeters wrote: post #145
dekz wrote: post #88

Earlier quoted context omitted.

We've moved on to a fictitious setup. I was so disgusted with my bank and their password policies and authentication measures. They too restrict to 8 characters, but they happen to also offer a SecurID token. This token can be used in conjunction with the initial authentication. I would happily switch to any bank where I can know my data is secure. How do we trust them?

> We've moved on to a fictitious setup. Fictitious? Did you read the rules in the original post? > 2. It must contain at least one letter, one number, and one special character. > ... > 5. Two of the same characters sitting next to each other are considered to be a “set.” No “sets” are allowed.

> Fictitious? Did you read the rules in the original post?

Yes. The grand parent post isn't talking about these rules per se, just a fictitious example of HR and bad password practices.

Re: Password Rules

#152

Post by jtheory »

TylerE wrote: post #99
r00fus wrote: post #68

Earlier quoted context omitted.

It's a good point towards passphrases instead. 1Password gladly generates "pronounceable" passwords (e.g. "thax-lers-ponc-werv"). I usually think a bit about whether digits or symbols are required (some services and websites - Skype notably) don't like them. A 20-char passphrase with spaces, dashes, or character-based (e.g. "S") word-boundary delimiter is often good enough to provide excellent (80+ bits) entropy.

Or how about everybody that uses these fucking inane rules just do something sensible - like lock an account out if there are more than 5 failed logins in a row. Using a setup like that even "4321" is probably secure enough. Obviously use a secure hash on the backend as well.

That's the trouble... the "sensible" options aren't so sensible when you really sit down and think about how they can be dodged, broken or abused.

Imagine I'm trying to crack into your site, and you lock any account after 5 failed logins in a row.

If I have access to (or can guess) a few thousand usernames, I can try the 4 most common passwords on all of those with no problems. I'll probably get some hits, no?

Or heck, I can try the 5 most common passwords, and not only will I have a few hits, I'll also have plenty of time to dig around without any attention from you, because you'll be struggling with a massive customer service nightmare, as thousands of your customers find themselves all locked out the same morning.

Re: Password Rules

#153

Post by jtheory »

entropy_ wrote: post #43
wetherbeei wrote: post #35

Earlier quoted context omitted.

Probably not a good idea, considering the answers to security questions are often not encrypted or hashed.

Why would that be the case? It just seems stupid to do so. A security answer is pretty much functionally identical to a password. Doesn't make sense not to hash it(there are no uses of the answer where you would need it in non-hashed form)

I'm not sure about all security questions, but I have noticed many credit card support lines ask me for my mother's maiden name, and the answer I give is long and not easily spelled but they always confirm -- instantly -- "that's it" and and proceed.

Think about last names, as well... there's huge variety in length, spelling, etc. -- it's poor customer service to force the customer to spell it out letter by letter -- so it's necessarily just displayed there on their screen.

Re: Password Rules

#154

Post by jtheory »

amalcon wrote: post #47
steve-howard wrote: post #44

Earlier quoted context omitted.

I don't know that passwords are all bad. For an alternative approach to complex rules, see: http://xkcd.com/936/ The last time I changed a password for a service I set it to a phrase that I can easily remember but which no human or current machine will easily guess. I'd say that the only good rule is "Make it at least 9 characters" (which is at least long enough to disallow "password").

11 is also a sane minimum, to disallow 1234567890.

Or you could just disallow "1234567890".

Re: Password Rules

#155

Post by unfletch »

kijin wrote: post #60
unfletch wrote: post #42

Earlier quoted context omitted.

I've used 1Password generated passwords for years. You're right, it is awesome, but only until you have to relay one of those generated strings to a support person over the phone: "...left curly brace. No, it's like the parenthesis, but squiggly. Are you using a regular keyboard? Hold shift and type the left square bracket. The square one. It's to the right of the P..." Nightmare.

I can't imagine the horror of having to recite any password to an actual human being. What kind of company asks you to tell them your password by phone? "No, the backslash. The one that leans backwards, no, I mean, to the left. Above the Enter key." Surprise, the backslash is not above the Enter key on Canadian bilingual keyboards.

    What kind of company asks you to tell them your password by phone?
I don't remember for sure. I think it was a utility company.

Re: Password Rules

#156

Post by epistasis »

jaybill wrote: post #149
epistasis wrote: post #108

Earlier quoted context omitted.

This is a terrible way to choose passwords, and in no way equivalent to the XKCD method. It's not equivalent because additional length in your password is very predictable rather than random. To brute force your password, all somebody has to do is choose a starting word in Wikipedia and some number of consecutive words. This is log2(size of Wikipedia) + log2(entropy of your "5 or 6" distribution). This is less than 3…

I didn't say I picked consecutive words. You'd be right otherwise, though.

Why are spaces important then?
Post reply on HN