

Myths of Password Security - lightup88
http://www.stormpath.com/blog/5-myths-password-security

======
kyrra
With the recent flaw (though very small flaw) in 1Password, I decided to do a
little research into the tools that password crackers use today. The first big
tool is the cracker itself. John The Ripper and HashCat are 2 popular ones
today, but I've focused my reading on hashcat.

Hashcat is a tool who's goal is to do various hashing functions as fast as
possible in both CPU and GPU (depending on what the user has available). Where
the tool gets interesting is the attack modes[1] it has. Each of the attack
methods has different use cases, but I would say Rule-based and table-lookup
are both fairly interesting (allow for smart generating of test passwords so
things it's not a full character set brute-force).

Now, you have other groups that are going out and doing analysis on database
password leaks[2]. This site tries to crack as many passwords as it can from
publically leaked password databases (such as Gawker ane EHarmony), then do an
analysis of the passwords they have cracked thus far. People can then use this
data to write rules for Hashcat or other tools to possibly crack passwords a
lot faster.

As rules for passwords change and people change their password habits, the
crackers will adjust their methods. While this article does bring out some
interesting points about passwords, it can still be good to know what tools
the crackers have at their disposal so you can think about how to craft a
password that won't be easily cracked.

[1] <http://hashcat.net/wiki/#attack_modes>

[2] [http://www.adeptus-
mechanicus.com/codex/hashpass/hashpass.ph...](http://www.adeptus-
mechanicus.com/codex/hashpass/hashpass.php)

------
pornel
A myth I'd like to dispel is that when login fails _not telling whether
username or password was wrong_ improves anything.

Please _do_ tell clearly when username was wrong. It won't disclose anything
new, because you're already disclosing this information by validating
registration form (and reg form will even disclose existence of registered
e-mails by forbidding duplicate registration), existence of profile URLs, all
kind of "add a friend" APIs, etc.

If you're really concerned about somebody compiling list of usernames by brute
force (and you've patched all other places where you disclose it) then put
rate limiting on the login form (you should have it anyway to prevent brute
forcing of passwords).

~~~
eddiemunster666
I humbly disagree, if you say to the user that the username was correct but
the password was wrong then you have leaked information to the user that they
should not have access to. i.e. If email is used as a username and I go to a
porn site and type in my wifes email address and a random email and it comes
back 'username right, password wrong' then I now know she has an account there
which she was trying to kepp secret.

It's not only bad from that point of view, but also the attacker now knows you
have a account there and so could try social engineering techniques to gain
access to your account, it basically provides a attack opportunity that it
doesn't have to.

~~~
mistercow
I think you're missing the point, which is that that information is _already_
unavoidably leaked by the signup form. So leaking it from the log in form
doesn't change anything.

~~~
HeyImAlex
Yep, the only way to _really_ leak no information is to just always say that
the action (sign up, forgot password) was sucessful, which is _awful_ from a
ux perspective. Don't forget to go through the motions of
registration/recovery to stave off timing attacks as well.

~~~
mistercow
I have actually worked on systems where the signup form allowed multiple users
to have the same user name, and the log in process consisted of checking for
the existence of a (username,password) pair. Needless to say, I regarded this
as a major design flaw and fixed it (except for the existing non-unique
users). But there is, for all the reasons it shouldn't be done, a situation
where the signup form doesn't leak usernames.

------
geal
Saying that using random words is better than using a string of unrelated
characters assumes that password crackers don't know how to combine words.

There are about 180000 words in English (but don't assume everybody knows
180000 words). That means that for three words, you have at most 5.8 _10^15
options.

For a password with mixed case and numbers, you have 62 different characters.
With, 9 characters, you have 1.3_10^16 options.

I can understand that people would prefer common words to remember them, but
they are not that much stronger.

The best password is the password I don't need to remember: generate long
random passwords, and store them in your browser, in Keepass, LastPass or
whatever system of your choice.

~~~
kijin
It depends on how many words you have in a string.

XKCD's oft-quoted comic uses 4 words. That would be 100000 times stronger than
using just 3 words, and vastly superior to your example of a random 9-char
password. The article's own example, "golf kangaroo crispy halitosis", also
uses 4 words.

I agree with you that long random passwords are the way to go, but even in
that case you need to remember at least one password: the master password to
your password manager. It would be a good idea to make that a string of 4 or
more words. My LastPass master password consists of 5 words with a bunch of
symbols sprinkled in between, and my banking password is 4 words in a foreign
language.

~~~
pfedor
The problem is, if you actually choose your 4 words randomly out of the full
dictionary, you won't get something like "golf kangaroo crispy halitosis" or
"correct horse battery staple". It will sound closer to "capaciously
endodermal remast amarantite". The set of words as familiar as "golf",
"kangaroo", etc. is much smaller than 100k.

~~~
dllthomas
It doesn't have to be as memorable as kangaroo, it has to be more memorable
than the equivalent (in entropy) number of random characters, which I think is
basically any word.

$ wc -l /usr/share/dict/words

99171 /usr/share/dict/words

$ rl -c 4 /usr/share/dict/words | xargs -d\\\n

contortionists mocking Alphard soling

$ rl -c 4 /usr/share/dict/words | xargs -d\\\n

Toni's dish's mauled spillages

$ rl -c 4 /usr/share/dict/words | xargs -d\\\n

expedited tireless interneships tranquiller

$ rl -c 4 /usr/share/dict/words | xargs -d\\\n

bohemian rogering unkindliest ayes

------
pizza
I'd say jjjjjjjjjjjjjjjjjjjjjjjjjjjj, from a human-interpetation standpoint,
has very low entropy, since there is very little uncertainty as to what will
come next... This would be evident if password security checkers tried to
compress passwords and compare them to the original message.

i.e. "jjjjjjjjjjjjjjjjjjjjjjjjjjjj" is 224 bits as a string. Huffman-encoded,
you only need 0=j as a code to convert it into 28 bits, a compression of
87.5%. So this is a good way of actually checking the security of a password,
if it _seems_ to have high entropy.

------
jere
>Simply put, adding length increases entropy more efficiently than replacing
letters with symbols.

I don't like this meme. Because it's not necessarily "more efficient." Like
most things, it depends. If I have a password made of 10 lowercase characters,
it's much better to replace with an upper case character rather than add
another lower case one.

Option 1) Add a lower case character. Password is _26_ times stronger.

Option 2) Replace 1 upper with 1 lower case character. Password is _1024_
times stronger.

~~~
eterm
But don't do what someone I know did and replace every single e with 3, every
single a with 4, every single o with 0.

Identical entropy, extra theatre.

~~~
mnarayan01
Not to imply that what you describe is a great strategy, but I wouldn't
describe it as pointless. The password "12345" has the same entropy as "b0g4p"
but it would be a mistake to think they are equally secure.

~~~
mistercow
>The password "12345" has the same entropy as "b0g4p" but it would be a
mistake to think they are equally secure.

Those do not have remotely equal entropy.

~~~
mnarayan01
At the byte level it does, which is presumably what the OP was talking about
when saying that replacing characters with digits (uniformly) does not affect
entropy.

~~~
mistercow
Maybe, but I would hope that's not what s/he meant, because that kind of
entropy is basically irrelevant to password strength.

------
danso
This is a bit of a fluff piece, isn't it? All five points are "true", to some
degree, but not when you consider the details.

Take point #4:

> "4. MYTH: Two-Factor Auth Means Any Password Will Do" > > _This is
> absolutely not a dismissal of multi-factor auth. Use it when it’s available!
> Two factor is on the Stormpath roadmap, and we use it for many backend
> systems. Just don’t consider it a substitute for strong passwords._

The example that the OP blithely cites is Cloudflare's incident in 2012, when
CloudFlare's CEO explained how his GMail account got compromised despite
activating 2-factor authentication. However, if you actually click through the
post, you see that CloudFlare's problem had nothing to do with a weak
password, but a flaw in AT&T's authentication procedures which allowed a
hacker to bypass GMail's password/auth requirement with a little social
engineering. It had nothing to do with the CF CEO's password, which he says
was strong and 20-characters long. In his case, it wouldn't matter if the
password was 8 characters long and a dictionary word, if 2-factor auth worked
as it was supposed to.

[http://blog.cloudflare.com/post-mortem-todays-attack-
apparen...](http://blog.cloudflare.com/post-mortem-todays-attack-apparent-
google-app)

And that's kind of the whole dilemma of security, isn't it? That certain
maxims ("Your password should be x characters long and contain y different
kinds of characters") do not universally apply, and that the implementation of
security protocols is extremely important into understanding your potential to
be hacked. The OP's mythbusting is somewhat counter-productive here.

------
venomsnake
Fist myth is that passwords provide security. The human brain is crappy rng so
it cannot create proper high entropy passwords. No way getting around that -
whatever your password is if it is "derived" from something - someone else is
using it too.

The only viable security I can think of is if we have distributed public key
infrastructure. Bitcoin style wallets. And securing the "PK wallets" is up to
the end user. Persona is close I think - so if the app fad/insanity finally
dies we will be on a good track.

~~~
mistercow
>The human brain is crappy rng so it cannot create proper high entropy
passwords. No way getting around that...

Yes there is: you use a real RNG to generate your password. A good option is
<http://passphra.se>. Just remember that you can't go clicking "Generate
Another!" until you find something particularly memorable, or you'll be
sacrificing an unknown amount of entropy by narrowing the space to memorable
passwords. Better to keep the phrase somewhere safe (encrypted) until you have
managed to drill it into your head. I like to fit the phrase into a sentence,
which adds both memorability and entropy.

For example, it just gave me: "song surprise calm task", which I might turn
into "Sing a song of surprise, and resume your calm task.", which Dropbox's
zxcvbn tool estimates at 141 bits of entropy. If a password form has a
character limit, you can initialize the sentence, yielding "Sasos&ryct", which
zxcvbn rates at a not-too-shabby 52 bits.

~~~
venomsnake
If we assume that English has 65535 words a four word password gives you 64
bits of entropy. Of course the real number of words that you can use for mass
generation is 2k (or even less) if we search words that everyone that is
standard deviation or two below the mean on the vocabulary graph can use and
spell correctly. Spelling is going after the ability to memorize telephone
numbers too with everyone using the crutches of autocorrect and other spell
checking tools. The moment everyone uses that scheme the people interesting in
reversing passwords will move in that direction too.

This is fake security trough obscurity. You can get pretty secure passwords
nowadays by just concatenating your username and site domain and md5-ing them
and taking the first half. It generates awesome passwords ... until you are
the only one using this way of deriving passwords.

The human brain is not suited for remembering long complex passwords. Even
less suited for unique for every service.

~~~
mistercow
Four words chosen from 2048 possibilities gives you 44 bits of entropy (this
is what passphra.se does). If you're being specifically targeted in an offline
attack, that won't hold up. But in that very rare scenario, you are already in
trouble. A 44-bit password will protect you from attackers trying to harvest
from a big pool of stolen hashes, or from attackers bruteforcing the login
form on a website. That is not the same thing as "fake security through
obscurity".

As for the problem of strong, memorable passwords that can stand up to offline
attacks, there is still a gap (a 253 bit password made of 11 bit words would
be 23 words long), but I don't think the problem is unsolvable. A project I am
interested in working on when I have time is one that produces very long, but
memorable high-entropy passwords with rigorously quantified entropy by
generating evocative, grammatically structured sentences, using a carefully
selected word list and a set of mad-libs style templates.

So to get a ~256 bit pass phrase, you might be left to type out a 50 word
poem. It would take _effort_ to memorize, but it would be reasonably doable,
whereas memorizing a random 39 character password is extremely difficult for
most people.

Moreover, since you'd be working with a limited set of words and grammatical
constructs, the password entry form could have robust auto-correction so that
typos and spelling errors wouldn't be a significant problem.

------
mbesto
_Complexity Trumps Length_

Question for the smarter people out there. If everyone started using passwords
like "donkey computer watch" would this mean that this format would then be
much easier to crack as opposed to xy7*hdkSD

Security is a bit of game theory right?

~~~
aiiane
It actually wouldn't, because the entropy doesn't rely on the attacker not
knowing the general format - it relies on the number of words available as
choices.

~~~
T-hawk
English has roughly 100,000 words, so that password scheme has 10^15
combinations. Suppose the latter scheme incorporates the 96 printable Ascii
characters. log96(10^15) is 7.5, so yes the latter scheme gets ahead on
entropy at 8 characters or longer.

But it's not a question of maximizing entropy. It's a question of maximizing
entropy _relative to the human brain's ability to remember it_. The brain
handles words as single units, so it's a lot easier to remember three of them
than eight or more arbitrary characters.

~~~
aiiane
I go by the xkcd standard of 4 words, though that doesn't change the math,
just the numbers.

------
josefresco
With advice like this seemingly contradicting other seemingly sound advice and
the debate taking place here at HN it's no wonder regular people (and geeks)
have trouble deciding what is and isn't a secure password.

------
eterm
Another myth: 20% of root passwords are now exactly
"CorrectHorseBatteryStaple"

------
pandog
I like how Myth 1 tells us long passwords are better than complex passwords
then Myth 3 complains that Microsoft rate the long but non-complex password
"jjjjjjjjjjjjjjjjjjjjjjjjjjj" highly

~~~
corresation
They aren't contradictory. While this is, as someone else stated, a "fluff
piece", neither b4#L or aaaaaaaaaaaaaaaaaaaaaaaaaaa are necessarily secure
passwords. It's a gradient.

Having said that, does any cracker even try for something like
jjjjjjjjjjjjjjjjjjjjjjjjjjj? If I were trying to brute force password, I would
think that such a password would be relatively safe simply because it's such
an irregular pattern.

~~~
jere
>Having said that, does any cracker even try for something like
jjjjjjjjjjjjjjjjjjjjjjjjjjj? If I were trying to brute force password, I would
think that such a password would be relatively safe simply because it's such
an irregular pattern.

Here's my response to that: <https://news.ycombinator.com/item?id=5546741>

tldr: I could try all repeating characters so fricking fast it would be worth
it to build into a cracker.

~~~
corresation
_tldr: I could try all repeating characters so fricking fast it would be worth
it to build into a cracker._

In the context of this discussion, of course we'll all say that. Does any
actual cracker program try for that, though? Not to my knowledge.

~~~
jere
Sorry for the back of forth here, but I'll try to make this the last comment:

 _Some_ people are using all repeating characters if they can get away with
it. ESPECIALLY because articles like this keep hinting that they are decent.

It doesn't matter how small this percentage of people is. The time it takes to
check against it is infinitesimal and the reward is nonzero. If I were
building a cracker, I would do it and not just because it's the topic of
discussion.

~~~
corresation
Clearly I'm not making the argument that jjjjjjjjjjjjjjjjjjjjjjjjjjj is a
recommended password. Of course it isn't.

Use a long, complex password. Period.

However _practically_ we know the history of password crackers, and while it's
easy to look at specific examples given and say "Oh I would totally crack for
that", in most general cases they wouldn't be cracked. On the flip side,
passwords that are dictionary words following by numbers and or punctuation
are cracked because they are exactly what people migrated to once complexity
rules were implemented.

