WordPass – Hate passwords, love passphrases | Hacker News Reader

WordPass – Hate passwords, love passphrases

wordpass.io

23 pointsmarkhemmings51 comments

Don't most password managers have a feature that enables you to locally generate a random, high-entropy password? If you're using a manager in the first place you don't really need to remember it, right?

Also, I've always wondered if it was better, worse, or of no consequence to leave spaces in a passpharse.

It can't hurt.

While a space is considered another character, I've come across more than a few instances in which blank characters are scrubbed from user input fields.

So even if you add one, it's entirely possible that it's ignored.

Yes. I use LastPass, and everywhere possible, I have 20-100 character passwords with uppercase/lowercase/numbers/symbols. They can be generated by the software very conveniently.

You need to remember the passphrase that unlocks tour password manager.

Don't seriously use this tool.

"People shouldn't use passwords that have been generated by a remote service unless they have very very good reasons to trust the tool and the transmission of the data." [0]

Passphrases are generated server-side, and this mines at the heart the security of the system. Are password saved? Yes? No? Who knows?

And you can trust a pair of dice more than an unknown website. Look up diceware on the web and see what I mean.

[0] http://discussions.agilebits.com/discussion/10684/password-w...

I agree with and applaud the use of seriously here ;)

I also thought that particular XKCD comic was obsolete and debunked at this point. Modern password-crackers aren't ASCII-character-at-a-time and know about dictionary words (and all your 1337sp33k substitutions and trailing numbers).

Link to where the XKCD comic was debunked or shown obsolete? Most of the responses I've seen to it were of the form "well, yeah, but you're not gonna remember a hundred different passphrases, it's much better to use a password manager."

"The oft-cited XKCD scheme for generating passwords -- string together individual words like "correcthorsebatterystaple" -- is no longer good advice. The password crackers are on to this trick." -- Bruce.

https://www.schneier.com/blog/archives/2014/03/choosing_secu...

I'm surprised that Schneier would make such a comment. Entropy is entropy, the "difficulty" estimates already except that attackers are fully aware of the method and the dictionary used.

Schneier is wrong if you are doing Diceware correctly. Schneier is more particularly wrong if you consider the point of the XKCD comic in the first place. What normal human anywhere is doing anything other than incrementing the required integer character (if they are even forced to rotate passwords in the first place)?

I think Schneier was assuming here that the user chooses the words himself rather than using a random generator. It's a fair assumption, given that most people won't actively seek out tools to help them make up passwords.

> Passphrases are generated server-side

That was a strange decision to me. There is nothing that can't be done with Javascript on the client, storing the dictionary in the local cache and making the app useful.

If you stripped out the jQuery and everything else and put the randomizing function Javascript right there in the source for everybody to see the page size wouldn't change much either.

I support the conclusion of this XKCD comic, but the math always seemed off to me.

Lets say your dictionary has 100,000 words[0], and your attacker has access to the same list. If the attacker knows that you have chosen four words off of that list, he still only has a 1/4,166,416,671,249,975,000 chance of guessing the right permutation (not combination!). That's less than 2^61, which is certainly very secure.

However, the entropy calculation in the XKCD comic assumes that the characters are uncorrelated with each other, the way they would be if you used a random sequence of characters as your password.

(Of course, this assumes that you choose the words truly (pseudo-)randomly, and not "cherry-picking" permutations that are easy to remember.)

[0] Not unreasonable - /usr/share/dict/words on Ubuntu has over twice as many.

If you compare the number of possibilities per word versus the number of possibilities per character (94 on the commonly used ASCII spectrum for US keyboards), the benefits are clear.

That's not to say that it's impenetrable. It's just making it less convenient to crack which seems to be the name of the security game.

> However, the entropy calculation in the XKCD comic assumes that the characters are uncorrelated with each other, the way they would be if you used a totally random password.

No. A word picked from 2048 word dictionary has 11 bits of entropy, that is where XKCD gets its 44 bits of entropy for four words.

What common user do you know of that has a 100,000 word vocabulary? My point being that a list of the 10,000 most commonly used words would most likely be sufficient to cover most combinations of pass phrases.

It would seem that word length is important too. Between 5 and 8 characters. Wouldn't that drop in half the size of the vocabulary?

No, word length has (almost) nothing to do with it.

XKCD assumes each word has, regardless of length, 11 bits of entropy. It implies that you are picking up each word out of a dictionary of the 2^11 (2048) most common, non-trivial[1] words. And truly, example words are common: correct, horse, battery, staple.

Contrast this with the "classic" example. You pick a single base word from a larger list (16 bits of entropy == 64K-word dictionary) of longer, more complex (troubadour, 10 letter long) words, and then subject it to a number of transformations to pump its entropy another 12 bits.

The key insight of this piece is that attackers have moved over to techniques that make password length a poor estimator of its entropy level. It is the rarity of the base word that makes the lion's share of a password entropy, with length adding marginal improvements, mostly from the increased chances to pack more transformations into it.

This gets lost on the discussion of the comic's main thesis and less subtle insight that it is easier to add entropy by increasing the number of base words than by adding transformations to a single base word.

[1] I am removing trivial words of length < 4 because if you choose from them, you may end up with a password with length between 4 and 12, which may be brute-forced without regard for dictionary attacks now or in the near future. Shortest word in the provided example is "horse" which is weak evidence in favor of this hypothesis.

I would suggest increasing the maximum length from 5. Many applications that don't use iterated hashing schemes like PBKDF2 recommend much longer passphrases for security against brute-force [1].

[1] Off the top of my head: cryptsetup with plain dm-crypt recommends a random English sentence of > 135 characters length (i.e. a passphrase of 27 words at 5 characters per word).

It was a larger number at first, but try remembering say 10 words in a row over a long period of time; most people find that difficult. If hashing is implemented properly (i.e. is slow with a large number of iterations) then passphrases shouldn't have to be that long. And if it isn't, then pretty much anything you use will be as bad as each other (Some people are still using MD5 for example!!) :)

I don't see the harm in leaving the option in, given that for some applications a longer passphrase is critical (not everything can use iterated hash schemes: for instance if you want to deniably encrypt a hard drive partition to look like random data).

EDIT: also, 'explicit' is a nice touch, makes some pretty memorable passphrases, but I hope you're not taking from a small list of profanities, since that would seriously diminish the entropy. Be sure to factor in the (probably) much smaller number of possible 'explicit' passphrases when doing entropy calculations.

Security concerns aside, I don't get it...

It generated "enterlongrangealfredgreeted". How does that help me? I haven't seen a site that would allow for a password like this in a long time. It's too long, it doesn't have at least one cap, one number, and one symbol. So, what good would this do?

> I haven't seen a site that would allow for a password like this in a long time.

I'm pretty sure you are looking at one right now.

Really? 90% of sites I run into don't have those restrictions.

The sites where you care the most about security do: Ebay, PayPal, my bank, all government websites (Canada).

I have always had a problem with this xkcd because most sites would disable your password after a number of bad guesses (making it not really matter that much), and additionally I don't see where 2^44 comes from. Taking the average word length selected and then computing the entropy using the average word length 4 times? Why not use the number of potential dictionary words and raise that to the 4th?

    echo "l($(wc -l /usr/share/dict/american-english|cut -d' ' -f1)^4)/l(2)"|bc -l

    67.44701327930010565796

So we get a better power of 2 and a more accurate estimate. Granted one could filter the word list down to words that people actually know (which exceptional people normally know about 75,000 but most people know only 50,000[1]).

    echo "l(75000^4)/l(2)"|bc -l

64.77841190063187168389

    echo "l(50000^4)/l(2)"|bc -l

62.43856189774724695805

So I guess it's still better but it seems like a pretty big oversimplification to assume a length of word (especially a uniform one) and it shouldn't be that much harder to calculate the actual value. Maybe I did something wrong, I don't know.

[1] http://news.bbc.co.uk/2/hi/uk_news/magazine/8013859.stm

Online bruteforcing is not feasible except for extremely weak passwords or sites with security vulnerabilities. What is feasible is bruteforcing stolen password hashes (think Adobe leak) or say a hard drive encrypted with a memorable password, and this is where secure passphrases come into play.

Or better yet, deterministic public keys like is seen with bitcoin.

True, account should be disabled after x number of bad guesses. But securing against a "brute force" attack for me is more a case of cracking hashes from a db dump. It's easy to churn though vast numbers of hashes in no time at all these days. Here things like hashing algorithm speed, number of iterations, unique salting and original password length all have a part to play.

The comic uses 11 bits per 'common word' to get to 44 (there are 11 little boxes by each word in the comic).

Underestimating that value isn't a bad thing.

While I applaud the nifty tool, we should be trying to get away from single-factor authentication wherever practical. It's also possible that the use of phrases could incur the same mis-use as passwords (common phrases, common words, reusing the same phrase on multiple sites, etc). Passwords just aren't a good idea anymore. (Side note: a lot of password fields i've seen limit you to something like 12 characters; how secure can our phrases be at this length?)

Don't forget that passphrases are also have security uses other than authentication: symmetric encryption of private keys, disk/file encryption, etc. where their use is pretty much unavoidable. Obviously a very long randomly-generated encryption key saved to a usb stick is more resistant to brute force than a memorable passphrase, but you still want to symmetrically encrypt it with a good passphrase to keep it (relatively) secure in case it gets into the wrong hands.

Completely agree. For example, I use two-factor authentication on all accounts that allow me to. Regarding limiting to 12 characters, the sites in question there are putting there users at risk and it's very likely they aren't storing passwords correctly, leaving anything you put in that password box vulnerable anyway.

This is a simple explanation of why passphrasing is better. Please bear with my laymen's mathematics because this isn't my forte:

Let's us XKCD as an example. Your passphrase is correcthorsebatterystaple but since you hate typing out things you abbreviate it to chbs.

In most English passwords, you are limited to the characters visible to you on your keyboard; 52 letters (caps and lowercase), 10 numbers, 32 symbols. That means each piece of your password has 94 possible options. That means there are over 78 million possible combinations to be tried to correctly guess chbs. When you realize that computers can hash through several billion attempts PER SECOND, your password starts to look like a terrible idea.

By typing out correcthorsebatterystaple, you go from 94^4 to 94^25. This is what XKCD points out and it's obvious that this is a big gain.

But it gets better than this...

Let's assume that crackers start to use rainbow tables full of common words used to build phrases like this. Instead of treating passwords by the number of characters, they start hammering on the number of words that are possible.

Instead of increasing the exponent of the perceived slot, you've gone from 94 possible options to however many words there are in the English language. So instead of 94^4, you're dealing with numbers like 250000^4.

This is why security people think passphrasing is better than passwords and why sites like Microsoft that limit you to only 20 character passwords are assholes. It's not the perfect solution, but it will help.

TL;DR: Passphrasing increases the security in your credentials in more ways than you are probably thinking. Do it. DO IT NOW.

The spirit of what you mean are right, but the details are all tangled up.

Example 1: "chbs". 94^4 is way too optimistic. Your upper bound is 26^4, though if you get a smart attacker, he will figure out that 'c', 'h', 'b' and 's' are all more likely than 'x' or 'q' (though less likely than 'e' or 't'), and prune the search tree accordingly. Honestly, it does not really matter because with just 4 chars long, he can afford to just brute-force it anyways.

Example 2: "correcthorsebatterystaple". While much, much better than "chbs", 94^25 is completely off-base. That would imply that you are using all printable ASCI characters in your passphrase. The other figure you mention, 250000^4 is closer to the mark, though it implies you are picking your samples from a 25,000 word dictionary.

XKCD does not make that assumption, it explicitly uses a small dictionary (2048 words) to let it clear that you do not depend on picking "epic words" for the scheme to stand. You can use simple, every day (e.g. easy to remember) words and still come ahead of the other approach.

Most all sites I use (several hundred) have password limitations that would prevent these passphrases from working as they require uppercase, lowercase, special characters and or numbers or length.

Though ultimately, of all the sites people use, they wouldn't be able to remember a special passphrase for each and if they are using the same one for each site that's even worse.

So ultimately it sounds like people should continue to use 1Pass to generate all the special password characteristics but then use this site's ideas as a basis for your single 1Password Master Password. Also maybe for your email account since if you ever lost access to your master password or vault the only way to reset all your passwords may be via email.

or shell alias:

    cat /usr/share/dict/words | awk 'BEGIN{srand();}{print rand()"\t"tolower($0)}' | sort -k1 -n | cut -f2 | head -n 4 | tr "\\n" " "

suggestion would be to find a better word list than the default aspell since that is the entire Oxford dictionary, which isn't as memorable (although it is an interesting way to learn about new words).

Also contains explicit words. Doesn't stop me from using it for myself, but it's not helpful if you are looking to generate passwords for others.

Or, if you have GNU coreutils installed (on linux, for example):

    shuf -n 4 /usr/share/dict/words

Actually this is not such a good idea, this type of passwords is very easy to break with modern dictionary attacks. Just get yourself a password manager and generate really random passwords. If you really have to remember the password then at least try to mix the words with numbers and non-alphanumeric chars.

Reynold (Diceware creator) says:

"Five words are breakable with a thousand or so PCs equipped with high-end graphics processors (criminal gangs with botnets of infected PCs can marshal such resources). Six words may be breakable by an organization with a very large budget, such as a large country's security agency. Seven words and longer are unbreakable with any known technology, but may be within the range of large organizations by around 2030. Eight words should be completely secure through 2050."

http://world.std.com/~reinhold/dicewarefaq.html#howlong

Most websites don't allow passwords longer than 21/30 characters. So getting to 8 words is difficult.

This type of estimates is relevant for brute force attacks, it's very hard to estimate how efficient a smart dictionary attack is. It very much depends on the size of the dictionary used for picking the words and if the words are picked in a truly random manner... which I really doubt because people will probably tend to pick short, common words that are easy to spell and memorize.

Please could you link to a modern dictionary attack that makes a Diceware passphrase weak?

The attacker knows that I use Diceware. The attacker even knows that I have seven Diceware words in my passphrase.

It's still a secure passphrase.

Couldn't you just make a ruleset for this? Might make it a bit easier since it's all dictionary words.

Why does it delete the blanks between the words?

or at least make it black, gray black, gray

Nice touch on displaying the words on hover

"Explicit" option is only option

Yes, it makes the passphrases a lot more memorable. But when there's guaranteed to be at least one taboo word in a passphrase (and it looks like 2+ is likely even with only four words), I think it's reducing the search space too much.

Reply on news.ycombinator.com