Show Posts
He goes as far as claiming that "D0g....................." is stronger than "PrXyc.N(n4k77#L!eVdAfp9" based simply on the length. That's preposterous ! The first password has 36 bits of entropy while the second has 150 bits, assuming a cracker aware of the "technique". Presuming that you are smarter than the attacker is the road to security hell.
I've been wondering about that-- is it possible to write a password cracker that generates all the lower-entropy passwords first?
That's the kind of theoretical computer science problem that it seems like should have an answer, or have a proof that it is equivalent to the halting problem.
There are engines that work that way but they don't handle the example provided well.
One well known example is Jack the Ripper an open source powerful cracking engine. It starts with a root word dictionary of common root words used in passwords (pull from prior password compromises, the largest being an hotmail password hash file which didn't use a per user salt. This allowed pools of hackers to brute force that list to determine common password root words with a very large sample.
Essentially the engine takes a root word and "mangles it".
Applies permutations of
1) capitalization changes
2) simple substitutions d0g for dog
3) apply suffix of symbols & numbers
so words with small amount of deviation from a root password have a reasonable chance of being compromised. However quickly the number of pemutations start adding up and it is better to just try brute force of all permutations.
In the example above both the high and low entropy passwords would be tough to brute force. While the more complex one is indeed stronger they are both beyond limits of current algorithms and an attacker would need to resort to brute force. The only exception would be if the attacker knew you were using a single repeated symbol Even if they did one would greatly increase the effective entropy by using a second symbol.
d0g.....................................................!
In most password breaches it simply isn't worth it for an attacker to search exhaustively. In Mt Gox attack the attackers obtained the password hash file and compromised accounts until further cracking didn't warrant the risk of delaying the attack. Since the attack space grows geometrically at some point it isn't worth it to try and compromise more accounts. Simply put the accounts breaches were the ones that were so easily cracked it was worth delaying the attack. Once the had got all the low hanging fruit they attacked.
The unique challenge with bitcoin is that an attacker could keep brute forcing a wallet for a very long time. The counter solution would be to periodicaly move funds to a new address. Maybe some future version of bitcoin client (or a high security variant) could do something like that. One address (or group of adresses) would be designated the "savings account" and keep the large balance of coins.
Now say wallet.dat is stolen and attacker begins to brute force it. The bitcoin client would periodically (period set by user say once per month) create a new address transfer funds to that address and then stop using old saving account addresses. This now limits the attacker attack horizon to < 15 days on average. IF the compromise the wallet.dat they stole AFTER the funds are moved it is worthless.
That is just at Core 880 taking it slow as that is a lot of thermal energy to dissipate.
Just kidding.
