Topic: Build a better bitcoin web service? - page 2. (Read 2508 times)

Yes, the human factor can't be eliminated but I think it is dramatically reduced if the transaction signing takes place on the client side, in browser code.  If the correct javascript is running, the owner doesn't have access to anything giving him the ability to take the funds.

What the owner does have access to do, is to serve up the wrong code and steal the funds that way.  But doing so immediately exposes the actor to the potential of getting caught (and before he has even been able to profit from it).

You still want to research and trust the site owner, but its a shit ton better than the mybitcoin or bitomat fiascos.  You or a 3rd party could also keep backups of the encrypted accounts, in case the site was shut down by the hosting company/govt.

EDIT:  Or, best case- open source team (A) hosts the code/front end, and site operator (B) hosts the database

Like I mentioned in another post, the human factor is something I haven't found a way around. The hacker can be deterred/slowed enough that damage is minimized, but there's really nothing to stop an owner from inserting code to steal passwords or redirect transactions and such.

The only safeguard is still: don't store more coins than necessary!

Agreed, javascript is the way to go.  Its easy to read, and its on most devices including the important ones for web access (the phone). Obviously its Turing Complete anyway, so it can be done.  It would actually be possible to host the javascript on a separate server than the database as well.  Downloading compressed js code is more trustworthy from an unrelated party that doesn't have access to the data.  And the js would often be cached as well, so some significant size is acceptable.  Again, this is all transparent to the non-technical users, and merely the fact that a motivated technical user could uncover fraud is a deterrent.

I'm not as concerned about two factor authentication (which could under some schemes require OS access outside the browser).  Ideally you're only keeping a small amount of funds per account, but the design of the service should reduce the attack surface from an owner or hacker trying to steal the funds from _all_ accounts.

The problem with Java is the split between Oracle and Google, on top of that, one of the most popular device people use doesn't do Java, or Flash

And we do want something that works conveniently for everybody.

Verifying checksums doesn't help when there are likely to be regular updates to the Java client to patch bugs or improve usability/security.

Even a tech savvy person can't tell if it's a legit change or not compared to the number of web devs who can read Javascript easily. For this reason, the Javascript should not even be minified.

I'd also considered that Java would be a more robust platform to build from.  Its not quite as pure as javascript where everyone can see the code.  But at least if it is open source, a determined user could check the bytecode check sum at any time and this should be a strong deterrent to fraudsters.

I've been thinking about something similar but unfortunately there are security gaps that current Javascript alone cannot cover. The solutions I can think of usually requires a two factor authentication or at least a Java applet, which then opens up the trust question about the Java applet itself. Or maybe I'm just not l33t enough to see the solution

Any comments on this?  Or is there a dev thread this should go in?

We've had potentially $1M of bitcoin stolen or lost at mybitcoin, and a system like this could solve the problem.

If someone wants to start this project and open source it, I can put in some coding time, I just don't have the time to own it.

I find it ironic that Bitcoin (by itself) elegantly solves so many problems people are currently having with their new online money:

- How to safely, irreversibly, and quickly move funds around (as opposed to Dwolla clawbacks, multi day bank delays all around)
- How to avoid the need to trust a 3rd party (mybitcoin, bitomat, etc)
- How to stay safe even if a 3rd party is hacked (Mt Gox exposing everyone's passwords)

However, I think it is safe to say that 3rd party web services are going to be required if this economy is going to grow.  My mother, for example, would need a simple, easy to use online payment system.

My proposal:

An open source ajax web service which performs key actions in browser, and stores data only in encrypted chunks from browser calls.

From the client view:

 (a)  Client logs into site with username/password
 (b)  Client is presented with personal addressbook, transaction history, account balance, etc.
 (c)  Client can send to funds directly, and peer to peer (transactions within the same web db) can be instantly satisfied (so merchants can adopt)

From the server view:

(i)   Login is sent to server, encrypted (stage 1).  Server receives encrypted password, matches against database.  If successful, data blocks can be retrieved to send to client- but these blocks were stored encrypted.  The server never has the key to decrypt and is blind to what the data contains.
(ii)   Javascript on client browser uses the password to decode the data blocks (stage 2) in order to present seamlessly to the user.
(iii)   New data to be stored in the account is encrypted by javascript, and sent to the server via ajax requests.


Private/Public keys:

The private key is only available encrypted on the server, and only the javascript client side ever "sees" the decrypted key.  This key is used by the browser to sign any new transaction requests, which are then submitted to the network by the server side (to work around browser security).

The server does maintain a decrypted copy of the public key.  This is used to also maintain a total bitcoin count for that address (since this is public knowledge anyway, no privacy lost).  If one or more requests exceed the total in the blockchain, that request can be instantly denied until verified by the network.

Although it is still possible for an evil site operator to steal your coins, it is much less likely.  The combination of in browser operation and open source peer review can provide a lot more confidence to the user, and this should be enough trust for day to day spending balances.

Between the existing js bitcoin and server side bitcoind projects, I think this is feasible.  Not sure if I would have that many hours though, so hopefully somebody else wants to run with this...

Thoughts?