Topic: Recent breach at Blockchain.info -- Android App did a stupid. - page 2. (Read 4934 times)

If the first thing you do with a SecureRandom object is call setSeed(...), then it is assumed you are providing a proper seed.  

This means that it skips the automatic self seeding as unnecessary.

From the docs.


The recommended way to create a SecureRandom object is to call .nextBytes(new byte[1]) right after creating the object.  This will force it to self seed (from OS randomness), since it hasn't been seeded yet.

Almost every excel formula I code contains, the following and that's for mundane stuff. You would have thought their due diligence would have increased for code transmitting $Ms a year.

=iferror(*code*,"YO DUDE YOU FUCKED UP, GO BACK")

One way of looking at this is that these fuckups are going to be made - and hopefully learned from - by people along the way.

With $27 million of money from vulture capitalists, bc.i will likely survive more "opportunities to learn" than most companies can afford.  

They may achieve security before their money runs out. Which, I guess, would put them ahead of the short-lived competition we've seen so far.

As part of my 'Cybernetic Entomology' posts I researched how and why this bug actually happened.

They derived a class with a 'SetSeed' method that _mixed_ input with the RNG state from a native class with a 'SetSeed' method that _replaced_ the RNG state with input.  But on low-memory Android devices that class didn't get registered.  Instead of failing because an important component did not load, they called the 'SetSeed' method of its parent class.

So, the procedure for initializing the RNG --->

whatever its current state is, use SetSeed() to mix it with bits from /dev/urandom (good)
make it "Better" by using SetSeed() to mix with bits from random.org (stupid but probably harmless)

But when you wind up calling the parent class's SetSeed method, instead, this turns into ---->

Replace current state using 'SetSeed' with bits from /dev/urandom (suboptimal but acceptable, except for what they do next)
make it "Better" by replacing that (acceptable) state using 'SetSeed' with bits from random.org (WRONG!)

I just checked and you they are indeed hiring a Mobile Developer. I would apply, but I only know Android, so I don't have the required qualifications.

Every since Andreas left I considered them to no longer be secure... Not that they didn't have an incident or two while he was present.

It may be no co-incidence they have Mobile Developer openings in their Job listings page at the moment. ;]

Those are some pretty big fuck ups, I won't trust blockchain.info anymore not even for just transfering something really temporarely.

I didnt suggest blockchain.info to anyone though that wallet was the wallet that was suggested when someone asked for a online wallet. Its not a wonder when all online wallets left and right got "hacked" and otherwise vanish. I remember things like ultrasecure wallets, best security and all and... hacked. So people tend to suggest blockchain.info because they still were there and they thought they would have fixed problems over time.

I mean lets say you want to bring bitcoins near to someone. You cant make him download something if you arent there, its easier to give him the login to a wallet and thats it. Giving bitcoins to a noob would mean risks anyway. No backup, no antivirus and so on.

Too bad. I didnt know that its SOO bad.

They should fire their android developer(s)  and anyone that was in anyway involved with it. Jesus Christ, this is one serious and ridiculous fuck up.

Blockchain.info has a good amount of security breaches since it started. Most of them are due to the developer's negligence and not ensuring the methods used are foolproof. If a person judges the trust based on the age of the product, it would be totally wrong. Even though it is opensourced, the track record should show their efforts put in to secure the customer's funds.

If they used random.org as a process for generating their RNG, they could ask the site to give them updates on the changes made or at least, monitor and debug their software regularly. [Bug existed for more than 5 months]

Ok, thats a real hefty story. Blockchain.info's wallets are seen as very secure since they exist since such a long time but this amount of amateurism is unbelieveable. Random number over http from a third party and then the message is not even parsed in any way. Thats simply only unbelieveable.

Never ever will i think about using a wallet from them. This things shows way too big problems.

Ok, one might think it could have been a third party coder. But even then, they are responsible, they handle the money from others and they showed a real high level of stupidity.

I expected they would take security more serious. If this is serious it's just unbelievable. Random numbers over either HTTP or HTTPS is not a good idea.

This is a beginner progamming bug. They shouldn't have made it especially when money is at stake. Do you not think it was one of the programmers who put it there on purpose?

This is ridiculous, maybe its time for us to move to another wallet 
Luckily i never use btc wallet on my phone, i only use my pc for opening my wallet 

If you need a mobile wallet, why not use Andreas Schildbach's Bitcoin Wallet for Android.  I've been using it for years and never had a problem.  You're responsible for your own private keys, no third parties.  Completely open source, you can download it from fdroid instead of the play store if you want to support FOSS on android.

Perhaps in their need for an android developer they hired an experienced mobile developer but one who did not come from a sufficient security background nor have proper experience with cryptography or bitcoin(and perhaps absent a bit of common sense in relation). Capable of producing the application but not able to provide the necessary security considerations.  I always assumed they would have their security team approving any code that's rolled out though -- and would imagine at least a few of their staff to be in the role of security analyst. I wonder how differently things ran security procedure wise when Andreas was with them.

After digging some more and understanding what actually went wrong (and discovering some of the decisions that led to the failure along the way)  I've updated the article at

http://dillingers.com/blog/2015/06/09/ce-random-numbers-and-response-parsing/

This "Cybernetic Entomology" series of articles is about breaking down bugs and showing how they came about - and after analysis, giving some basic observations about how not to get bitten by the same bad decisions that led to those bugs. 

So, if all were racing to scam others...we can even say no one got scammed.  
Quite a mess...I could never trust a lone satoshi to Blockchain.info after such performance. They totally FUBAR their business.

HW wallets are not mature and may not be as secure as you think: https://bitcointalk.org/index.php?topic=1022815.0;topicseen

I suspect there are several such someones and they must basically be in a race to see who can spend first when money appears in their address.


If you're just trying to set away some coins for a future date, just generate a secure keypair and print it out.  You don't need computer hardware in order to keep a number safe (just my opinion).

I have always used a blockchain.info wallet and was quite satisfied with it. Their sloppy coding is not giving me confidence to use them anymore. It's money at stake here and some users, quite unwisely, have their life savings in bitcoin stored on their wallets.

I have been postponing my purchase of a hardware wallet long enough. It is time to give it more thought.