It is hard to estimate the quality of that proposed passphrase: because it was not randomly generated.
"banana, dominican, equator, guacamole, honduras" seem to all have a tropical theme.
The number tacked on the end frequents top 10 password lists.
My room-mate noticed that each word starts with a subsequent letter.
If we assume a 2000 word list, divided by 25 due to the predictable pattern, that is about 6.32 bits of entropy per word. If we assume the last word is a list of common number sequences, I will be generous and assume 6.32 bits of entropy for that as well (80 entries).
9 words X 6.32bits = about 57 bits of entropy.
As a rule of thumb, you will want at least 64 bits of entropy (the actual strength needed depends on how fast an attacker can check guesses). 64 bits is 128 times (2
7) stronger that 57 bits. If you have over 128 bits of entropy, no machine in the universe is likely to be able to ever brute-force the passphrase.
Perhaps Brainwallet.org should use their own rainbow table. You can still keep everything client-side for generating the address. However once the address is generated, it can be submitted to the site for checking. Users may be surprised to learn the the chorus from their favorite song (with common mishearings and spellings) is actually in the dictionary.
As has been mentioned earlier in this thread, if you can easily memorize it, it is probably not a secure passphrase. The rule of thumb I use is that
If it has ever been published anywhere, it is probably not a secure password. Do you really think the sum total of human knowledge has over 64 bits of entropy? (that data-set is only about 46 bits of entropy).
Wikipedia has a page on
Password strengthMy favorite online
Password Generator (Note: in theory, it is better to generate passwords on your own hardware).
Generating passwords makes the amount of entropy more predictable:
28B1849D702FB75A
/|url.:n~p
NtLDtc1rhf6
All have at least 64 bits of entropy. The first is 4 bits per character, the second is 6.55 bits per character, while the last is 5.96 bits per character. You can calculate the number of bits per character thus: log(number of symbols)/log(2) -- the base of the log does not matter because dividing by the log of 2 converts to base 2.
