14 ms·

Why the password "this is fun" is 10 times more secure than "J4fS!2"

421 points by joshwa 16y ago

ianferrel 16y ago
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.
- ominous_prime 16y ago
  > The danger is that they crack the server and get the list of password hashes This isn't an argument either way. The service poorly handling passwords is even more culpable than the user with poor password complexity. Passwords should never be stored as plain hashes.
  - pavel_lishin 16y ago
    Did he imply that they were unsalted?
    - ominous_prime 16y ago
      No, he did not :\. I was reading into it too much, and inferred he was wandering towards the rainbow-tables fallacy.
- andylei 16y ago
  i think the point is that increased password length can make easy to remember passwords that are more secure than shorter, hard to remember passwords. even though "this is fun" isn't secure in your scenario, its still more secure than the "j63<2a" password in the same scenario.
  - ianferrel 16y ago
    That's true, but the construction of the argument gives a false sense of security. "j63<2a" is more secure than "password" as well, but since they are both effectively useless (as is "this is fun"), we probably shouldn't waste time comparing their relative terribleness. The proper solution to passwords isn't to come up with a slightly longer phrase that can still be cracked in a reasonable amount of time, it's to use a 30-character randomly generated password for each login, and keep them in a privately encrypted password safe of some sort.
    - glenjamin 16y ago
      Except that's a usability nightmare, and the majority of password field (annoyingly) won't accept a 30 char password. I aim to use a short phrase that includes punctuation and a number if required, and to have the sentence be thematically linked slightly to the system I'm logging in to. This produces a long string that meets the criteria and is memorable by following the original train of thought from that led me to form the sentence. This I believe is "good enough" in all scenarios, since I should be able to type it quickly, and never write it down or share it. The only remaining issues are max-length password fields and keyloggers (apparently a parabolic microphone can be used as a keylogger!)
      - gusper 16y ago
        You run the risk of making it a lot easier to figure out your password for other sites once one of them is known though, right? Say you create an account at fakecompany.com where they happily and naively save their passwords in plain text in their database. Wouldn't it be easy for that site admin to then figure out your facebook.com, for example, password?
- phamilton 16y ago
  Your argument does essentially shoot down any merit to 5 second login attempt delays, and a cap on the number of attempts in 15 minutes.
  - asharp 16y ago
    Not particularly. An attack that leaves the attacker with password hashes is rare, as opposed to regular "brute force" attacks of various flavours.
    - queensnake 16y ago
      (Couldn't a hacker have 500 connections and, though trying each only every 5 secs as permitted, still get 100/s overall?)
      - asharp 16y ago
        Only in the case of a very badly configured server.
  - jtheory 16y ago
    Login delays have serious problems anyway. If you include a serious delay (like, "10 attempts to guess a user's password and we lock the account for an hour" or if you lock accounts & require admin unlocking), this is a great way to set yourself up for a quiet DoS. I don't have to bring your server to its knees -- I can lock our any user with only 10 requests, ha ha... If you save the limit in the browser session, well, it's easy to start a new session for each attempt (just don't send in any established cookie). Limiting per IP is a bit stronger, but with large NATs this is still as risk of DoSing. If you use just a small timeout -- like 5 seconds -- that means any individual attempt will take 5 seconds to return. Let's say I submit 100 requests in 100 threads. Will it take 500 seconds to return? Nope -- each thread will take 5 seconds, concurrently, and I'll have the results back in request tine + 5 seconds. Also don't forget that an attacker is not required to choose a single email address and try to brute-force passwords. In fact, it's probably more efficient to take one common password at a time and try likely usernames.
- asharp 16y ago
  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 16y ago
    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 16y ago
      Everyone should just use bcrypt, period. (Or scrypt if you follow and trust cperciva)
    - asharp 16y ago
      It was my understanding, having read the scrypt paper, that scrypt is significantly more secure then bcrypt (hence its existence).
  - notJim 16y ago
    What about using a unique salt for each user. For example, if you use the user's login name. Then, the hacker would have to make a rainbow table for each user, in essence. I think bcrypt is probably still more secure? Or maybe the best would be to combine both.
pronoiac 16y ago
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.
- deleted 16y ago
  [deleted]
this-is-fun 16y ago
good find, I will be changing my password to this is fun pretty soon.
- drivebyacct2 16y ago
  Novelty accounts on HN? Really? I guess I've quickly become a pessimist in the last few days of changes around here but the green on what is presumably new accounts highlights the poor quality of new commenters.
  - saturdayplace 16y ago
    I wondered what might be the reason for that. This makes LOADS of sense. Hi-light new users in threads and your eye is drawn to them. This enables experienced users to easily give constructive criticism, knowing that a poor comment was left by a new user who might not otherwise know the community's mores.
  - deleted 16y ago
    [deleted]
dvdhsu 16y ago
I refuse to believe that there are no tools that can dictionary attack sentences.
- ernestipark 16y ago
  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 16y ago
    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 http://ngrams.googlelabs.com/datasets There are roughly 32 billion of google 4-grams.
    - merloen 16y ago
      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.
- colanderman 16y ago
  I'm willing to bet that the set of 8-character full-ASCII passwords is comparable in cardinality to the set of 8-word sentences, even accounting for Markov information density.
tel 16y ago
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".
- tlrobinson 16y ago
  In practice is a long nonsense sentence of English words really any better than an equally long coherent sentence of English words? Are cracking tools really that intelligent?
  - tel 16y ago
    Maybe not yet, but lots of people are attacking NLP and thus building all the components of cracking tools that are that smart.
  - jtheory 16y ago
    It's not at all about how intelligent the cracking tools are; it's about how unimaginative users tend to be. Let's say the suggestion "use an easy to remember sentence, rather than a short password" gets around. The actual set of easy-to-remember sentences for a large set of users will include some very good ones, but mostly a small set of simple ones, like "To be or not to be", "Seize the day" and so on. The cracking programs don't need to figure out what those are -- they just need ONE password dump from a site with poor security (easy to find, unfortunately), and the analysis is trivial. The other downside of sentences, though, is that even when the average person picks an easy-to-remember sentence, it's still hard to remember exactly how they wrote it last time (upper-case, all lower, what punctuation?), and for poor typists, think about the chances of making a typo (or just forgetting where they were) while typing out all those little stars....
synnik 16y ago
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 16y ago
  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).
- seles 16y ago
  This isn't a logic cap. The 11 character password is easier to remember and faster to type than the 6 letter one, so it is perfectly fair to compare it.
iuguy 16y ago
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/ http://keepass.info/
patio11 16y ago
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.)
- ominous_prime 16y ago
  remember though, the l33t letter replacements are in the dictionaries for common passwords, and used in brute-force algorithms.
  - patio11 16y ago
    True, but increasing the raw length of the password (which passphrases will give you in spades) makes those leetification tricks combinatorially explosive. "apple" has 3 characters (2^3 = 8 variations) for easy leetspeak. "apples" has 2^4 = 16. "applestastegreat" has 2^12 = 4,096. Assuming you don't totally fubar your entropy in the underlying passphrase, you'll end up with something both memorable and infeasible to brute force.
    - ominous_prime 16y ago
      Oh yes, and I do use this in my own passphrases for the added combinational complexity. I just wanted to point out to the naive that using `passw0rd` or `s3cr3t`, they are in password lists that a brute force attack will use. My point that crackers will programaticaly try this was less relevant.
      - nostrademons 16y ago
        You can choose to l33tify different combinations of letters in the password. passw0rd may be in the dictionary, but is p4ssword, or pa$$word? Patrick's point is that there are combinatorially many different ways that you can 133t!fy a password, so they don't really help in dictionary attacks.
deleted 16y ago
[deleted]
- zyfo 16y ago
  I never understood this. Why? I can't imagine this being the bottleneck for a secure password in any realistic situation.
  - g_lined 16y ago
    Because it's not true! Or at least not the way it was explained. The reason to change your password is to avoid the vector of attack where someone gets your password and can therefore use it against you. If you change your password each month, you limit the damage the person can do to whatever they can achieve in that month. Similarly if they have your username and don't have your password, they only have a month to try as many combinations as they can. To say that is is 'the only way' is certainly not true. However, it does help in these circumstances and that's why it is a method which is used - mostly in companies as far as I can tell.
    - kgo 16y ago
      I think corporations are just as worried about employee X willingly giving account info to employee Y, as they are about a malicious attack. Of course the real fix for both scenarios is two-factor authentication. Not something that practically begs the user to either write their password down or append apr-11 to their normal password.
- boredguy8 16y ago
  Using "000" for 3 months then "111" for 3 months isn't secure. So changing a password regularly doesn't make it secure at all.
  - wickedchicken 16y ago
    It's a lot more secure than relying on "000" for 6 months if your server was breached or your PW was sniffed over the wire, or if you use the same (or similar) password on a different site and that PW was stolen/sniffed. Rotating passwords is one of those security practices that (like any legitimate security consideration) is crazy annoying but effective.
onedognight 16y ago
"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.
juiceandjuice 16y ago
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.
- juiceandjuice 16y ago
  I thought about this a bit more and, in reality, the amount of english words used could probably be cut down to less than 1000, which would cut down to 1/400th of my original figure. So no, I don't think it's more secure against advanced dictionary attacks.
- ezy 16y ago
  One obvious solution: Don't use english, and don't use standard word order.
  - qjz 16y ago
    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.
- T-hawk 16y ago
  >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. 82 billion may sound like a lot but it is not. Suppose you had a few multi-core machines that could collectively get up to 1 million crack attempts per second. Now you can crack that password in 82,000 seconds, or under one day.
ig1 16y ago
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 16y ago
  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)
jcfrei 16y ago
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 16y ago
  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 16y ago
    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).
tzs 16y ago
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 16y ago
I wonder how many people will use "this is fun" as their password after reading this...
- evoltix 16y ago
  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 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.
cool-RR 16y ago
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.)
dude_abides 16y ago
Not any more.
contextfree 16y ago
“In a sense, there is no such thing as a random number; for example, is 2 a random number?”
mcorrientes 16y ago
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.
reedlaw 16y ago
This is why I like using Passpack. I can store secure passwords securely without post-its.
- fexl 16y ago
  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
tcskeptic 16y ago
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 16y ago
  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...
stretchwithme 16y ago
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.
jasonwatkinspdx 16y ago
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
- teaspoon 16y ago
  You should also make your sites amenable to password managers that autofill and submit login forms. Bank of America, for example, foils 1Password by spreading login across two forms and using a custom, non-machine-discoverable "submit" button in one of them.
- jerfelix 16y ago
  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).
LiggityLew 16y ago
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).
EGreg 16y ago
He forgets one of the easiest ways of getting people's accounts: http://xkcd.com/792/ http://xkcd.com/792/
torstesu 16y ago
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 16y ago
  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.
merloen 16y ago
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.
swaits 16y ago
This person is just.. confused, to put it nicely. My password system is detailed here: http://news.ycombinator.com/item?id=2431480 http://news.ycombinator.com/item?id=2431480 It's secure, passwords are never stored, and it's not based on any false premises.
jjcm 16y ago
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 http://files.jjcm.org/jspass
michaelochurch 16y ago
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.
EGreg 16y ago
In http://qbix.com 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.
presto8 16y ago
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!
Draft_Punk 16y ago
TL;DR - Password fundamentals...length always beats complexity.
barmstrong 16y ago
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/oskturnonuse.aspx http://www.microsoft.com/enable/training/windowsxp/oskturnon...
meric 16y ago
Doesn't anyone use code for password? {login(url='google.com',user='meric',password='sun');}
billmcneale 16y ago
Another positive aspect of sentence passwords is that they are more likely to survive a keylogger attack.
mleonhard 16y ago
My undergraduate research addresses this subject: A Comparative Study of Three Random Password Generators http://tamale.net/pub/2007/pwdgen/pwdgen.eit2007.proceedings.pdf http://tamale.net/pub/2007/pwdgen/pwdgen.eit2007.proceedings...
vshlos 16y ago
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 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.
spullara 16y ago
Not any more. Now added to all the password dictionaries.
xilun0 16y ago
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.
Ratufa 16y ago
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.
16s 16y ago
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?
jarek 16y ago
"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.
kodemunky 16y ago
This article is total crap, the author has very little in the way of security clue -- how does such nonsense make it onto HN?
troyhunt 16y ago
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-and-good.html http://www.troyhunt.com/2011/04/bad-passwords-are-not-fun-an...

421 points by joshwa 16y ago

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.

ominous_prime 16y ago
> The danger is that they crack the server and get the list of password hashes This isn't an argument either way. The service poorly handling passwords is even more culpable than the user with poor password complexity. Passwords should never be stored as plain hashes.
- pavel_lishin 16y ago
  Did he imply that they were unsalted?
  - ominous_prime 16y ago
    No, he did not :\. I was reading into it too much, and inferred he was wandering towards the rainbow-tables fallacy.
andylei 16y ago
i think the point is that increased password length can make easy to remember passwords that are more secure than shorter, hard to remember passwords. even though "this is fun" isn't secure in your scenario, its still more secure than the "j63<2a" password in the same scenario.
- ianferrel 16y ago
  That's true, but the construction of the argument gives a false sense of security. "j63<2a" is more secure than "password" as well, but since they are both effectively useless (as is "this is fun"), we probably shouldn't waste time comparing their relative terribleness. The proper solution to passwords isn't to come up with a slightly longer phrase that can still be cracked in a reasonable amount of time, it's to use a 30-character randomly generated password for each login, and keep them in a privately encrypted password safe of some sort.
  - glenjamin 16y ago
    Except that's a usability nightmare, and the majority of password field (annoyingly) won't accept a 30 char password. I aim to use a short phrase that includes punctuation and a number if required, and to have the sentence be thematically linked slightly to the system I'm logging in to. This produces a long string that meets the criteria and is memorable by following the original train of thought from that led me to form the sentence. This I believe is "good enough" in all scenarios, since I should be able to type it quickly, and never write it down or share it. The only remaining issues are max-length password fields and keyloggers (apparently a parabolic microphone can be used as a keylogger!)
    - gusper 16y ago
      You run the risk of making it a lot easier to figure out your password for other sites once one of them is known though, right? Say you create an account at fakecompany.com where they happily and naively save their passwords in plain text in their database. Wouldn't it be easy for that site admin to then figure out your facebook.com, for example, password?
phamilton 16y ago
Your argument does essentially shoot down any merit to 5 second login attempt delays, and a cap on the number of attempts in 15 minutes.
- asharp 16y ago
  Not particularly. An attack that leaves the attacker with password hashes is rare, as opposed to regular "brute force" attacks of various flavours.
  - queensnake 16y ago
    (Couldn't a hacker have 500 connections and, though trying each only every 5 secs as permitted, still get 100/s overall?)
    - asharp 16y ago
      Only in the case of a very badly configured server.
- jtheory 16y ago
  Login delays have serious problems anyway. If you include a serious delay (like, "10 attempts to guess a user's password and we lock the account for an hour" or if you lock accounts & require admin unlocking), this is a great way to set yourself up for a quiet DoS. I don't have to bring your server to its knees -- I can lock our any user with only 10 requests, ha ha... If you save the limit in the browser session, well, it's easy to start a new session for each attempt (just don't send in any established cookie). Limiting per IP is a bit stronger, but with large NATs this is still as risk of DoSing. If you use just a small timeout -- like 5 seconds -- that means any individual attempt will take 5 seconds to return. Let's say I submit 100 requests in 100 threads. Will it take 500 seconds to return? Nope -- each thread will take 5 seconds, concurrently, and I'll have the results back in request tine + 5 seconds. Also don't forget that an attacker is not required to choose a single email address and try to brute-force passwords. In fact, it's probably more efficient to take one common password at a time and try likely usernames.
asharp 16y ago
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 16y ago
  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 16y ago
    Everyone should just use bcrypt, period. (Or scrypt if you follow and trust cperciva)
  - asharp 16y ago
    It was my understanding, having read the scrypt paper, that scrypt is significantly more secure then bcrypt (hence its existence).
- notJim 16y ago
  What about using a unique salt for each user. For example, if you use the user's login name. Then, the hacker would have to make a rainbow table for each user, in essence. I think bcrypt is probably still more secure? Or maybe the best would be to combine both.

pronoiac 16y ago

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.

deleted 16y ago
[deleted]

this-is-fun 16y ago

good find, I will be changing my password to this is fun pretty soon.

drivebyacct2 16y ago
Novelty accounts on HN? Really? I guess I've quickly become a pessimist in the last few days of changes around here but the green on what is presumably new accounts highlights the poor quality of new commenters.
- saturdayplace 16y ago
  I wondered what might be the reason for that. This makes LOADS of sense. Hi-light new users in threads and your eye is drawn to them. This enables experienced users to easily give constructive criticism, knowing that a poor comment was left by a new user who might not otherwise know the community's mores.
- deleted 16y ago
  [deleted]

dvdhsu 16y ago

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

ernestipark 16y ago
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 16y ago
  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 http://ngrams.googlelabs.com/datasets There are roughly 32 billion of google 4-grams.
  - merloen 16y ago
    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.
colanderman 16y ago
I'm willing to bet that the set of 8-character full-ASCII passwords is comparable in cardinality to the set of 8-word sentences, even accounting for Markov information density.

tel 16y ago

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".

tlrobinson 16y ago
In practice is a long nonsense sentence of English words really any better than an equally long coherent sentence of English words? Are cracking tools really that intelligent?
- tel 16y ago
  Maybe not yet, but lots of people are attacking NLP and thus building all the components of cracking tools that are that smart.
- jtheory 16y ago
  It's not at all about how intelligent the cracking tools are; it's about how unimaginative users tend to be. Let's say the suggestion "use an easy to remember sentence, rather than a short password" gets around. The actual set of easy-to-remember sentences for a large set of users will include some very good ones, but mostly a small set of simple ones, like "To be or not to be", "Seize the day" and so on. The cracking programs don't need to figure out what those are -- they just need ONE password dump from a site with poor security (easy to find, unfortunately), and the analysis is trivial. The other downside of sentences, though, is that even when the average person picks an easy-to-remember sentence, it's still hard to remember exactly how they wrote it last time (upper-case, all lower, what punctuation?), and for poor typists, think about the chances of making a typo (or just forgetting where they were) while typing out all those little stars....

synnik 16y ago

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 16y ago
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).
seles 16y ago
This isn't a logic cap. The 11 character password is easier to remember and faster to type than the 6 letter one, so it is perfectly fair to compare it.

iuguy 16y ago

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/ http://keepass.info/

patio11 16y ago

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.)

ominous_prime 16y ago
remember though, the l33t letter replacements are in the dictionaries for common passwords, and used in brute-force algorithms.
- patio11 16y ago
  True, but increasing the raw length of the password (which passphrases will give you in spades) makes those leetification tricks combinatorially explosive. "apple" has 3 characters (2^3 = 8 variations) for easy leetspeak. "apples" has 2^4 = 16. "applestastegreat" has 2^12 = 4,096. Assuming you don't totally fubar your entropy in the underlying passphrase, you'll end up with something both memorable and infeasible to brute force.
  - ominous_prime 16y ago
    Oh yes, and I do use this in my own passphrases for the added combinational complexity. I just wanted to point out to the naive that using `passw0rd` or `s3cr3t`, they are in password lists that a brute force attack will use. My point that crackers will programaticaly try this was less relevant.
    - nostrademons 16y ago
      You can choose to l33tify different combinations of letters in the password. passw0rd may be in the dictionary, but is p4ssword, or pa$$word? Patrick's point is that there are combinatorially many different ways that you can 133t!fy a password, so they don't really help in dictionary attacks.

deleted 16y ago

[deleted]

zyfo 16y ago
I never understood this. Why? I can't imagine this being the bottleneck for a secure password in any realistic situation.
- g_lined 16y ago
  Because it's not true! Or at least not the way it was explained. The reason to change your password is to avoid the vector of attack where someone gets your password and can therefore use it against you. If you change your password each month, you limit the damage the person can do to whatever they can achieve in that month. Similarly if they have your username and don't have your password, they only have a month to try as many combinations as they can. To say that is is 'the only way' is certainly not true. However, it does help in these circumstances and that's why it is a method which is used - mostly in companies as far as I can tell.
  - kgo 16y ago
    I think corporations are just as worried about employee X willingly giving account info to employee Y, as they are about a malicious attack. Of course the real fix for both scenarios is two-factor authentication. Not something that practically begs the user to either write their password down or append apr-11 to their normal password.
boredguy8 16y ago
Using "000" for 3 months then "111" for 3 months isn't secure. So changing a password regularly doesn't make it secure at all.
- wickedchicken 16y ago
  It's a lot more secure than relying on "000" for 6 months if your server was breached or your PW was sniffed over the wire, or if you use the same (or similar) password on a different site and that PW was stolen/sniffed. Rotating passwords is one of those security practices that (like any legitimate security consideration) is crazy annoying but effective.

onedognight 16y ago

"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.

juiceandjuice 16y ago

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.

juiceandjuice 16y ago
I thought about this a bit more and, in reality, the amount of english words used could probably be cut down to less than 1000, which would cut down to 1/400th of my original figure. So no, I don't think it's more secure against advanced dictionary attacks.
ezy 16y ago
One obvious solution: Don't use english, and don't use standard word order.
- qjz 16y ago
  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.
T-hawk 16y ago
>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. 82 billion may sound like a lot but it is not. Suppose you had a few multi-core machines that could collectively get up to 1 million crack attempts per second. Now you can crack that password in 82,000 seconds, or under one day.

ig1 16y ago

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 16y ago
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)

jcfrei 16y ago

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 16y ago
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 16y ago
  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).

tzs 16y ago

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 16y ago

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

evoltix 16y ago
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 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.

cool-RR 16y ago

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.)

dude_abides 16y ago

Not any more.

contextfree 16y ago

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

mcorrientes 16y ago

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.

reedlaw 16y ago

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

fexl 16y ago
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

tcskeptic 16y ago

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 16y ago
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...

stretchwithme 16y ago

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.

jasonwatkinspdx 16y ago

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

teaspoon 16y ago
You should also make your sites amenable to password managers that autofill and submit login forms. Bank of America, for example, foils 1Password by spreading login across two forms and using a custom, non-machine-discoverable "submit" button in one of them.
jerfelix 16y ago
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).

LiggityLew 16y ago

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).

EGreg 16y ago

He forgets one of the easiest ways of getting people's accounts: http://xkcd.com/792/ http://xkcd.com/792/

torstesu 16y ago

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 16y ago
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.

merloen 16y ago

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.

swaits 16y ago

This person is just.. confused, to put it nicely. My password system is detailed here: http://news.ycombinator.com/item?id=2431480 http://news.ycombinator.com/item?id=2431480 It's secure, passwords are never stored, and it's not based on any false premises.

jjcm 16y ago

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 http://files.jjcm.org/jspass

michaelochurch 16y ago

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.

EGreg 16y ago

In http://qbix.com 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.

presto8 16y ago

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!

Draft_Punk 16y ago

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

barmstrong 16y ago

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/oskturnonuse.aspx http://www.microsoft.com/enable/training/windowsxp/oskturnon...

meric 16y ago

Doesn't anyone use code for password? {login(url='google.com',user='meric',password='sun');}

billmcneale 16y ago

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

mleonhard 16y ago

My undergraduate research addresses this subject: A Comparative Study of Three Random Password Generators http://tamale.net/pub/2007/pwdgen/pwdgen.eit2007.proceedings.pdf http://tamale.net/pub/2007/pwdgen/pwdgen.eit2007.proceedings...

vshlos 16y ago

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 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.

spullara 16y ago

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

xilun0 16y ago

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.

Ratufa 16y ago

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.

16s 16y ago

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?

jarek 16y ago

"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.

kodemunky 16y ago

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

troyhunt 16y ago

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-and-good.html http://www.troyhunt.com/2011/04/bad-passwords-are-not-fun-an...