Comment by Niten | Hacker News Reader

Comment by Niten | Hacker News Reader

Parent Full thread

Respectfully, you are flat out wrong. This "entropy check" doesn't prove what you think it does.

This password strength test is attempting to estimate the entropy of given passwords under the assumption that it is a word roughly obeying the character distributions of English text, using Shannon's approximation. It does not apply to randomly generated passwords, which violate these assumptions, as described in Appendex A of the NIST plublication linked on that very site.[1] As that document describes, the entropy of a randomly (not user!) selected password is not estimated in this manner, but calculated according to the same formula I provided: H = log_2 (b^L), where b is the number of letters in the alphabet (95) and L is the length of the password. (If the password had any less entropy than that, then by definition it would not have been pseudorandomly generated!)

Additionally, the algorithm employed by this site does not take into account that an intelligent password cracker is capable of exploiting the construction of passphrases.

In other words, you've taken an algorithm designed to approximate the entropy of a user-selected password and misapplied it to both randomly-generated passwords and user-selected passphrases. The fact that the algorithm is able to give you a number for these inputs does not mean it is any valid indication of how difficult such a password or passphrase would be to crack.

[1] http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1...

EDIT: But you're right that passphrases can be easier to use by people. I personally think a password manager like keepass / lastpass / etc. is a better choice than trying to select a memorable password, though.

First, all this is beside the point. Evernote hasn't understood the concepts of either entropy or human chosen passwords. Rejecting my passphrase and accepting "abc123" is wrong. That's my original post, and that's what you objected to. Computer generated random passwords that nobody's going to use on their mobile phone Evernote client, simply don't figure into normal human use.

Our job is to recommend things that can help real people use tech more safely.

> "the entropy of a randomly (not user!) selected password is not estimated in this manner, but calculated according to the same formula I provided: H = log_2 (b^L), where b is the number of letters in the alphabet (95) and L is the length of the password"

Yes, I'm aware of that. Using that site's check, "correct horse battery staple" comes out weaker at 104.2 bits, so I listed that weaker "lower bound"[1] for that phrase. I'm happy to use whatever formula comes up with less entropy for reasons discussed in [1].

I also don't care when sharing with less technical users if it's exact. I care if I can point them to a URL that gives a reasonable approximation, which that "quick check" does. For users who want to do math, I listed both approaches:

> 1. Quick entropy check: http://rumkin.com/tools/password/passchk.php

> 2. Manual entropy check: http://www.wolframalpha.com/input/?i=log_2%282048%5E4%29

The "manual" check is pre-filled with your suggested formula. It's interesting to compare the entropy check to http://www.passwordmeter.com which I think users will "solve" as if it were a password meter puzzle, in very predictable ways.

Meanwhile, to an attacker trying the whole character space, "correct horse battery staple" is log2(27^28) or 133.1 bits of entropy. And if you use H = log_2 (b^L) on the passphrase that Evernote wouldn't accept, it comes in at 188 bits of entropy.

In any case, the approximation is a more conservative "lower bound" than the formula you're suggesting as applied to character set ^ length.

> I personally think a password manager like keepass / lastpass / etc. is a better choice than trying to select a memorable password, though.

I agree. And I use 1Password and generate random passwords.

Btw, the two truly random passwords from 1Password (equivalent of keepass, lastpass, etc), if working with the H = log_2 (b^L) formula, give only 98 bits and 101 bits. Again in their case, the "quick entropy check" URL gives lower numbers, meaning it's a remains a reasonable "lower bound" check for casual users who don't grok formulas.

I tell non-technical family members and friends who can't be bothered with password minders to use sentences meaningful to them and unlikely to be in a book.

    This phrase is definitely not in the dictionary! : 227 bits or 286 bits

That's a pretty good password that my Mom can remember.

--

1. lower bounds: http://subrabbit.wordpress.com/2011/08/26/how-much-entropy-i...

While "This phrase is definitely not in the dictionary" is true, every component is. If this sort of password became popular brute forcing passwords would just start using whole word combinations when cracking passwords. i.e a word becomes the equivalent of a character (though from a larger set of characters).

Also wouldn't a hash of a long passphrase be longer? (I am completely ignorant the details of hashing algorithms)... so if I'm cracking a table of hashed passwords, I could set a "passphrase" cracker on hashed passwords of above average length?

No, the hash is always the same length, a single character and a 4GB movie will generate a hash of the same length (using the same hash algorithm (md5, sha512, etc). I've casually read about it, I think that is the point of the hash, to take an input of any size or length and represent it as a fixed size.

The problem with this is hash collisions, weaknesses found in hash algorithms can make it so attackers could generate files to match another files hash (or password or w/e). I think the idea is that they create a harmful file, then add null characters or w/e so the hash algorithm will generate/assign the two different files the same hash.

The key idea behind any hashing algorithm is to take inputs of any length and turn them into an output of a fixed length.

Different problem domains have different additional requirements: password hashes want to minimise collisions (multiple inputs hashing to the same output), checksums want to make similar inputs produce wildly different outputs, hashtable/dictionary/map key hashes want to create an even distribution of outputs etc. But the thing common to all hashing algorithms is the output is the same size.

Reply on news.ycombinator.com