Topic: The Strong Coin hack explained (Read 1871 times)

the transactions were easy to track....he didn't go through the washer and other services....

it wasn't just luck, the scammer had bought into another scam, that his bitcoins would retain value in StongCoin no matter what.

But when you can only send coins to an address chosen for you....that value is zero.

From here an online service would have to offer some sort of open source + crypto solution so that you could ensure they were not substituting your address...though that may be really hard to do.

Just make sure you always have you private key and always send a small test amount first. (though thats no absolute guarantee either) remember clients are windows on the blockchain, not the block chain, its that private key that alows you to go through the window into the block-chain

So it was just luck that the thief ended up transferring to strongcoin instead of a private wallet. 

Where do we go from here?  It's kind of an ethical dilemma, because while we'd all like to think that bitcoins are unpoliced, there are definitely 3rd party services that can do this and seize funds as they see fit.  Are we going to end up with a Network of Trust between large-scale bitcoin processors that attempts to detect and intercept grand-scale thefts?  Or are we going to have to eschew the very centralization we're trying to create?

There seems to be a lot of misinformation about what happened here. I will give my view as I understand it feel free to criticize.
(I have professionally programed front end JS for financial institutions, that interfaced with a bespoke oracle java middle ware)

The Hacker ended up on an island in strong coin as any address they chose to send to while in strongcoin would be substituted server side for one chosen by Strong Coin.

The Hacker could have still gotten his coins if he knew the private key for his address in strong coin, loaded that into any client and send on.

StrongCoin could have even prevented this access to the private key, if they disabled the serve up private key for this user on the server side, and the Hacker had not already taken a copy of the private key. At that point, the Coins would be locked up for good. If the Hacker never attempted to move them. As soon as he did then send them he would be into StongCoin territory


In detail.
The Hacker thought they were sending BTC to -----> [1]

StrongCoin rewrote the back end so that when Hacker logged in, any address the hacker chose, would server side be ignored and it for him was hard coded to address  Chosen by Strong Coin Mod.

SrongCoin Mod subs [1] for ------>[2]

This was not as I understand it a javascript detectable event, not would it require any change in any java-script served up.

This was, all server side.

Even If I am wrong and some how the JS was modified, this could be done all server side as I understand it. Unless I ma mistaken, you web borwser is not acting as the client to send anything...stongCoin is. If I were wrong it would not matter if StongCoin even existed as you could do it all from your browser without them ever.


A separate attack for JS would be to serve JS that grabbed the password before it was encrypted and send that, and have this on the public hub as well so the check client would not catch this. This was not done.

Notes
You should always have access to all your private keys.
For any address you use or create.
A wallet.dat is not good enough as it may corrupt
A private key for every address is the gold standard
We need a better pywallet.