Topic: Collection of 18.509 found and used Brainwallets - page 8. (Read 31129 times)

Don't let this list dies 

https://www.blockchain.com/btc/address/1KTtPr67kxRu1MTk5FyqQj1Q8xT95KCFMP


Thanks for that coffee 

Now for something a little different:

https://www.blockchain.com/btc/address/674239f32cd4041965f3a9e1fdeb09356f07887a

Passphrase: ประวิตร วงษ์สุวรรณ

According to Google this is Thai, and translates to "Wittawong Suwan" but I think the correct (Westernised) translation is Prawit Wongsuwan, who is a General that became the Deputy Prime Minister after a 2014 coup. He seems to be fond of expensive watches.

Most commonly used brainwallets, i.e. single round unsalted SHA-256 are a terrible idea leading to loss of funds for many users, but something like a warpwallet isn't too bad if someone's really set on using a brainwallet:

https://keybase.io/warp

Using a salt should still be recommended though.

Don't do this, there is no need for it. Just use regular high quality wallet like Bitcoin Core wallet and you will get incomparably more secure private keys without the need for any mental gymnastics. The quality wallets get their entropy from the hardware layer beneath, not from something humans can think of.

They're flawed due to the fact that they're easy to bruteforce, and test different password combinations on without any sort of limit. However, a brainwallet is as secure as the user makes it. As LoyceV points out putting unique information within a sentence instantly makes it more difficult to crack. Common passwords for brainwallets used to be sentences from books, and I think there was a pretty famous one which used a random page in the Lord Of The Rings books. I've never used a brainwallet, and would recommend against them just for the sole reason that they can be attacked easier than most other ways of storing Bitcoin.

There are 2 problems:
1. Anyone can search all existing brainwallets at the same time
2. It doesn't require much CPU-power to test a password

Without promoting brainwallets, I could think of several solutions:
1. If you add something unique to you to a brainwallet, it's  much less likely to be found. Say I would add LoyceValenzuela to this:
That would make:
weadmittedwewerepowerlessoveralcoholthatourliveshadbecomeunmanageableLoyceValen zuela and instantly adds many more possibilities to the search space than "just" searching all available digital text on the planet. Or add your phone number.
It's not perfect, but it makes it several orders of magnitude less likely to be brute-forced.

2. The protocol should use CPU-intensive encryption like BIP38 uses. That reduces the number of tries per second from billions to dozens.

Brainwallets were the worst idea from the beginning, but for some mysterious reason they are attractive to newbies. There s something in the human psychology, I guess the simplicity of the solution and the masochistic aspect torturing themselves to remember long passphrases and the risk they may forget it which has an allure off challenge. There is also an aspect they do not get the math and reasoning behind reliable alternatives, like Bitcoin Core wallet, that turns them away from better alternatives.

https://www.blockchain.com/btc/address/1d923c954d8901d559f1262fec66ed08fdac73cb

Value of around $USD 55 swept immediately.

At least one of the inputs in the funding transaction appears to be an exchange hot wallet (1NDyJtNTjmwk5xPNhjgAMu4HDHigtobu1s, which has nearly half a million transactions [edit: this is a Binance wallet -> https://twitter.com/binance/status/961666467325358081]). Are people still deliberately withdrawing funds to brainwallets?

The passphrase is "weadmittedwewerepowerlessoveralcoholthatourliveshadbecomeunmanageable" which appears to be the text (sans spaces) of the first step in the 12 step Alcoholics Anonymous program.

It amazes me how obscure passphrases are still swept away almost immediately. The cracking that I do for fun represents literally months of CPU time and trillions of candidate passphrases. At full tilt my i7 can push out about 43 billion passphrases per day, which would require over 1TB of storage per day if saved permanently.

People running stealer bots must have massive databases of pre-computed candidate passphrases.

That is very compicated, really. Also, if noone doesn't know your passphrase you shouldn't afraid seed compomising. Because the fact of knowing your seed can't help to hacker.

If you afraid that your passphrase will be brute forced or social hacked (as we know, people's brain provides very low enthropy) , then i have some interesting algorithm for you:

1. Create easy master passphrase you always will remember.
2. Create your own algorithm of lower passphrase derivation. It can be like: 3. Use result as passphrase (following BIP39) for specific wallet. (for wallet 1 - passphrase1 + 12/24 seed)
That's it. You can use different wallets for different purposes without fear your wallets being linked (like addresses in one wallet).
Also, while only you know derivation algorithm no one can get access to your wallets even seed or/and master-passphrase compomised.
You can store your seed without any protection, you can put it into the bank or write on paper.

To hack all your wallets, hacker needs to know your seed + master-passphrase + derivation algorithm. It's not so easy to hack such protection.

> hash(passphrase+seedX)

that operation reduces security due to attacker can brute force quicker with a single hash iteration

You're the second person to point this out after I corrected myself.

You could store hash(passphrase+seedX) in the blockchain so that the brainwallet client can figure out when it has cracked the seed, but that means an attacker also has that clue. Not such a good idea: now an attacker can hunt for hash(passphrase+seedX) matches to discover seeds with weak passphrases, and once they find two different seeds with the same passphrase, they're less than 60 seconds away from finding a private key.

I wold like to point out that your times are correct only if the user has a way to know that an individual seed has has been cracked. Otherwise, you must multiply the number of attempts rather than add them.

Edit: Oh, I see that you have already arrived at that conclusion.

OK, you're right. We have a passphrase and without #0 it is just a millisecond to try. With #0 each passphrase will take a minute to try.

Shrug. I guess as some extra protection if the two main seeds (which would need to be printed out or stored somewhere) are recovered by an attacker.

Without seed #0 the attacker would only need to bruteforce the passphrase, but by requiring the additional (unknown) seed the work is increased by a factor of at least a few million.

Disclaimer: I'm not a cryptographer, so I freely admit these ideas are probably a little crazy.

why do we need #0 if it's so easy to brute force it then?

no, if you loses both seeds you die

Edit: yep, if I lose one of #1 or #2 seeds it gonna take a month to brute force it of a couple of weeks with 50% probability if I'm lucky guy.
If I lose both seeds I'm in the deep trouble even if I'm extremely lucky.

Was thinking about this again today, and I've found a flaw in the above. I believe the total effort required to cover the search space is actually the product of the effort per seed, rather than the sum. This is because there's no way to know if you've correctly found a match for a single seed. The complete passphrase+seed+seed+seed combination is either matched, or not matched; there's no way to match a part of it.

In other words, if you lose both seeds, it will take 60 x 86400 x 86400 seconds (5,184,000 days) to brute force all possibilities, not 60 + 86400 + 86400 (2 days and 60 seconds).

To be able to independently crack a lost seed would require additional external validation, such as a hash of each seed stored in the blockchain.

Just wanted to update the above idea to point out that multiple seeds won't work as expected. A single seed would still work, since there's only one unknown part to force if it is lost.

What is "old style" different from the new?

This one is unusual because:

1. It was sent around 3 months ago to a seemingly random passphrase (looks like a 21 letter keyboard bash), but that passphrase appears in a password list from 2012.
2. This time it was a whopping 1 BTC ($USD 4k at the time), swiped immediately.

Why was 1 BTC sent, in 2019, to a brain wallet using a passphrase that's been known for 7+ years?

Because of the large amount and recent transaction, I won't reveal the passphrase publicly, but I'm sure there's a few people reading this that who know it. And there's at least one bot that does...

https://www.blockchain.com/btc/address/af867f1c5287676c97dfc402e3e642ac97652670

Nearly $2k USD blown by sending to a very weak key (7b7)

Swiped quickly, with about $USD400 paid to the miner which incorporated the transaction.

I really hope this was deliberate. 

https://www.blockchain.com/btc/address/02b443fb5654d5fb6323dff432b90f6e204b9676

No, that would be security through obscurity. It's fun to have some cool secret way to generate your key, but if it's too complex, you (or your benefactors, say if you suddenly die) could risk losing the funds.

The point is that if you must use a brainwallet, the random seed will at least make it more secure against untargeted privkey hunters. Remember that each ATTEMPT at brute forcing the passphrase+seed takes 2 days, so in theory, even a reasonably common dictionary word as your passphrase could take years to crack. (In practice, a cracker is going to be using multiple cores and possibly optimised cracking methods, so it will take less time.)

Multiple seeds can be used, for example:

1. Seed #0, which is an internal seed that is not disclosed or stored. This must be brute forced when re-generating the private key, so it is quite weak. It is intended as some extra protection against an attack.
2. Seed #1 (stored in one location) which takes ~1 day to brute force if lost.
3. Seed #2 (stored in another location) which takes ~1 day to brute force if lost.

If the user has the passphrase, seed #1, and seed #2, all it takes is (say) 60 seconds to brute force the internal seed, and generate the correct privkey.

If the user loses either of the seeds, it takes 60 seconds + 1 day.

If the user loses both seeds, it takes 60 seconds + 1 day + 1 day.