Topic: Blockchain.info security [FUNDS STOLEN] - page 2. (Read 28195 times)

@watertech666: Sorry for your loss.  However, neither of your victimized addresses 1 2 appears on my published list nor in johoe's additions to it so neither of your addresses was specifically effected by the repeated signature nonce issue. 

Also, it's clear the thief knows the private key for 1CzAncjXYjtiXNC4CNAw4RoKdQLoi72xn, so you should remove it from your forum signature.  He could steal from either address in the future at any time.


@Aajo: Sorry for your loss as well, but your victimized address is not listed either.

Jesse James. I'm so sad. I lose 263.84btc total from 2 difference address in blockchain.info on 29th Aug. 2013. Details Please check  https://bitcointalksearch.org/topic/my-wallets-were-stolen-just-now-can-any-one-help-me-277601

Can you help me to check it's because of bug?

Hello, my blockchain.info wallet was cleaned in April - back then there was a wave of stolen coins but only a speculation about the reason having to do with the alias and offline copies.

can someone check my old address / transactions with the script?
https://blockchain.info/address/1N2ctCxet8zjeyQMQngfmkvC2h9qzF3c6k

Back then I used to do alot of outgoing transactions with Blockchain on Firefox..

I applaud you, Blockchain.info. Great service.

"Conversion, theft and unjust enrichment."
-Msantori

 

I was referring to the fact that you posted the reply as hyperreal

Try this service
https://bitcointalksearch.org/topic/bitcoin-wallet-recovery-services-for-forgotten-wallet-password-240779

I've just locked out 7 BTC yesterday while fiddling with blockchain.info app on iPhone. Their database glitch forced to reenter the password, which blanked from my mind after several months of cached usage. I did a mistake by trying too soon, would I have waited for a few hours for service to come up, the cached password/database could still work. I felt this may come some day, just the timing was quite nasty.

What I have left now is AES encrypted blockchain.info wallet, and there's a hope to crack it via dictionary with bits and pieces from my memory. If someone already had an experience with bruteforcing it with speed optimized solutions would you please share the know-how?

Actually I like the blockchain.info, it's so far one of the cleanest services out there for small transactions, just some additional safety net in these cases would be a great thing.

This is quite important information, and it immediately makes me question the security of bitaddress.org generated addresses, anyone with more knowledge about this care to comment?

My account was hacked on Aug 1st.

https://bitcointalksearch.org/topic/hacked-266500

Someone was able to empty out my blockchain.info account.

Transaction id here:

https://blockchain.info/tx/1174e27cd6de043ec081a68b52f455ba1548f35949c2ba2ddd3abc60f5a29840

I've found no evidence that my email was compromised, and was using two-factor authentication at the time.

How can I determine if this was caused by the rng exploit?  I was using Chrome at the time.

Thanks!

Can someone explain where the source of this issue with the RNG came from?

Was it the RNG in:

1. Blockchain.info's browser plugin code?
2. The Browser's code?  (Firefox, Chrome, etc)
3. The OS itself?  (Windows, OSX, etc)
4. Something else?

Thank you for the clarification.

I reran my script to try to catch the special case you mentioned but oddly was only able to confirm a subset of the ones you reported.

1BH4hyBMH8NoiscwiPngP23fVNN8wpJwrT
1HRhPdTXhTDMTM8C9C3Y8FGD1EKszkPGv
1MmE9r9QTN2GnP1TF7JhZSKPsubuXguJkb
1NujNX3cvbikAZMnKtETgSd7kvw7o93MRg

Checking my logic ...

Edit 1: My bad ... I think the discrepancy is caused by my parser ignoring transactions with non-canonical signatures (which stopped being allowed a while ago).  

On an unrelated note I also just checked if there was any overlap between the set of signature r-values and the set of public key x coordinates ... ∅ ... if there were any that would have indicated the potential for more RNG issues.

I don't follow?  My reply simply acknowledged I had overlooked the cases he pointed out.  I deleted it because I thought it prudent to double check his additions first.

Jesse James,

While I appreciate your efforts with this,  I think deleting the reply to johoe is more questionable than the way you replied..

Jesse James, you missed a few addresses:

16mWzkk6iznyJQ3sKQRYxQ1Zr8xWpGMFWi
1B2wqabcETtQxPuacB5whni7GUjDn1oQQX
1BH4hyBMH8NoiscwiPngP23fVNN8wpJwrT
1HRhPdTXhTDMTM8C9C3Y8FGD1EKszkPGv
1K5XZhjCwbLYHwys86FvepaHt6tFiWb35T
1LfuyRkm9MrEXTz72hzpPsL46mzHEXfqWj
1MmE9r9QTN2GnP1TF7JhZSKPsubuXguJkb
1NujNX3cvbikAZMnKtETgSd7kvw7o93MRg
1PCrHhXxS8ZotDvgSA5WxpmtC1qNQchrPr
1Q4VVTsx6vgYth7iD9WnAgHvAj239PMaoL
1rPAkJSXWgnLFEiCzv3APUFLsi8Kzv3pX

Only one of these addresses is very recent.  Maybe my script finds more keys, because I also catch an addresses when the R-value was used only once as long as the same R-value was used on another address twice.

Moreover, the two addresses 1Q8eetJs5wRpqR3b5FT9EHe6GD8Bges9Hm and 195Tycz7nVhV7aKw98nq74FdVYtyYyE1K7 are endangered by this transaction:
https://blockchain.info/tx/127da3144a02f16e1a5ccb67778a2f5f9924023ce9aa20c1c4d08be576cbb0b9
I think it is not exploitable but as soon as one of the private keys is revealed, the other is also revealed.

Your friend's private key was never exposed due to a signature nonce collision.

Here's every address that has been exposed from genesis through block 253081 ... obviously only a few of these are due to blockchain.info:

121Zna8Dy9W2qDvsJEH2ALeHQkteXaeGng
12CkZeZvwDwiTvFm5H8bABpEqQHXJ6gWc1
12JDjmk2fGMPRK9GaT98vBFDc3MDHoPV9r
12RFNoJK2MSiWfXt3fFG7F4urUpLGnTBxh
12WhvZTWMv9XLfyM2g7XFSUgpwzuQUX5Mq
12a7gpjZDQBDhVSknfQzL3ygcASNQcocnd
12c1XuVdjQwyftTbqnWMT94CYW6vKFknwm
12ekVy8duhBMLGd1JhxcgxrTN1fchmVcTo
138VcLyoAb5sdjo3cDw7d14fUGLKRwQ9VK
13CWujDi4g6DWB9bWDXT3TfRU635NPJdPF
13GXRxeyR9UTDQojZYv9NZ1j3VA6Butc9U
13LRBbvgCSXsUs4JNmYhzHRo3re8vYVDid
13ds2bCrxe68w8WD4R7bWSjGq4uK7XbzWH
13fZF8aZcSjpxhukHkyVtHsLnPnVszQaLm
13oCG1VNMAGtNp9RcAmUieRf8NayAJ7xj7
13x6i5itrvR8Rf75xP8PZaPtNTNxZLReLe
143CugrdSngLmDaLWoLrWJzb4AU1xLMqoY
1494Wwkf8QN4nC3gSYz3qjZVNuVZSHw2zi
14FguDL7teNFCctazjUxCxCfZtssycq11h
14RJsWTjq9q2a9tNQSdpxbMaViWoXxRbjt
14ih1qxbcFmwLm8Hc7qTr3BhzdmWTWRmpC
14reTqqg8r4qriHozsYoydugzLjYtpVoMZ
154nELZtftuW951oQY7erHnN4L196c98Wp
15E8CUjvHDVj8mBzhkNHErXtz4AeEHycpH
15GieELLKTruUdzmTDVYP1TsjnzNRDg8Qa
15p65cNbtB3bQYf9GB78edRo5Ppux3uaU3
16He3EDsvTKYRSQGsZeoooTbYAjy9fiLoQ
16NCxA48LPKdSr5fACPnrLxgkrFnDJAzLp
16SchApeKZEc86CVJCc1vLQ17TEJCRJNef
16UkUnbqW8PXRrwgxRdb2UTivbgNnBYqwC
16io8zfbhStqe9WVdHN3JLzc29D73okaoy
16y2wAieZE9VknMK29J7EAhC8fmRtdLy8p
17AHXAodFQ33A4DqFENVHCG59qiaRNbhcq
17HHdLh4oXncuTejALwC6fgArVqPUxh2Sr
17Lq1nrktyEFV3AVPAbsbDXWuWoUNMhws8
17Vjk88w6fy5YRVUGD6Aa9w545UA6K4tYZ
17gDnz5TU8T16Pgzo93M7Dm1j5HS3UuS2Q
17sDdDiW2dNRQvTu2NkwwCbfXNFxVCpbZW
18KZdcnGaqaXnHiRPb8rVGCztyA4jJPKtS
18mmzMizs5CHtLJwchtPMuiYqVqWjw3rLe
18pqzCLA17hdnzxFnf5Cad2feA1RHKtW2P
18yDksipyvWEX14KTd4DHvj6ZDcXvNqtpB
196SL6bZEvBT8A9z46df54zE3rzZfXzwe8
19DcmnrhqpLgn8L6Exay1sJiKZPtYUAw1Y
19cRkXQfonjdJT9K8TMuDxV1PKLSdHZtPh
19qnLpn9it7csR9sEay1XrFyfAmUNoXYk4
19yCy4mFWJVsdJbgtG79VwHGxQpcx4uhcr
1A8TY7dxURcsRtPBs7fP6bDVzAgpgP4962
1ALsXt19tBxMr29WfM2Zd7EU8HwzooLGHx
1AgVauV4U1tt3KbRiehht56NoZeKprLUXe
1AnFEpvs8a41T3ZpfPtXBENvkL5oatQ64D
1AyTNQRvz6fo7EvebGpKfJB7jJeppxY4yc
1B8vhS5umMNKvwQFHJ3Hgres4NJeoe8U7Y
1BFhrfTTZP3Nw4BNy4eX4KFLsn9ZeijcMm
1BMzWp77j7x3GKDYNbCP3df7YG3UEw1vVE
1BRwmguCycCWSbueTcpn1vSJddMJXEhyjH
1BvQyALiTSgKwVYzDL3ANoqmdWaoyRZazS
1C3G6y8Cyi7ECDaaDhG34sLzrv1dd7Xo33
1C8x2hqqgE2b3TZPQcFgas73xYWNh6TK9W
1CFVxqxX3i9L9dm6Gw2QKJ2fH18HSJ9H8k
1CNHzFKNCkCwYecVUfmahmqDFrn5uuRzsU
1CRcBxVoXCqL7cEiq7b7rTYQyMhUrCu5Mf
1CozShbCQwFqa3iw2AUE3zn7Pp1f3HR3D
1CqEdApNprZzgqUsuyLocXKH5yMdFTnTJQ
1CxZGXpNLDmr7eDmgMiGc1n1gAyE6LKBig
1DHmu7BvzjpQQxbKEuqTU2zSvZmgZBBrne
1DQK1Xb1gKBRXLi4PEegWCZ1giELgBqhq7
1DWhHeTnoZAFPehoM1W6S37hn7nVjZLrQN
1DY5YvRxSwomrK7nELDZzAidQQ6ktjRR9A
1DcNJeexQV2kM78AdMKSzmsQ8DeNMHLTJ1
1Df8hDiS6RSeu9WDUqUtBpBmBoepzo24pD
1Dka5AAYwdZkrPJZHjKmdZkaVATnwYeSqG
1E67dSKMyrEoqfAjSsE1SNpeeau4pmyc5j
1E9ffsnXjMnZxmJaqCLXWhqWzKqx1sZXP9
1ECvZ9ojebv5TVWySf2roXRP4XyQb5rNCy
1EFET6LSLabV5KR55XqRzzhQ1rBUGTD1SQ
1ENrnLCxp9srcWCCE3kQFNqHRGDijespb9
1EPXZfTX6TD3L7TQdRu2nqMT8mrAAPSTST
1EUDdSvFGmZCa5zUXSXFSQD7r2qBZaSWJU
1F48AGnDGLBbDr5Uk7DfUhrhe8U14eHKaH
1F9tB2p9NWsGEt1TjiGAa3WEEGs9Wc779R
1FPSVbypWa7rBWbciKHJ983YWcucBn7aUQ
1FPgs8ZaxXUAp61jkd53U7zWj9NQq8yM34
1FX2xLHNxcT77bxLZXHzet6e8kMSS53uDK
1FY4Ny2ZTvDGDHshB1Rpp5Di9x6Q9GVd5a
1FYXLjfFJ1qsngiArLsrBVEGRaKkV15FGV
1Fcj89eqk1xCe6PqkMpaUuWCaK7MUXeYbZ
1FwbYs6UL2fzB9crvhWNCZyr9oqNjEXzcu
1FxWoGvwzjWGKk69vFumyoBaUCqzsndVck
1G3BjSLWsWH6tbPYs29fYMYaz9k8EStQM
1G4TqNcKTRRuQ3brQSv85Fohf3jQiaGAbL
1GTFFqbHGp6xwcKVmLkbLqHiauUbKT7jxs
1GUqD7UATGzbEBrMjweP5GCTQeU51TsZbj
1GYRDPaCm3hrzUcgfT49w7mcvoQu2Y4MmX
1GjDS84eNBx6QQoo7dBddvgYArSttxLYdk
1GysfXJbf5FREeJetrwuANNZi8pcz4n1v6
1HWEyVbuyPmXfR9eBnrh4v2Npjnp9UJQCw
1HWYEGYNgVc7bc28RCAa8mCJPv9eEnHieR
1HXSnvNGK8oYQCyLDkpHNZ2sWPvFsYQcFU
1HmJh2b8iS64WgX5snSzKYrNXqbnKkuBvE
1J8THH46JdkjiGYLQyPQDHVk4gtftahDUx
1JCMAUG9P8X4PHM7rF4ywDFHaAK2FMRrkN
1JFMHv7ijwXDQYQrehhSxn6u9bTfkGCmK
1JNC3iaxA95NbWrSro5me2BM27wohuucKD
1JNMvqdUYP9eDR3mEkxxCne4BYabc93Nwh
1JZ5NjZCDrnj84mZnv2fuAmAb7w4v5LiEu
1JjcWuJDRNkw3XcMfE7khhRg1UCxU8eKua
1JmMcWWy1mFuubbsBRPuVXdjFdtM2ENJXE
1JnqZ6Djhncs9YHe74CbkLaXXAbA1phsTU
1Js2D8Fj1AWQ2aB7TMtmJ6rn4bYDFtcjgF
1K5CgovB1c4vX22MvUq8cfRsuctG86Jmx5
1KSFgqcm6mc4Aaq6EsR6Awfr65S6RmVeHh
1L8DFt7yYA3iZsr6RA3d1mpf4J7TgBsYF
1L9a8dXMgq2xWV1zaDUGje2FAbzCG18QQh
1LKu5b7jUoM7MJzeuTCmvDWsJrBgBhcvhb
1LnBTt9TYRMt4aABcDYSoaMQ9jV8Qgajkx
1Lr9tUFz4mypFzc3PYitgGU1dTg21ubM9p
1LspNcTjkzFQRrsr4iGGxD5RSKehB5fHnA
1M5edBFjjFJhQhgSuCUQnX3uytcskgnqQB
1Mjwi2LnE6oz3p8dNFXWgMpAPBs6ZpPPA2
1N2aQiQ5LjNQ3C3cKCmHHnnq65RH3zRD9B
1NCRgUAgJnzBGcLNX7iQD1d9Cn9ZyKF2PC
1NEb41nDgxWwVzhHSsk4obURJ13KauJRsF
1NRtYCGVo2vR7WmYVussK6sVva2wZsYTep
1NSLj5xdCyRmMYVtM7bwZxZarYLm6EGZJf
1NSnZPRR32mrfAADxNJcPRP647gseqEMyj
1NuSEboWF7YJ3bozo5H1JDpH5yc7zyHZm8
1NvfCyqRh6cuh8dCQDJmboriifg1eaYDnV
1PUv3XNWWCDmEK6o9VerPK81qVfo4Wtvv2
1PWTFonhiXCdTZ4Nd2J726rqWnNsTVeVMY
1PXU5aD3fzgAm2E56o2VSaHpVe4bhe3d2m
1Pbt1LGM2JNgMjtnEscEmntsSrcYofeaoa
1Pde4CbEitkdPiwwKvd6s3znWw7EXZMYjD
1Pq6Ygv3kdMVX2TdNhUSPadxaShiGJUAoS
1YWwSaXTESKgDpitb6Rp8bteXzUR6hjDg
1ZBRXLZEzSukVDEDDJjtHYmrpkEGH94nS
1kJwZbv3dhUowPyRHcxJMknoJpPYfwaGf
1kMEr9W4YeAnzFcuSWwj3ShYGANdLHSxG
1szVke6ThJtfdUTi6Y5AAMDMePM4Ha8vK
1yiQRuB3KRxZTrSHBNZK9NdjbyJskHiVs

Yep,  that's what I meant.

This information was very helpful.. thank you! It looks like they did something similar to what I'm working on here. I'm warm to your idea of only supporting the window.crypto.getRandomValues browsers for the release version of Coinpunk, or at least warning users that they should upgrade their web browsers.

I wanted to ask you what your thoughts were on my skipping Arcfour (RC4) for window.crypto.getRandomValues. The blockchain.info implementation appears to still use the RC4 code (it uses window.crypto.getRandomValues for the seeding of RC4), but I didn't see why it was necessary here if I can just always get a nice random number from the newer browsers. Is this what you meant by mainlining?

Cheers! And thanks again.

window.crypto.getRandomValues is not available in webworkers because the window object doesn't exist in webworkers (by design).


IMHO, it's worth looking at puik's modifications to bitcoinjs-lib that he's maintaining in his branch ... he's made fixes to the RNG in particular.

Honestly, if I were doing JS crypto my approach would be to just mainline randomness directly from window.crypto.getRandomValues and bail if it's not available.  If you need randomness from the context of a webworker, you have no choice but to message pass it into the worker from the foreground.

I don't have time at the moment to do a comprehensive audit, sorry    ... but javascript honestly isn't really my bag baby so I'm not sure I would be the best person to look at it.