Topic: If you used Brainwallet.org - MUST READ! - Security Breach! - page 4. (Read 52768 times)

The problem is with the key stretching that if you make it very particular then as user you are dependent from a specific website or provider and you also have to trust him.
So it is most better if you use something standard and widely used where you don't have to remember to much on the particularity of the key stretching and you have alternative key generation possibilities othervise may be it will be not stollen but you forget it or will be not available the generation method in 2 years.
PBKDF2 is the most widely used and they are some alternative sites where you can stretch the keys if your brainwallet generator is not available but it is ASIC friendly.
bcrypt is less used and less ASIC friendly, some web implementations
scrypt  is the most modern ASIC unfriendly key stretching but there is no web implementation and they are a lot of parameters to be configured

Yes - agreed - but because SHA256( SHA256( random ) ) is *intrinsic* to Bitcoin (i.e. a "meme" that is likely to be used) does sort of imply that some basic hashing checks might be useful (to stop people thinking that just because they use a hash algo somehow magically makes a simple password impossible to guess).

Not trying to "take the piss" - btw - just trying to suggest some possible improvements to the basic algo (as I'm sure you'd agree it won't take someone 150 years to crack hash( 'password' ) with any well known hash algo).

The main point being that "fools can be ingenious" (so of course you'll never help them all but perhaps we can stop the most idiotic - and if we are not trying to stop fools then why bother rating their passwords at all?).

Strictly speaking, it is not the hash, but just one of many possible hashes. It's always possible to come up with a hashing function to make a specific trivial password look complex from the standpoint of Shannon -- and, in the absence of information about what that hashing function actually was, there's a good argument for saying that it is complex. After all, the suggested string is also a hash of the word 'easy', and it is a hash of the word 'trivial', and it is a hash of the word 'oops'. However, if I don't tell you what the hash function actually is, it is unlikely that you would actually discover it.

The problem comes not from choosing a word like 'password' to run through a hashing function; it comes from choosing a well-known function with which to do it.

In principle, I suppose someone could translate all the common cracking dictionaries using all the common hashing functions in an attempt to provide a tool that could tell you not to use a word like 'password' run through one of those common hashing functions. But given the one-way nature of hashing functions, I suspect the exercise wouldn't tell you anything you didn't already know: if you're dropping a dictionary word into a hashing function and using the output, you already know what you have done, and a coming up with a tool to confirm that for you seems fairly pointless.

And maybe also use a hash algorithm for which no optimized ASIC hardware exists to make producing these tables even harder.

Sure to make it user friendly:

Secret phrase:                              (passphrase)
Email, phone number, SSN, etc:        (used for salt)
Four digit PIN number:                    (used for # of rounds)

You should let the user select the number of rounds as if you use a standard number of rounds the attack table can just use the same number of rounds once it is known.

I think the problem is that if you are smart enough to think like this then you would have made sure that your password was already constructed in such a manner in the first place.

If you are not then you are probably likely to say "huh? I need to eat some salt first?".

The idea is good and I am also thinking to implement it with small differences:
Instead of salt and passphrase should be used more suggestive expressions:
- personalization (your name or email):
- secret passphrase(nobody should know this):
The number of hashing rounds should be something standard, like 1.000 or 10.000 otherwise you have to remember it.

What if the input to a brain wallet looked something like this:

Enter Passphrase: ___________
Enter Salt: ______________
Enter Number of hashing rounds:  ____________

This would be better than what is being done today, which is no salt and one round of hashing.

You would have to remember all three in order to reconstruct the private key.  The table becomes much more difficult to produce.

But as has been pointed out several times in this thread if you are going to have to write it down and keep it safe anyway why not just write down (print out) and keep safe a truely random private key anyway (paper wallet).

Sorry - didn't notice the link - will look into that - thanks!


Maybe some future improvement could be made to the algo then (that hash is the hash of the word "password").

Sure -- the source code is on github, linked from the top of the page I mentioned.


The zxcvbn tool shows 185 bits of entropy and a crack time of centuries. It's very easy to type these in yourself and see. 

OK
Lets make a try.
I used a passphrase composed from a known short male name and a 4 digit pin (which could be from your mobile or debit card) and I generated a keypair with it.
The passphrase was so short that my brainwallet generator don't even accept it. But brainwallet.org takes it. (however I also don't agree with this and I don't have any relation with this site)
To the corresponding address I deposited exactly 2 hours ago 100 mBTC.
Here it is:
https://blockchain.info/en/address/1uSDNberTDLZhA1zWB48qSpWQyYq6DFZd

In 1-2 months if the brainwallet is still not broken then I will publish the passphrase. I am also not sure if the passphrase was not to simple.
But if you can break it than the 100mBTCs are yours. You will wonder how easy is the passphrase.

Neat - is there a simple sample that can be used offline for testing?

(if not - perhaps let us know how does it handle hashes being used as passwords - e.g. what would the strength of the password 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 be?)

As several folks have alluded to already, the relevant aspect of the system's security (i.e., excluding any other potential problems) comes down to the properties of the passphrase relative to the capabilities of available cracking tools.

Unfortunately, our intuition is not always a good guide about the level of entropy in a given string, nor does it necessarily help much when trying to factor in the risk from dictionary attacks. If you'd like a quantitative evaluation of entropy for a given string, together with an approximation of crack time and the relevance of particular dictionaries, I'd encourage you to have a peek at zxcvbn.

Note that while this does offer a quantitative look, as is so often the case when Shannon-style entropy is involved, it is not by any means the only way of looking at the problem. See the original article (zxcvbn: realistic password strength estimation) for a comparison with a handful of other guessers of password strength.

Brainwallet.org is great!

You just need to:

1. Download it from github
2. Use a secure password

Actually you're just underestimating the amount of computing power and time available to an attacker and overestimating the amount of entropy the average untrained person can generate.

Crack vanity addresses? 

You can loose it easily, and of course they can confiscate it "you stay in prison until you reveal the key" usually works.

Remove it from your qt client, in case the address gets reused.

tried it yesterday, took me 5min to crack 2 promising addresses. never ever use brainwallet. NEVER, if you're new to passwords.

?? I don't understand you.
I think if you have an algorithm for brainwallet, that takes for example 5 minutes to mung your password into a key pair, your mothers name and a 4 digit number might be enough as creating the rainbow table would take millennia for even this small password space. Or maybe your mother has a very complicated name and there is no public record of it that somebody might ever take as input for a rainbow table? In any other case I would expect your bitcoins to disappear rather soon.

Sad thing is that brainwallet mining is more profitable for some than securing-the-network-mining but it's certainly only beginning. At some point huge amount of computing power will get directed to collect the coins that are said to be lost here in the forum. When we migrate to safer keys, not all coins will migrate and people will hunt for those nobody migrated.