Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Milk Sad Disclosure

milksad.info

Post reply on HN
Print view View original

101–110 of 133 posts

Re: Milk Sad Disclosure

#101

Post by nullc »

knocte wrote: post #98
jrockway wrote: post #93

Earlier quoted context omitted.

I love how many references to Stack Overflow that PR added to the codebase. Always a good sign.

LOL! The second S.O. link actually goes to show how broken C++ is: https://stackoverflow.com/a/18298965/544947

That's really a C related comment and all it doing is subbing in implementation specific pre-standard versions for the benefit of compatibility with compilers prior to the introduction of the feature in the C11 standard.

The standard calls it "_Thread_local", pre-standard MSVC/icc(win)/borland called it __declspec(thread), and pre-standard GCC/icc(linux)/clang/sun called it __thread.

Code would also be free to just use _Thread_local and say that a C11 conforming compiler is required.

Re: Milk Sad Disclosure

#102

Post by yieldcrv »

chx wrote: post #100
yieldcrv wrote: post #4

Are any of the following two things true: Multi signature addresses mitigate this attack vector? With the “taproot+schnoor” upgrade last year, it is impossible to tell if funds are stored in a single signature vs multi signature address?

[flagged]

One perspective is that it mimics society more evenly: if you’re one step ahead you also get to steal everyone else’s. Being a perpetual bug bounty is utility.

A more collaborative perspective is that the adaptable nature of the protocol adds to the confidence in it. Only new addresses created after an update of one program were affected. And now it is fixed already. Bitcoin use has pointed out flaws in other encryption methods before which quickly got fixed solely because there was a financial motive to fix it suddenly.

The primary thing that you missed is that the upgrade last year was not “snakeoil to mitigate this problem”, its just also an additional way to mitigate this potential problem, its just happens to also provide an improvement on 10 year old multisignature technology

But an overlapping analogy to your primary observation would be how insecure accepting credits over the internet was in 1995. That problem actually never went away, despite layers and layers of patches and payment processors and security standards, SSL, TLS, PCI Compliance v1 v2.. venture backed competitor payment processors with fraud detection

and yet nobody threw their hands up and said “we’re going to stop trying now”

Re: Milk Sad Disclosure

#103

Post by lclc »

comex wrote: post #72

The spiciest bit: > During our accelerated coordinated disclosure to the Libbitcoin team, the Libbitcoin team quickly disputed the relevancy of our findings and the CVE assignment. By our understanding, they consider bx seed a command that should never be used productively by any bx user since it is sufficiently documented as unsuited for safe wallet generation. > We do not agree with this assessment. https://milksad…

Look at the big warning there: https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-se...

He's right.

Re: Milk Sad Disclosure

#104

Post by ryan-c »

alchemist1e9 wrote: post #89
werrett wrote: post #88

Earlier quoted context omitted.

It’s not not a myth. Not even really lost to time (or a simple Google search). E.g https://www.reddit.com/r/Bitcoin/comments/1zti1p/17956_hacke... https://www.wired.com/2015/07/brainflayer-password-cracker-s...

FUD!! and you know it if you actually took time to read the post. > I could find the passwords for 17.956 of the addresses. * Only 2 addresses of the hacked brainwallets are currently not empty, and the total money that I could actually steal is 0.00115215 BTC. > Somebody seems to have systematically flooded the blockchain with transaction to brainwallets. E.g. this transaction: https://blockchain.info/tx/ba421da33e5…

Did a brainwallet write this?

Re: Milk Sad Disclosure

#105

Post by ryan-c »

alchemist1e9 wrote: post #69
ryan-c wrote: post #28

Earlier quoted context omitted.

https://www.cs.unm.edu/~vasek/papers/vasekfc16.pdf Also, there was an ethereum wallet with over 40,000 ETH that got drained.

From their conclusion: > By examining 300 billion candidate passwords, we found 884 brain wallets that were active at some point in time. Unfortunately, we also found that nearly all were drained – usually quickly. While our findings are necessarily incomplete, they certainly suggest that brain wallets are not a secure method for using bitcoin. Perhaps the most surprising result of our analysis is the relative scarci…

Someone used the passphrase "how much wood could a woodchuck chuck if a woodchuck could chuck wood" to store 250 BTC. I personally drained it by mistake, then tracked down the owner, via the pool he'd mined it from.

I'm a co-author of that paper, we later got funding to do a larger cracking run and found more wallets, and even some that still had balances. See slide 18:

https://rya.nc/files/measuring_the_use_and_abuse_of_brain_wa...

Feeding a massive corpus reddit comments and six years of IRC logs into the cracking tool was particularly interesting.

> And no, anyone with 400,000 ETH who claims they used a brain wallet, and oppsie .. someone stole it. Is having a boating accident, if you know what I mean.

It was about 40,000. The password was "guybrush", and I spoke to the guy who made it. He didn't understand how the tool worked when he made an address. Much later, the Ethereum foundation sent him the ETH. It was gone by the time he went to spend it. Dude put out a press release offering to let whoever did it keep half if they gave back the other half. The ETH hasn't moved since the day it was stolen, almost eight years ago.

I assure you, the guy made a genuine fucky wucky.

If I'd gone blackhat with this research, I could be retired to a volcano lair on a private island by now.

WTF is your angle here?

Re: Milk Sad Disclosure

#106

Post by usr1106 »

WraithM wrote: post #83
lostmsu wrote: post #12

Note: "Libbitcoin" here is a company name, and not a name of the core bitcoin library. Only their products and whoever used them as a 3rd party is affected.

libbitcoin isn't a company. It's an alternative C++ implementation ( https://github.com/libbitcoin ) to the Bitcoin Core ( https://github.com/bitcoin/bitcoin ) implementation. Bitcoin Core is the one originally from Satoshi. Libbitcoin came in like 2011 or so iirc and was led by Amir Taaki. Libbitcoin is a lot less popular than Bitcoin Core, as you can see on the github stats.

Last release 2019, master branch marked as non-functional. Doesn't seem to be very active. Their homepage https://libbitcoin.info/ looks polished, but no signs of recent life. This vulnerability seems unmentioned. Well, they claim it's not a vulnerability but a demo implementation that should not be used to store anything of value. But there is no prominent note about that and some users did exactly that.

Re: Milk Sad Disclosure

#107

Post by chx »

yieldcrv wrote: post #102
chx wrote: post #100

Earlier quoted context omitted.

[flagged]

One perspective is that it mimics society more evenly: if you’re one step ahead you also get to steal everyone else’s. Being a perpetual bug bounty is utility. A more collaborative perspective is that the adaptable nature of the protocol adds to the confidence in it. Only new addresses created after an update of one program were affected. And now it is fixed already. Bitcoin use has pointed out flaws in other encrypt…

[flagged]

Re: Milk Sad Disclosure

#108

Post by lrvick »

lclc wrote: post #103
comex wrote: post #72

The spiciest bit: > During our accelerated coordinated disclosure to the Libbitcoin team, the Libbitcoin team quickly disputed the relevancy of our findings and the CVE assignment. By our understanding, they consider bx seed a command that should never be used productively by any bx user since it is sufficiently documented as unsuited for safe wallet generation. > We do not agree with this assessment. https://milksad…

Look at the big warning there: https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-se... He's right.

I would call your attention to the several places it was demonstrated for use by libbitcoin team members -without- a warning, such as in their contributed examples in Mastering Bitcoin. We cover a few of such examples in the writeup.

Also note that the tool bothers to refuse to use a flag to specify 32 bit seeds, due to their known risks, but then proceeds to give you only 32 bits of entropy anyway even if you ask for 256.

Re: Milk Sad Disclosure

#109

Post by yieldcrv »

chx wrote: post #107
yieldcrv wrote: post #102

Earlier quoted context omitted.

One perspective is that it mimics society more evenly: if you’re one step ahead you also get to steal everyone else’s. Being a perpetual bug bounty is utility. A more collaborative perspective is that the adaptable nature of the protocol adds to the confidence in it. Only new addresses created after an update of one program were affected. And now it is fixed already. Bitcoin use has pointed out flaws in other encrypt…

[flagged]

That’s not what I wrote, I wrote there were some similarities and listed them, and you presented different differences and discredited those differences as an attempt to discredit me and the entire concept

That is called a strawman argument, do better.

Re: Milk Sad Disclosure

#110

Post by bombcar »

iraqmtpizza wrote: post #77
codetrotter wrote: post #39

Earlier quoted context omitted.

This xkcd comic has been instrumental to me. I wrote a command-line utility a couple of years ago that I use myself regularly to generate secure and memorable passwords https://github.com/ctsrc/Pgen With this tool you can also see how many bits of entropy the passphrase generation settings you are using will result in. For example, generating a 5 word passphrase using the long wordlist pgen -l -n 5 will yield a passp…

dibs on joyous embolism outsider evasion mashed. this is my new password

It’s better than your last one, hunter2
Post reply on HN