I've just updated this to include support for syncing settings with a remote server (locally encrypted with AES-256 before storage) as well as updated the plugins to actually work with the latest APIs of their respective websites.

It also includes support for wallets with passphrases, so the RPC plugin is now generally usable without having to worry about exposing your wallet.

So I've just released v0.3.10727, which adds some basic support for MtGox (basically read-only things like showing balance and open orders).

If someone is interested in writing a ticker viewer and trading operations into the plugin, get in contact with me via the forum's PM system or email.

Thing is, if someone has broken the Chrome sandbox between applications, they could just steal the raw data they want and then send the request off..  CAPTCHA won't do anything.  But as I mentioned before, at that point, if they can break that security barrier, you have to question whether or not they can just take control of the whole system (I'm not sure how sandboxed processes are between each other in Chrome relative to each of them to the OS, but I would assume it would be similar).

So assuming that the Chrome sandbox holds up (which it should), the only thing you have to watch out for is rogue Collate plugins (as in account types); but that's why we screen any plugins that are submitted so it doesn't happen

EDIT: Also think of it like this; if they can break the security barrier between website <-> chrome extension, then they'll be able to break the security barrier between website <-> website and steal any session data or login information that you're sending to normal sites.  So at that point, I don't think it's really much of a concern (i.e. they could just steal the session data to Tradehill anyway.. why go to all the trouble of getting the information out of the extension?)

Not quite possibly yes, the answer is completely yes.  It's for this exact reason that I've deprecated the Local Server plugin in 0.2, or at least relegated it to a highly not recommended option when the Block Explorer is available (which conveniently enough only requires the public BitCoin address to show your balance, rather than having to set up RPC information).

It seems that the Chrome Web Store version is not yet 0.2! I meant to do that previously, but it seems I forgot (I'll get it done now).  It addresses the following concern:


In 0.2 you can use the Block Explorer to examine your wallet without actually having to run the BitCoin client.  This means you can keep wallet.dat on an encrypted partition via TrueCrypt or w/e and you can still monitor your account balance (although to send coins you will still need to start the BitCoin client for obvious reasons).  In 0.2 the Block Explorer method of viewing a wallet supersedes the old way of connecting to the BitCoin client since the latter requires that your private key be stored in memory all the time (which is a bad idea).

UPDATE: 0.2 is uploaded to the Chrome Web Store; I think it takes up to two hours to actually update in people's browsers however.

Just to let everyone know, this project isn't dead, I've just been super busy lately with some other things.  Development should start again next week sometime.

The exchange has to operate in real-time, waiting for users to release funds is not an acceptable solution (and introduces problems such as "Oh the price went up... yeah about those funds...").

As I said previously, if an attacker is monitoring all the communications between the user's computer and the exchange, and has access to the files on the exchange, there isn't really much you can do in the way of allowing the exchange to safely create transactions on the user's behalf without the situation being compromised.  It's fundamentally flawed.  If the exchange has to create a transaction for the user, and the attacker has that level of control, then the attacker can withdraw coins at will.  They only need the decrypted private key to do so.

That's the point of this; it isn't to prevent an attacker withdrawing coins when the user is being observed making trades; it doesn't protect against that and quite frankly, I don't really see how anything could.  What the design does do is prevent an attacker from withdrawing coins from accounts that he hasn't observed.

This is in contrast to existing systems where an attacker can manipulate the system and withdraw any coins he likes, when he wants to, without having to observe anyone.  There are no restrictions on what an attacker can do to existing system.  That's what this paper set out to solve and that's what the design does.

As I said previously, until you can show me a solution in which the exchange can use a private key to create a transaction and an attacker still can't manipulate the transaction as it's being created, then there's no point in continuing the discussion further.

Unfortunately you haven't actually detailed any solutions yet other than stating the current system is unsatisfactory.  If you want to outline exactly how this can be done, then I'm all ears, but until then, I don't think this conversation is going to go anywhere.

For future reference, the requirement of the paper which you quoted explicitly details that the situation that we've been arguing about is noted as (practically the only) attack vector on the system:

No, it does protect against that.  If an attacker breaches the exchange, they can not place trades on behalf of a user unless that user makes a trade after the exchange is breached.  That's the key point here.

You can't protected afterwards given that the exchange must be able to easily move coins around and must be able to transfer coins when an exchange match is made.  The alternative to this system would be for the exchange to wait until the user transfers coins from their BitCoin wallet and then wait one hour before the trade actually takes place, which is not an acceptable system for an exchange.

There isn't another way that the exchange can have the private key as needed, the information to use the private key for signing (such as decryption information), and still not have an attacker be able to observe those variables.

Nothing stops you from recording the master keys and differencing codes if you had that level of control over the server, the intention is that you wouldn't be able to automatically access the BitCoins used by the accounts in the past (meaning you can't steal all of the BitCoins from the exchange).  It's about minimizing damage.

Unfortunately, since the exchange must have easy access to BitCoins for trading (i.e. they must have a wallet of some kind with the user's BitCoins in it; currently I expect this is done with one giant wallet, here it is one wallet per user) there is no way to have both the exchange accessing the coins without you providing the details required to open the wallet.  Please note that you can't simply send BitCoins to the exchange when you want to do a trade, as it takes up to an hour for a transaction to be processed and confirmed (which is no good for trading).

Transmission of the master key on trade requests is exactly what keeps it secure; an attacker can not break into the exchange and steal coins without also knowing the master key, which is never stored at the exchange.


It's not about trusting the exchange, since you must originally trust the exchange when you make trades (because for that short time, the exchange knows the master key and differencing code); rather it is to prevent attackers from gaining access to your wallet after-the-act.

In the case of MtGox, this system would have prevent the type of attack that was seen; an attacker would not have been able to place large trades on accounts unless they observed the user actually making previous trades.


Unfortunately if it's firewalled off and inaccessible, then you're implying that the web server also has no automatic way of transferring coins from the user's exchange wallet into the "Active Transactions" pool, which is not an effective situation for an exchange.

A few people and I just finished writing up a short paper on how 3-factor authentication can be used to secure exchanges such that an attacker can't place trades on a user's behalf without compromising the user's computer and the exchange (if the user is using physical verification).

http://www.redpointsoftware.com.au/papers/3FactorAuthenticationForExchanges.pdf

Feedback is appreciated (especially anything related to flaws in the proposed system)!

I've just updated the source code in the repository (https://github.com/hach-que/Collate) to support reading a wallet via Block Explorer which means you now don't have to run the BitCoin server or leave your wallet unencrypted to do so (since it must be unencrypted for the BitCoin server to run).

So in summary, it's a much safer way of viewing your wallet from Collate since you don't have to leave your wallet unencrypted (and you shouldn't).  The main differences between the Block Explorer and the RPC-based plugin is that the former can't report or control local mining (but who does CPU mining these days?) and it also can't send coins on your behalf.

I've also merged the BTCGuild mining pool plugin from Wonderbread into the system, so that's built-in now for anyone using that mining pool.

This is the RC to the v0.2 release, however it's appreciated if people test the version in the repository so I can iron out any final bugs before packaging for the Chrome Web Store.

332-bit KeePass passwords.  Damn near unbreakable and easily replaceable too.  I'd recommend it to pretty much anyone affected by this (it's also good for generating super-strong passwords for the TrueCrypt partition that your wallet.dat should be sitting on).

I haven't written a Firefox extension for years and I've never written in Opera extension at all (nor would I have the ability to maintain those).  I'm hoping someone with the relevant experience might have a go at doing it (it's 99% standard Javascript so it should port easily).

I just finished the submission to the Chrome Web Store; I recommend that you install it from there as it means you'll get automatic updates when we release new plugins.

Overview

For the past few days I've been working on a project called Collate.  The goal of the project is to allow a user to view and manage all of their BitCoin wallets in a single place, this means:

• Wallets running in the desktop client.
• Wallets stored online with wallet providers.
• BitCoin balances for trading sites (such as MtGox).
• Earnings from mining pools.

Latest changes (v0.4.21029)

Version 0.4 brings support for syncing configuration with a server (locally encrypted with AES-256).  It also updates the plugins to work, and disables MtGox (their API is requires more infrastructure to use now).  Importantly, it now supports wallets that use passphrases.

Downloads

Collate is written as a Google Chrome extension, but importantly it's not restricted to being a Google Chrome extension; the Chrome-specific element is the browser action (and if you can't tell, this is an encouragement for someone to port it to Firefox ).  It's designed such that it can be easily extended with new types of wallets and it's licensed under an MIT license (so it's open source).

You can install the application from the Chrome Web Store at https://chrome.google.com/webstore/detail/anlcpclkmbeeoglfgbfboogijdkbohkn.

You can download the source code from https://github.com/hach-que/Collate.

Features

• Extendable with plugins
• Wallets:
  • Local BitCoin Server
  • Block Explorer (via BlockChain)
• Mining Pools and Control:
  • OzCoin
  • BTCGuild

In the works

An initial plugin for MtGox had been completed; but it does not yet support trading or the MtGox ticker.  If you're interested in working on this, get in contact with me.  Outside of that, we're planning plugins for more mining pools and wallet providers (it depends on what they support).  In addition, we're working with the developer of BitMiner to provide a plugin that will allow you to control GPU miners from the interface.

Screenshots

[1] [2]

I've been working on a project called Collate (http://www.github.com/hach-que/Collate) for the last few days and was hoping to be able to post it Project Development forum.