
Why the password "this is fun" is 10 times more secure than "J4fS!2" - joshwa
http://www.baekdal.com/tips/password-security-usability?
======
ianferrel
The author relies on the assumption that one can try 100 passwords per second
(or, fewer, in the case of an extra delay), but that doesn't correspond to
real-world security breaches.

The danger of having an insecure password is not that someone will bombard the
server with login requests. That can easily be detected and stopped by even
the most cursory of server security. The danger is that they crack the server
and get the list of password hashes, at which point the time to crack a
password is dictated by the hardware at their disposal and the hashing
algorithm. Your server capacity or timeout protocols are irrelevant.

So, the 100 attempts/sec number is essentially a fiction. It applies only to a
manufactured threat. The real threat is much worse, which means that a
password like "this is fun" is not reasonably secure.

~~~
asharp
To be more specific they are dictated by the hashing algorithm and how it is
set up.

Say you have something like a straight md5/sha256/etc. It's fairly likely that
there exist rainbow tables that will insta(for some reasonable value of insta)
crack any reasonable password.

On the other hand, if you use a salted hash you arn't vulnerable to rainbow
tables, but an attacker can still try an altogether silly number of passwords
per second given enough hardware. (or again, more specifically GPUS against
most common salted hashes).

On the other other hand, if you use a memory hard key derivation function
(scrypt/etc.), you can quite easily set things up such that even with a
ridiculous amount of hardware it is infeasible to launch any sort of attack.
The problem then, is that the harder you make it for attackers to attack your
passwords, the slower normal logins are for you, affecting scaling.

So at the end of the day you need to weight off how much of a problem this is
in the specific circumstances you are in which will then dictate the solution
you can provide.

~~~
jarin
Bcrypt is a good hashing algorithm to use, as you can tailor the difficulty
level to find a good balance. A 100ms hashing time probably won't make much of
a difference as far as scaling goes (unless your users are actually doing the
login process multiple times per day), but it makes a huge difference in how
long it takes to brute force.

~~~
Locke1689
Everyone should just use bcrypt, period. (Or scrypt if you follow and trust
cperciva)

------
tel
As I wrote in another comment, high entropy passwords by definition must be
hard to remember. It's not strictly true, but it definitely refutes the title
of this submission.

While I think this post is rather optimistic in its calculations — using
maximum entropy distributions, for instance — it does bring up a good point:
_Personally memorable nonsense sentences_ are _rather high entropy._

Actual practical guessing is not pure distribution entropy but instead closer
to the KL divergence since an intelligent brute force guesser has to make
assumptions about the password distribution in order to reap benefits. If your
password comes from an expected distribution (letters in English words, words
in English sentences) you're losing a whole lot of potential entropy, traded
for particular memorability.

If you can hedge between those bets, though, you're in a good place. "this is
fun" is not actually terribly secure compared to "J4fS!2" unless you're
actually attacked by a uniform dictionary brute force search. "slurping
radicals debilitate enzymatically" is super high entropy and quite likely
easier to remember than "J4fS!2".

~~~
tzs
I once did the following for a password that I wanted to be able to remember,
but that I wanted to be very secure against attack. It was easy to remember,
yet very effective. How does this fit into the entropy vs. rememberability
thing?

1\. Take a 100x100 binary matrix, initialized to 0.

2\. Change some bits to 1, in a pattern that I memorized. It was just
something simple, like my initials in dot-matrix form.

3\. Apply Conway's Life cellular automata rules to the matrix, with no wrap,
doing 108 iterations.

4\. Read out the final state of each cell row by row, as a an ASCII
representation of a binary string of 10000 bits.

5\. Run that through MD5. Iterate this 1960 times.

6\. The final MD5, as an ASCII representation of a 128-bit hex number, was my
password.

I did _NOT_ have any of the software for this on any computer. Whenever I
needed this password, I'd write a Life program, enter my memorized pattern,
run it, do the MD5 stuff, and then delete the program.

Effectively, my password was the combination of the Life algorithm, the size
of the input, the input pattern, the number of iterations to run of Life, and
the algorithm for converting the final Life state into an ASCII password
string.

There seems to be a lot of entropy here. Yet it was pretty easy to remember.

~~~
jerfelix
Let me guess, you're a 50-year old Libra.

~~~
tzs
I assume you guessed 50 from the fact that I iterated MD5 1960 times so assume
that was my birth year. That is correct.

I don't see how you (incorrectly) guessed Libra. If you took the 108 as the
108th day of the year and assumed that was my birthday, that would be April
18th, which would be Aries. If you took it as meaning January 8th, that would
be Capricorn. Did you assume it was 10/8? That would give Libra.

Anyway, the 108 is not a date. It refers to Math 108, an undergraduate math
course at Caltech that bestows a curse upon those who take it. Forever
afterward, the number 108 starts appearing in their lives more than normal.

One girl I knew there went so far as to build a digital clock that held 1:07
for two minutes so that she would stop seeing 1:08 on her clock.

~~~
billforsternz
+1 and my nomination for the Dr Sheldon Cooper ubergeek of the month award
(the combination of the bizarre password story and the 1:07 digital clock is
unbeatable in my view)

------
patio11
The danger with semantically meaningful passphrases is that they have a _lot_
less entropy than you think they do. I still use them for everything, but it
is something to be aware of. (You can get more by e.g. padding it with a
number, doing the usual l33tspeak tricks, etc.)

~~~
Florin_Andrei
As a purely theoretical question - if they are _usual_ tricks then wouldn't
they also exhibit low entropy on some level?

~~~
kgo
Lower than a totally random password. Higher than a readable password without
leetspeak.

------
juiceandjuice
Assume there are 7500 very commonly used english words. A three word sentence,
all in lower case, would yield 421 Billion permutations. Let's say, of those
421 billion permutations, which don't tense or plural nouns about 1 in 5 are
familiar english language constructs, which drops down to around 20 billion
permutations. In this case, if we took all capital letters, all numbers, and 6
punctuation characters, we'd end up with ~67 unique characters, for a combined
82 billion permutations.

Furthermore, like Richard Feynman discovered in Los Alamos, you could narrow
down the possibilities of combinations if you know something about a person.
You could probably build profiled dictionary attacks and reduce possibilities
a lot.

So, is it more secure? No, it's _maybe_ equally secure, but it would
completely depend on the attack. A combination of capital letters would
probably be more secure though.

~~~
ezy
One obvious solution: Don't use english, and don't use standard word order.

~~~
qjz
Except your recommendation reduces available entropy. It would be better to
randomly mix words from multiple languages and disregard word order. No matter
what algorithmic approach you use, you need to exclude results that are
cracked easily by existing methods.

------
cool-RR
One advantage of gibberish passwords like "b923F$5mvA" is that if someone
looks at your fingers while typing them, he'll have a hard time figuring them
out from your keypresses, whereas if you typed "this is fun", it would be much
easier.

Ditto for when someone has a visual glimpse of your password which is only a
few seconds long. (e.g. someone looked at your laptop screen while you got an
email with your password from an irresponsible website.)

------
jjcm
This should be fairly obvious to anyone who's done any sort of combinatorics -
you're saying that a 10 character password using symbols and lower case
letters is more complex than a 6 character password using 36 more characters
in the character pool. Anyone who's even glanced at password complexity
research will be able to tell you that. To break down the numbers though, a 10
character password using lowercase letters and symbols (spaces) has
30155888444737843000 possible combinations. A six character password has
735091890625 combinations (around 1/4000th of the complexity, assuming a brute
force approach). While the author also takes into account the possibilities of
using a dictionary attack, you can't really tie a number to the search space
for that. It depends on the breadth of what the program will go to. Will it
check alternate spellings (color/colour)? Will it check for apostrophes?
Foreign languages? Etc.

A while back I wrote a small piece of JS to demonstrate to some people the
complexity growth in passwords. Some people didn't believe me that
asdfasdfasdf was more complex than Fc34!j_, and this was the end result. Feel
free to play with it. The source is rather simple as well:

<http://files.jjcm.org/jspass>

------
synnik
There is a huge logic gap here. He is comparing 11 characters passwords to 6
character passwords. The difference in length also will account for a
significant difference in the time required with brute force.

I think what he is trying to show is that is that the lower security of using
multiple common words on a password with 11 characters is still greater
security than a random 6 character password, and still quite acceptable.

~~~
alexqgb
Actually, I think that's his point - by using a longer passphrase instead of a
shorter passcode, you get something inherently more secure AND more memorable
(added bonus: no post-its, which means one more layer of security).

------
iuguy
It's interesting. The author shows some fundamental misunderstandings and
makes assumptions that are not necessarily based on real-world situations to
present an idea that longer strings with more recognisable characters (e.g.
passphrases) are better than shorter strings with larger keyspaces. If you
pick two data points you can actually fiddle with the numbers to present
either side of the argument as the truth. For example:

A full 16-bit unicode 2 character password has 65 536^2 or 4,294,967,296
permutations to work through.

A lowercase alphabetic password of 6 characters in length has 26^6 =
308,915,776 permutations.

Of course there's a tradeoff involved, and that tradeoff is what IT
departments try to manage, with mixed success. It's easier for the software to
determine whether or not the password contains methods of increasing the
keyspace than whether or not the user has typed out a 200 character long
series of 'A' characters, so that's what they use. I don't know whether or not
increased length has a higher risk of collisions for some algorithms (that's
tptacek territory, not mine). Over time, software products have been guided by
best practice standards from organisations like COBIT that define and mandate
complex passwords based on keyspace rather than length alone.

Secondly, there is a difference between an online brute force and an offline
brute force. Depending on the algorithm, with the right kit (or Amazon EC2
instances) you can get billions of hashes per second to crack a password hash
offline. At that point your increased length only matters if the attacker
doesn't know about the complexity. The samples provided are terrible as
they're all lower case with a space at most. This is the poor end of the
trade-off. To brute force a SHA-1 hash of the word 'sum' on my 2 year old
laptop takes less than a second.

Online brute forcing (e.g. brute forcing a web form) is generally something
you're not going to do if you're looking to compromise a web account, unless
it is a specifically targeted attack (e.g. the user is an admin or a specific
person of interest). In these situations your brute force rate is dependent on
your network throughput, the application's ability to respond to concurrent
requests and any other factors that may affect it (such as any monitoring
system). Your web application on a linode slice will probably choke out
between 40 and a hundred attempts per second (and you'll notice it unless
you're blind or have no performance reporting). If you can get past the
automation detection in larger sites, like Amazon, Google, Twitter etc. you'll
probably be able to go much, much higher. For this reason, web site brute
forces tend to be dictionary based, or at most on dictionaries and a number.

Ultimately when choosing a password you need to consider what you're defending
against. If you own the box or the app, chances are you trust the defences. If
you're going to change the password every few months then maybe you will
choose a weaker password. If you don't own the kit and you're not intending to
use the password, then use a tool such as Keepass[1] and generate the
passwords yourself. That way it doesn't matter what J Arthur Random says on
the Internet, you won't need to remember the passwords at all.

[1] - <http://keepass.info/>

~~~
neuroelectronic
Right, but to put it simply, character count is the only metric that matters.
If your password is a sentence that's 44 characters long, then you're set.

~~~
anthonyb
No, goddamnit! The search space of possible passwords is the metric that
matters. This is why people should not be rolling their own password schemes.

27 possible chars * 16 length gives 27^16 combinations, or about 8.0 * 10^22
combinations. (Although much, much less in practice because you're using
common english words separated by spaces.)

Printable characters, including punctuation like { } | & etc, gives you 95
characters, for 4.4 * 10^31 combinations - about fifty million (50,000,000)
times larger.

Also, the main attack (which the article misses) happens offline, where the
bad guys have compromised a system and downloaded all of the password hashes.
In that case, they're only limited by the hardware that they can throw at it -
FPGAs and high end graphics cards can check stupid numbers of hashes per
second. <http://nsa.unaligned.org/> is from _2007_ , and will check 800
passwords * 64 chars * 8 length in about a day.

------
merloen
In my 25M word corpus, "this is fun" occurs 23 times. There are only 94,000
trigrams that occur more frequently.

Therefore, you should be pessimistic, and consider the password "this is fun"
less safe than passwords in the shape [a-zA-Z]{3}, like "tsP", of which there
are 140608.

Assume attackers know the algorithm (e.g. three common words, one 7-letter
word in l33tspeak, a 6-letter string of random ascii characters) but not the
parameters.

------
jasonwatkinspdx
The most useful thing we can do as web developers:

\- support very long passwords, so that users can use pass-phrases if they
like.

\- use bcrypt or the like for storage

\- do not create easily cracked side channels, like a fixed set of "security
questions" for forgotten passwords

~~~
jerfelix
Forget "security questions" altogether. We've gone to a set of "insecurity
questions". It makes people smile when they've forgotten their password.

    
    
        "Do these jeans make me look fat?
        "Why is everyone staring at me?"
        "Is there something in my teeth?"
        "Are they talking about me?"
    

... yes I jest, but that would be cute (and serve no practical purpose).

------
onedognight
"this is fun" has structure and I suspect is an easy password to guess from
the pool of all three word passwords. Just like using a dictionary is better
than brute force, trying common words that usually go together when guessing
three word passwords is much better than trying all three word passwords. If
Google were to write a "word" password cracker using their data trove, I
suspect "this is fun" would go down early. Likewise putting spaces between
words would be to the Google cracker like adding a number on the end of a
dictionary word is to a standard cracker.

------
LiggityLew
What about moving away from semantics (easy to remember words) and change to
patterns on the keyboard? That's how I handle my most secure passwords.
Patterns on the keyboard using all the keys and combinations of shift create
passwords that are easier to remember than a random length string, and can
become quite long (>8 chars).

------
ig1
No it's not. If I was brute forcing a password these days, I'd use the google
ngram database, and "this is fun" and pretty much any other memorable phrase
would fall pretty quickly.

~~~
glenjamin
Would you do that before or after your dictionary attack? Or brute force
character ngrams? Or pure brute random chars? There's a fair few responses
pointing out that it's not a hugely uncommon ngram, but the known search space
in this case is just "a password field", the application/organisation's rules
might tell us min length, or if we can discount no numbers/symbols.

Time between events _should_ be limited by either the app's login function or
a suitably expensive hashing function (whose algorithm will have to be known
in the case of a DB dump)

------
dvdhsu
I refuse to believe that there are no tools that can dictionary attack
sentences.

~~~
ernestipark
Using a grammar and a dictionary of common words I can see attacks on 3 or 4
word passwords being somewhat feasible although I should do some back of the
envelope calculations.

~~~
mdemare
An easier way is to use n-grams. You can download 3 and 4 word n-grams from
google here: <http://ngrams.googlelabs.com/datasets>

There are roughly 32 billion of google 4-grams.

~~~
merloen
Those are unique per year, so the phrase "a simple but potentially" is counted
many times. There are about 600 million google 4-grams, slightly more than
there are 4-character ascii strings.

Summing up, a meaningful 4-word phrase, is, in the terminology of the article,
"risky".

My advice: use generated passwords, and apps like 1password to remember them.

------
stretchwithme
hmm, perhaps I'm missing something, but shouldn't systems just not allow you
to attempt to login so much and so frequently?

I guess these systems do get hammered by so many improper attempts and you'd
risk blocking the actual account owner. But if a billion attempts are made
from the same ip in an hour, shouldn't that be considered suspicious?

Personally, I like what Google's doing with the two-step verification. That's
probably where security should be going.

------
Ratufa
Good "dictionaries" for doing on-line brute-force attacks don't just contain
words, they contain likely passwords. Guidelines for choosing good passwords
should point this out. For example, something like "J4fS!2" is a much much
more secure password in terms of protection from on-line attacks than
"letmein" or "chang3m3" or "tryandguessthis" or "password123" or "root!@#" or
"b4ckm3upsc077y". All of those passwords are actual passwords taken from the
list used by an SSH brute-force password cracker.

Because people aren't random when they choose words to remember (e.g.
"beavisandbuthead" is also on that list), a better set of password-choosing
directions would provide instructions one how to add some additional
(pseudo-)randomness to passwords that are being created. The classic "pick a
phrase, take the first letters + punctuation" method is one way to do that
("pap,ttfl+p" is a somewhat strong password), and it's not hard to think of
other password generation schemes that also create strong passwords.

------
mcorrientes
Using multiple words or even sentences as password (as described in the
article) doesn't even work always, there are too many websites or application
which have a password length limit.

I recommend to use a password manager, KeePass is quite good.

Good password manager should be able to easily generate a new strong and
complex password every time.

Remembering only one password and getting rid of the laziness of choosing
always the same password is another advantage too.

Even if a website that stored your password in clear text and someone hacks
the website, you shouldn't have to worry about other applications or services
you may have used with the same password.

My personal rule is to choose unique strong passwords (alphanumeric and
symbols) with at least 9 chars.

Brute forcing a password with 8 chars was with my 5870 no big deal at all, but
cracking a password with 9 chars is too expensive (ec2 gpu) or takes to long
for the usual hacker.

If someone really brute forces my password, with gpu and a cluster support,
damn, than he really deserve it.

But that's just my two cents.

------
EGreg
He forgets one of the easiest ways of getting people's accounts:

<http://xkcd.com/792/>

------
presto8
The title is a bit misleading. The passphrase "this is fun" may be 10 time
harder to brute-force than "J4fS!2", but both are hard enough that nobody
would bother trying to brute force attack them. So they both are equally
acceptable. I personally would rather type "J4fS!2", and here's why:

We use PGP Whole Disk Encryption at my company. The passphrase strength
requirements are quite strict. It took me about two dozen attempts before I
found a password that it would accept. The password was something along the
lines of what the article is proposing, five short English words arranged in a
sentence (about 25 characters long). This was acceptable to PGP because the
software prefers longer passphrases with less entropy per character over short
passphrases.

The problem is that it's quite hard to type this long passphrase in when all
you can see on the screen is stars or dots. The longer a passphrase is, the
higher chance there is of introducing a typo. A shorter passphrase, mixed case
and with symbols, is, at least for a programmer, easier to type, especially
with muscle memory.

In the case of PGP Whole Disk Encryption, they obviously realized this since
you can press the tab key to enable showing the password in plaintext as you
type it. I always do this because it increases the success rate of my password
acceptance quite a bit.

On an unrelated note, it seems that a far bigger security risk on the Internet
is the use of the same password on multiple web sites. If you use "this is
cool" on ten different sites, then you are opening yourself up to serious
vulnerability if one of the sites is compromised. Using a hash of a common
password with the domain name provides a lot more security, but the simple
implementations available today produce passwords that are short with mixed
case and symbols versus long strings of words. But since the only sane way to
use this approach is with a password manager, extension, or bookmarklet
anyway, this doesn't seem to be a major limitation.

But having to create and remember short three to five word passphrases for
dozens of web sites would be a daunting challenge!

------
swaits
This person is just.. confused, to put it nicely.

My password system is detailed here:
<http://news.ycombinator.com/item?id=2431480>

It's secure, passwords are never stored, and it's not based on any false
premises.

------
pronoiac
I think dictionary attacks are a far more common attack profile than looking
for written down passwords. Also, pointing out common passphrases is a good
way to ensure that passphrase checking makes it into later iterations of
password cracking.

------
tzs
If site X suggests to users that they use pass phrases consisting of common
words chosen at random, then "this is fun" is not very secure. A brute force
attack using /usr/share/dict/words found on many Unix systems would take about
the same effort as a brute force attack on an 8 character random password
where characters are drawn from upper case, lower case, digits, and common
punctuation.

You'd actually break most people's common words passwords using smaller word
lists, say the 4096 most common words. Three words from the top 4096 chosen at
random gives a password equivalent to a little under 6 characters of mixed
case/digits/punctuation.

------
jitbit
I wonder how many people will use "this is fun" as their password after
reading this...

~~~
evoltix
This article was written 3 years, 8 months, 4 days ago. I'm pretty sure
there's been plenty of time for "this is fun" to propagate through the masses.

Also, as stated in his The Usability of Passwords - FAQ
(<http://www.baekdal.com/tips/the-usability-of-passwords-faq>):

 _Q: So, are you saying we should use "this is fun" as our password?

A: No, I'm saying that you should use a 3+ word pass phrase as your password.
Something that isn't linked directly to you or your immediate interests. So
don't choose the names of your three kids._

------
EGreg
In <http://qbix.com> , we have implemented passphrases out of the box for all
of our apps.

Try signing up there. You will find that the passphrase suggestions are quite
nice. To obtain them, I took three random words, searched yahoo news for those
words, and for each result, chose 3 contiguous words and presented it as a
passphrase suggestion.

In the event that Yahoo is unreachable, our server generates one of 50 million
unique phrases from ADJECTIVE NOUN VERB NOUN. I would say this produces
greater entropy than if you left people to choose their own passphrases, even
if they don't copy our passphrases exactly.

------
barmstrong
One benefit he didn't even mention: keyloggers

Someone scanning a keylogger file might not even notice "this is fun". It
doesn't look like a password.

The only time someone has gotten my password was actually from a keylogger
when I logged into Facebook at a hostel while traveling.

Pro tip: Another way to defeat those is using the virtual keyboard in windows
to "click" your password in. I do this while traveling now.
[http://www.microsoft.com/enable/training/windowsxp/oskturnon...](http://www.microsoft.com/enable/training/windowsxp/oskturnonuse.aspx)

------
torstesu
1\. Construct a complex password key with a minimum length of 8 characters,
e.g -Kr/2.pq4

2\. Make an algorithm based on the URL. E.g. news.ycombinator.com a) Take the
last 4 characters in the URL, excluded the domain suffix: ator b) Shuffle the
letters based on your algorithm: orat

3\. Combine the password key and the output of your algorithm: orat-Kr/2.pq4

4\. Always enjoy individual, secure and easy to remember passwords for any
services.

The algorithm you use can be more complex, e.g. adding characters in between,
but the basic idea should be explained.

~~~
jjcm
A few years back I got heavily into password cracking. As part of it I sniffed
a bunch of people's passwords in coffee shops, as well as other black hatty
things that I'm not proud of (though I will say that I learned tremendously
from them). While these pattern based passwords work nicely to deter automated
systems from grabbing your password after a site compromises your password,
they dont stand to the test of human eyes. I had several people's passwords
who used similar tactics, it wasn't hard to figure out the pattern. My point
here is this: don't rile yourself up about having bulletproof passwords. It's
good that you do it, but don't mandate it if you're the head of a company. No
password is bulletproof - if someone wants it hard enough, they will get it.
Figuring out a pattern based password is only another breadcrumb to follow.

------
jarek
"None can remember a password like "J4fS<2", which evidently mean that it will
be written on a post-it note."

That's bullcrap. Few _will_ remember this password, but most _can_ if they
try. My work domain password is over 8 characters in this level of complexity
and it took me about 10 minutes to get used to typing it, a day to fully get
it into muscle memory. If you ask me what my password is, I'd have to type it
out.

------
vshlos
I started writing a response, but then it got too big. Basically the 5 second
timeout is a bad idea because its implementation is not worth the effort.
<http://oim.ae/gx8qMD> for the reasoning.

But the other thing, use UTF8 high value characters. Or simply learn Russian
and use a password from russian words.

------
troyhunt
It's a bit hard to know where to begin responding to the number of
inaccuracies in the original post. So here's a complete summary:
[http://www.troyhunt.com/2011/04/bad-passwords-are-not-fun-
an...](http://www.troyhunt.com/2011/04/bad-passwords-are-not-fun-and-
good.html)

------
billmcneale
Another positive aspect of sentence passwords is that they are more likely to
survive a keylogger attack.

------
meric
Doesn't anyone use code for password?

    
    
      {login(url='google.com',user='meric',password='sun');}

------
xilun0
The author either knows basically nearly to nothing in computer security and
password bruteforcing, or knows stuffs but miserably failed to _properly_
communicate the hypotheses used (he did communicate some of his hypotheses,
but not in an appropriate way that would have rightly prevented the general
public from making password choices based on this article while under
radically different conditions) and caveats to take into account when
interpreting his examples.

This article is misleading in the sens the results it gives are only
applicable for very narrow cases, and fast reading it can give the impression
that "J4fS<2" is a "secure" password and that "this is fun" is even more
secure. While this can be true under those very restrictive hypotheses he
used, the fact that it was not prominently warned that those hypothesis should
not be blindly used for basing password choice for random online web sites or
other things makes this article dangerous.

------
contextfree
“In a sense, there is no such thing as a random number; for example, is 2 a
random number?”

------
mleonhard
My undergraduate research addresses this subject:

A Comparative Study of Three Random Password Generators

[http://tamale.net/pub/2007/pwdgen/pwdgen.eit2007.proceedings...](http://tamale.net/pub/2007/pwdgen/pwdgen.eit2007.proceedings.pdf)

------
16s
Speaking of passwords, I believe hackernews account passwords are transmitted
over plain-text HTTP. Even the password reset is plain-text HTTP. Perhaps that
will change soon?

------
tcskeptic
When helping people construct passwords I always guide them to use an acronym
from a favorite line of a song (or bible verse, or poem depending on audience)
and then add a symbol and a number. So for example if you really like Led
Zeppelin you might take the opening line"

"Hey Hey Mama Said The Way You Move Gonna Make You Sweat Gonna Make You
Groove"

and turn it into the password hhmstwymgmysgmyg!8

or "The woods are lovely, dark and deep. But I have promises to keep"

to become: twaldadbihptk$9

Easy to remember, relatively high entropy, pretty good compromise.

~~~
forensic
Your idea was ok until you posted it on the internet.

Since I already had a song-lyric dictionary (that prioritized complete phrases
like you used there, "HHMSTWYMGMYSGMYG" being FAR more likely than just
"HHMSTW") it didn't take long for my program to just grab the first letter of
each song lyric word, stick them together, and then add every possible
combination of symbol->number to the dictionary.

Now everyone you've told to do that will be very quickly cracked if I ever get
their hash.

This is security through obscurity and you just gave away your obscurity by
posting your algorithm on the internet...

------
kodemunky
This article is total crap, the author has very little in the way of security
clue -- how does such nonsense make it onto HN?

------
reedlaw
This is why I like using Passpack. I can store secure passwords securely
without post-its.

~~~
fexl
Also, writing down passphrases can be a good thing. Just not on a post-it.
Keep it in your wallet, or in a safe.

Personally, I like diceware passphrases, written down. The Sign Up screen on
this site rolls a random passphrase:

[https://loom.cc/?function=folder&new_folder=1](https://loom.cc/?function=folder&new_folder=1)

------
jcfrei
the author only considers common words attacks, what about common phrases
attacks? with a database consisting of common sentences, (eg. from reuters)
those passwords could be broken in a much shorter timeframe than claimed in
the article.

~~~
iandanforth
A number of posts have made this point and all seem to have not understood the
article and the FAQ. (Or just like to nitpick)

Let x be a three word pass-phrase of 11 characters and y be a 6 character
standard complex password.

The argument is: x is more secure than y.

You've pointed out a special case where x is also a COMMON phrase, and
demonstrated a counter example to the assertion.

So rephrasing the argument:

Let x be a three word uncommon / nonsense phrase and y be a standard complex
password.

x is more secure than y (and a hell of a lot more user friendly)

I think with that modification the argument stands, and the specific case of
'this is fun' is a mundane distraction from the real point the author was
making.

~~~
jcfrei
with that argument you've reduced the problem to how complex (ie. how long)
said phrase is. the point the author makes, is that the password should be
easy to remember and not a nonsensical phrase (so you don't have to write it
on an insecure post-it). I see you wrote uncommon as well, so I agree there
might be an uncommon yet easy to remember password, even though this somehow
contradicts itself (not subjectively but collectively).

------
Draft_Punk
TL;DR - Password fundamentals...length always beats complexity.

------
spullara
Not any more. Now added to all the password dictionaries.

------
michaelochurch
I would not use "this is fun" _ever_. If it becomes at all common for people
to start using 2- or 3-common words instead of smaller non-word strings,
password crackers are going to start generating 2- to 4-word strings. "This"
and "is" are two of the most common words in the English language. A flat
dictionary approach may take prohibitively long, but a smart password cracker
is going to start with the most common English words, and I just don't believe
"this is fun" will survive very long.

If you use 3 _uncommon_ words with no logical connection ("masquerade
nefarious pulchritudinous") you are probably safe, but if two of your words
are among the language's 100 most common, and your password is a sentence...
bad idea.

A cracker faced with a 20-character password space is going to choose "this is
fun" before "J4fS!2". It's only with a 6-character password space (which is
pathetically small) that "J4fS!2" is likely to be hit.

------
dude_abides
Not any more.

