Hacker News Reader

Comment by mikeryan | Hacker News Reader

Its funny I worked for a startup that got acquired by Comcast, and eventually we started having to follow the Comcast security policy which made us change domain passwords every month with requirements around using strange characters etc.

I'd say about 50% of the people ended up with their current password on a post-it on their monitor or desk.

View on HN

Yes, this same thing happens on the ship I work on in the summers. There are about 300 people, and about half have to reset their password when they come on board. There is the arbitrary 8 character, at least 1 #, at least 1 special character, at least 1 capital, can't match a dictionary word, and can't be close to the previous password. Also can't contain their name. Try explaining that to 150 people over and over again...it is so painful to watch some people try half a dozen, even a dozen times and still not get a password that will work, and then the vast majority will either write it down in a public place, share it, or forget it.

I'd based on the available data that could have just as much security, without all the user hassle, if we just require long passwords, no other requirement. Can you see how much easier it is to just say, your password has to be 16 characters or longer. Just think of a passphrase. For instance: IWa1kmydogonSaturdays Easy to remember, and I would argue, though would want to try to provide some evidence, that this would be just as, if not more secure than 8 characters with ridiculous requirements.

> if we just require long passwords, no other requirement

... then I bet lots of users will choose passwords like "passwordpasswordpassword".

I'd go with passwordpasswordpasswordpassword. Just to be safe.

Great idea. Everyone knows about passwordpasswordpassword.

But does anyone know thisisnotapasswordthisisnotapasswordthisisnotapassword ?

... with all due apologies to PIL.

The wise thing is to allow for and encourage the use of passphrases. Sentences are both easier to remember and harder to guess!

and of course only an alliteratively poetic machinist would think to use "sublimeswarfswirlsslowly"

Possibly, but I sure would like some data on this. Theoretically, I could try this out by getting approved from the CIO first and then just checking the hash vs the hash for passwordpasswordpassword and passwordpasswordpasswordpassword as well as any password in the top 100 from the previous leak that was > 16 characters (not sure if there are any). As said, I'd like some to get some real data as opposed to stipulations, but obviously it's hard to get this kind of data.

> just require long passwords, no other requirement.

I particularly liked the suggestion (elsewhere) to set passwords to a random combination of three dictionary words. It's hard to remember 7Gw$kW_ws, but I bet I could come up with a meaning for "dog shower flange".

That's not much better entropy on the password. It wouldn't take long to go through all three word combinations based on a normal english dictionary.

With a password the key is always entropy. You can use all the smarts in the world to avoid the pre-computation attacks on your password... but never forget that brute force is not limited to character by character attack :)

http://www.baekdal.com/tips/password-security-usability says that it would take 2,537 years to crack a password with three common words, at a rate of 100 guesses per second, and flange isn't common. That's long enough for me.

Right, so someone trying to brute force the password into the interface is limited by the speed of the program (or any artificial limits it should have built in :)).

In fact, just one word with a couple of numbers has the same effect.

Don't forget though, you are trusting this password to a site. If they are hacked, what then? Your 2K years turns into minutes or hours.

This guy picks that upper limit based on the idea that an attacker can't hit the webserver more than 100 times a minute, which makes me question how much he knows about crypto. He doesn't take into account someone who has access to the password hashes.

So assume they've got something lame like SHA-1 hashes, even on commodity hardware you're talking about 100,000 hashes a second. Now you're at 2.5 years. Setup a simple cluster or buy some CPU cards, and you easily get into the three month range.

Shit, he's in trouble now!

Use bcrypt, and chose a work function that's as high as you want. It's pretty trivial to ensure that given certain hardware, it will take a certain amount of time to hash a password.

Never Never NEVER use SHA-1 or MD5 for hashing your passwords, those algorithms are designed to be fast.

Anyway, the technique is called "Diceware", and you can pretty easily calculate how much entropy you're getting with it. (and assuming your attacker doesn't know you're using diceware, you're in even better shape.

That is good developer advice. But from the perspective of a user there is no harm in assuming the website your using stores your password as unsalted sha1 and go from there.

Reminds me of when I had to write a front-end for a web search feed. It was easy to test the standard case (millions of results, of which the first 1000 can be paged). But what about the case when there is only one page of results? The solution seemed to be, rather than finding a topic with only a few results, to keep appending common words until the # of results shrunk enough. For example, from Google:

  "antelope" has 14,100,000 results
  "antelope walrus" has 118,000 results
  "antelope walrus biscotti" has 8,100 results
  "antelope walrus biscotti eisenhower" has 1,690 results
  "antelope walrus biscotti eisenhower lambchop" has 8 results!

Bonus if you can find a word combo which produces a single page of interesting sites, not word spam. Of course now that this comment is on the web, make that 9 results for "antelope walrus biscotti eisenhower lambchop".

This was a concept back around 2004 or so called "googlewhacking". The goal was to form a search query of only two words that had exactly one hit on google.

I came up with such a scheme 12 years ago, but with some improvements. If you modify words from /usr/dict/words with h4xx0r style modifications, then it's easy to get above 80 bits of entropy with a reasonable number of entities.

An average vocabulary has something like a million words in it, if you word count derivations. If you can expand that by a factor of five with easily memorable things like 1337-speak transformations, you can get above 80 bits with only 4 entities.

I came up with a similar password for our house router. After a week, I couldn't remember which animals were involved...

Easy to remember, not so easy to type into a password box. Or maybe for you it is easy, but it wouldn't be for me.

I loathe policies about expiring passwords because it breeds insecurity in the manner you mention. However, my company has this same policy, not because its been evaluated as being a good policy, but because our SOX audits require it.

Another reason to grumble over SOX.

Yep, this is common practice.

I do a lot of pen testing, and one of the easiest ways to get access to important things is figure out a way to go into the IT department under some premise. Passwords galore, the rest is just memory :)

(this is, sadly, only a slight exaggeration)

I did support for a hospital a while back. The favored ( by faculty, not IT ) strategy there was a sticky note on the back of an ID badge. My guess would be that this is common practice anywhere where people carry ID badges.

Reply on news.ycombinator.com