"Online wallet services" are an invitation to fraud and theft

[dacoinminster]

Anyone thinking of developing or using an online wallet service should be thinking about offline reserves, as discussed here: https://bitcointalk.org/index.php?topic=34011.0

[1713513363]

1713513363

[1713513363]

1713513363

[1713513363]

1713513363

[Stefan Thomas]

But how would you see that work with a web service? You could implement a large part of the Bitcoin protocol in JS,

That's what Webcoin is. (server-side node, client-side crypto/wallet)

but if it is served from the wallet provider, it could steal any key that you enter by injecting a keylogger into the JS as well.

Basically true, but there are remedies. Also, it's not as bad as having your data on the server. If the server turned evil, they could only steal from people as they logged in. Anybody could monitor them (by looking at changes in the code they send out) and blow the whistle before they can steal from a majority of their customers (most users don't log in all that often.)

Anybody with HTTPS webspace can also host the actual JS application themselves. Then they only have to trust their own server security. You could even make a self-contained package containing a simple webserver that just serves the app locally.

Obviously, that's still not a satisfactory solution for mainstream users. So in the future, we envision using an authenticator. This could be a software authenticator or a hardware authenticator. The authenticator would be where the actual cryptography takes place and the browser based application only is responsible for the managing the wallet data. It would send the final, serialized transaction to the authenticator for signing. The authenticator would have a separate window pop up (in the software case) or a display with yes/no buttons (in the hardware case). It would parse the actual transaction as serialized for signing and display exactly what the signature would allow (Bitcoin has things like blank checks, so it would be a bit of a challenge to allow maximum flexibility while still making sure the authenticator "understands" what he's signing.)

Both authenticators could offer the same standardized protocol, which could be supported by any kind of client.

That's the most common argument leveraged against LastPass, and it's indeed valid (see below). The solution, so far not implemented anywhere, is to sign a hash of the JS snippet in question and have that verified by the client.

Someone implemented this for their own webservice cryp.sr: https://github.com/cortesi/apphash

I don't like the approach too much. Browsers are extremely complex software, so I don't see how this type of hashing could possibly be secure. Anything that allows the injection of some JavaScript would completely break the security. And if you're going to have to install some extra piece of software anyway, you might as well go the authenticator route, which is much cleaner because it also protects against all kinds of accidental spending, UI failures and other bugs in the (validated) software.

[jimrandomh]

Flexcoin announced a security breach today, so: Bump. Guys, using or telling people to use an Online Wallet Service is Not Okay. Not MyBitcoin, not Flexcoin, not StrongCoin, not Coinbase. The only reason a web site should ever have access to your bitcoins is if that website sold them to you, in which case you should transfer them to your own wallet prompty, or if you are using them to pay that website for something, in which case you shouldn't be expecting them back.

[Stephen Gornick]

Flexcoin announced a security breach today,

Source?

[westkybitcoins]

Flexcoin announced a security breach today, so: Bump. Guys, using or telling people to use an Online Wallet Service is Not Okay. Not MyBitcoin, not Flexcoin, not StrongCoin, not Coinbase. The only reason a web site should ever have access to your bitcoins is if that website sold them to you, in which case you should transfer them to your own wallet prompty, or if you are using them to pay that website for something, in which case you shouldn't be expecting them back.

You do realize how sites like StrongCoin and Blockchain.info work, right? You keep control of your keys, not them.

Originally in this thread, it seemed like there were folks who weren't wanting to make this distinction. It's an important one though, and one that still needs to be pointed out. A site you interact with where you keep your own keys is still a risk (they could potentially change their code to access your keys,) but on a far different level than one where you don't.

And if the claim is that none of them, even those, are worth using, then I'll it should be asked again:

How do you spend bitcoins away from home without using a site like that, or an app (subject to the same issues?)

It's all a risk calculation. Keep the bulk of your coins in at least one offline savings address, and only keep what you can afford to lose on anything that's not a full node.

All that said... I do agree that keeping coins in an exchange or "bitcoin bank" is just begging for trouble.

[Mosper]

Where can one get a security architect for this kind of job?

I thought Microsoft has depleted the supply by dragging all the good people into the Midori project...

Seriously, someone who can manage a 100.0% flawless system for all the running time -- those people are rare to come by. One contact of the private keys with a hacker, and your entire company is history. And possibly the responsible people as well, if the amount of value lost was high enough for people to get violent.

Here is some general (read: industry standard) advice.

Run suPHP and don't allow any permissions on your server other than 644/files and 755/folders.
Keep EVERYTHING updated CONSTANTLY - have someone whose job it is to make sure this is done around the clock
Run mod_sec and be very careful about what you decide to whitelist
Take advantage of services like http://sitelock.com and http://sucuri.net/
Force HTTPS and use a trusted SSL from a company like Comodo
Don't run any services that you don't need (disable ftp if you're not going to use it for example)
PAY ATTENTION to what is happening on your network. Many attacks not first try instant successes and if you're reading your logs and watching traffic you will catch these things

These are basic tips that will go a very long way to keeping your site/server secure. Most people are compromised because they are lazy and don't pay attention.

[Stefan Thomas]

There has been quite some progress in this area since this thread was originally discussed.

Here is a quick write-up regarding what I consider to be best-in-class security for web-based clients:

https://ripple.com/wiki/User:Justmoon/Secure_Bookmarklet

Note that the document above deals only with the code delivery problem (i.e. the server can send you a version of the client that steals your keys). This seems to be the key issue that web wallets need to solve.

Note also that a web client like this actually provides better security in this particular area than a downloadable wallet like bitcoin-qt, because it makes independently verifying the client much quicker and much more user-friendly and it is therefore significantly more likely that any given user will actually bother to do it.