Topic: "Online wallet services" are an invitation to fraud and theft (Read 3914 times)

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.

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.

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.

Source?

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.

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


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.



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.

Anyone thinking of developing or using an online wallet service should be thinking about offline reserves, as discussed here: https://bitcointalksearch.org/topic/open-letter-to-online-exchanges-and-wallets-store-coins-offline-34011

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.

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. When the code needs an update it has to be vetted before clients approve a new hash or signature.

I believe this is on its way into the HTML specifications but I haven't looked for some time. If we control the client implementation (Android, PCs) it's however implementable already today.



In the LastPass case, they are considered trusted (reputation, company) and the architecture is meant to protect against hacking instead. They take great care to make sure their systems serving up the JS in question aren't easily manipulated, and if a hacker were to extract their databases they still cannot do anything with them since everything is encrypted and only the end users have the corresponding keys.

But how would you see that work with a web service? You could implement a large part of the Bitcoin protocol in JS, 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.

It could work with the native clients though, to have it use a wallet on a storage provider (with encrypted private keys) instead of a local one. Would be a matter of generalizing the DB backend. This would also protect against wallet loss if the local machine is formatted.

Not giving you my private keys for storage, but using the data stored with you together with my local secret every time a key is needed.

This would be similar to how LastPass handles passwords (they're not stored with them, yet it's "like" if they were) and give the same security as Wuala has over Dropbox (employees cannot, ever, see your content).

It might also be interesting to make a personal wallet webservice for micro-payments. Only allow a certain maximum BTC per user, so that it is not used as long-term storage for large amounts of coins.

Users should then be actively encouraged to only use the service for web payments.

This will limit the risk a bit...

Assuming you're an honest individual I can still forsee the following problems.

1. How can you protect the bitcoin private keys in the wallet from...

a. Disgruntled employees (assuming you'll need employees)
b. Someone at the data center where your servers are hosted.
c. The backups you'll need to make. Who holds these ?

2. You're going to be constantly under cyber attack.

a. Who examines your code ?
b. Your software stack i.e. the 3rd party libraries you use how will you check that no-one inserts a specific attack on your site via a library upgrade.
c. How about your personal computers a hacker could gain access and use a keylogger to get root passwords ?

3. If you do well you'll be holding a significant amount of cash for other people that can easily be transferred and anonymized. You've also made yourself public on your site.

It's possible someone could attack you personally to get at the bitcoins. Have you thought about that ?

Would offering wallet.dat download (or alternatively, a gpg-encoded text file with private keys) by a good idea? So that even if your site goes offline - for example, if your servers are nuked or taken - I still have the private keys for my own addresses and can use them in a local client, and spend the coins.

This won't help against you purposeful stealing the coins, but will give reassurance against loss or destruction.

I wish you and all your customers good luck.

Exactly.

Side note: I can't help but wonder why so many people seemed to prefer mybitcoin over instawallet. Because it had a password? Both were e-wallets, and not worth keeping a lot of bitcoins in.

I want to be able to buy Yuengling for bitcoins.
[/quote]

the brewery is across the street.. literally smell hops each time I go to work.

I want to be able to buy Yuengling for bitcoins.

We registered where our company is located,  Pottsville, PA USA.    Our clients know who we are,  can verify an address, etc...  considering it's plastered all over there that it's a Yooter InterActive Company.

Agreed. With this thread being up for close to a month now I would say that anyone who lost bitcoins at mybitcoin.com is at fault for their own losses.

There were too many warning signs of fraud.

Plus it seems contradictory to keep one's wallet/coins on a third party server. The whole idea of bitcoin is to be and decentralized and storing your coins on a central server defeats one of the main beauties of the design of bitcoin.

What a shame....