Topic: Build a better bitcoin web service? (Read 2470 times)

An online wallet isn't the most secured thing, but for a lot of minor daily transactions, it's probably the most convenient way to go. And we won't be able to get the average joe onboard without an easy way to do things.

I think something that works is the best way to move forward. If they can try it and see that it does work and address the major problems, then higher chance of sites adopting it.



There is a bitcoinjs project that seems similar to what we're attempting but I think it's not really done yet. Haven't looked at it in details, I tend to prefer to do my own research and brainstorming for something unfamiliar without looking at existing code, to avoid being influenced by existing implementation as well as avoid potential legal issues in case those code ends up proprietary

people need to stay away from online wallets

That's my goal too!   


Right, a sort of 3 tier approach: data backend, Javascript core functions, presentation front end.

The presentation tier should allow anyone else to play with the UI without changing the core security.



Should this go to a development thread?  I started the post here as a very general topic that I think is of interest to the community- how does the community move forward with web services they can trust?

But if we can get some like minded developers who also are thinking of this open source in browser concept, lets take it somewhere and start the serious nerd talk

The problems may be entirely due to my paranoia which assumes the host cannot be trusted so communications must be done in such a way that the host gains limited information even when compromised. But at the same time, the system cannot be so draconian that it wouldn't work at all

Currently, I've been looking into the various encryption possible, e.g. OpenPG -> RSA/AES and Blowfish/Twofish (allows changing key length) if necessary. One issue is that in Javascript, the encryption process will be slow and there apparently isn't any complete library to do the whole public/private key thing. Most of them assumes we would only want to encrypt and send to a trusted server, a lot of them also rely on having access to an OpenSSL service to generate key pairs, although I found one source for doing this in-browser, it needs to be adapted to eliminate inherent weakness in the JS random generator.


The front end definitely should be open sourced and flexible, I was thinking more of a reference API built on top of library of core functions. This would allow custom front end by implementing custom top level functions to replace the reference API without the need to change the core functions. The core functions could be hosted on public servers, which reduces the amount of "suspicious" code to be verified to only the custom frontend.

We might be getting seriously off topic for this sub-board though

What are the issues you're finding?  I know there are open source javascript encryption libraries, but I haven't researched how well they perform or are vetted.

Given that you can interact with the user, accept the password, etc entirely within the browser, and assuming that a suitable and trusted existing encryption library can be used, the rest is just standard ajax between js/server.  A lot of work of course, but no new ground.

I think you're right that we should work on the common browser front end and treat the JS code as inherently separate from the backend code (we'd define an API I suppose).  I would prefer the JS to be hosted separate from the server operator, but I would still accept a one host system, since its still a big step forward.  But as long the browser front end is treated separately, its the right road map.

I'm researching and working on something along those lines but there are still issues with trying to do encryption within the browser. Not to mention the backend problem.

I would suggest that maybe we can work together on a common browser front end, that would work with different backend. This way, we always have the option to switch between different backend solutions if one proves to be better or worse.

Yes, anonymity is still achievable, and more backup options are always better.

The strongest point I'd like to make is: retain the password and all unencrypted data within the browser.  If you're willing to work on a system to do this, I'm willing to contribute to the open source ajax part of the solution.

> One of the cornerstone of Bitcoin is anonymity. Tying the wallet to a Google account?
> Com'on man, might as well just put out a public list of which transaction belongs to which passport number

Intersango Bitcoin Exchange already do that!! It is not a big deal... Not for me at least...

Also, you can create a google account only for that purpose...   

Honestly, I don´t care too much about anonymity, only my balance is a secret and it will remain a secret in that system...

BTW, you raised good points here... I´ll take all of it in consideration...

Best!!   
Thiago

Having to run a VM just to use a wallet is still a little bit overkill. Not to mention the resources needed to keep all those VM running, even using resource over-commit and memory ballooning. Also the long term future of Xen is questionable, being sandwiched by RHEL's preference for KVM and the incumbent leader VMWare.


Yet it's also one of the easiest thing to throw away under the right situations.



The problem is always a compromise between redundancy and security. Strewing so many copies of the wallet around, even encrypted, could invite security concerns.



One of the cornerstone of Bitcoin is anonymity. Tying the wallet to a Google account? Com'on man, might as well just put out a public list of which transaction belongs to which passport number


We start from very different ends I guess
I'm cynical so I assume nobody can be trusted beyond what I'm willing to risk. So I would design such a system that it has to be as secured against myself and everybody else before I considered it secure.

As for the thieves part, a lot of people didn't start out with the intention to be a thief. There are many examples of well meaning people starting things with good intentions, but along the way, things changed, people changed. So while your intentions may be good, the system MUST be secured against you betraying that trust as well.


All the best man

Mmmm... I not express myself in the right way... English isn´t my native language...  sorry...  \o/
This kind of scripting is just an example... I´ll never tell to a user of an Ajax Web Interface to do that... This will be done automatically...


Agree! But, in my proposal, you will be the owner of your server (virtual in this case), including the Bitcoin binary and wallet.

What I can do is just provide a pre-configured version for regular people, but you can upload your entire Linux image to that cloud, including the Bitcoin binary...

I see people saying that a Bitcoin/wallet within a Virtual Machine is not safe but, that is true for crap systems like vmware esx or virtualbox, etc...

But that is not true for Xen.

Xen can provide a "security through isolation", so, I, the owner of the phisical server, am unable to access your portion of RAM memory.

BTW, everybody can check the binaries of a system provided by me, to see if it is original or cracked.

So, I'll never going to provide a cracked binary (or compiled from a patched source) because my name is what is at stake. And my name, my reputation, is one of the most important things in my life...


I already think on this, first, the cloud folder will host a encrypted wallet, second, the backup will be sent to multiple clouds at the same time, so, you think that your file will be lost/deleted from Dropbox, GmailFS, Ubuntu One and from your PC at the same time?!?!

Oh! BTW, in my proposal, you will be able to access your wallet.dat through SSHFS!!!  


You´re right... The non-technical user is the most weakest part of any IT solution, that´s why I propose a solution like this... A solid backend environment, powered by Xen, Linux and Eucalyptus (that is a huge part of the proof), with a easy to use Ajax Web Interface for "normal" people, with automatic backups, etc... People will just need to "link" their google account with the Web Application to start the backup procedures automatically, for example...

My point is: It is perfectly possible to provide a trusted, secure and easy to use Bitcoin online wallet. Within the law!

I am the kind of people that trust in everybody for the first time, until somebody proves the contrary.

I feel that the feeling of trusting in people are going to hell... But this is not the kind of society I want to live. In fact, I think most people are trustable in first place, not the inverse.

I know that there is many, many thiefs in this world but, I am not one of them. I am one of this people that can be used to make this world, a better place, starting building a safe place for people´s Bitcoins. Because our money, is sacred and sweaty.

If I gonna build this service, it will be entirely open source, so, you will be able to read my documentation and build one identically with your own computers.

Nice talk!  

Regards,
Thiago

Two things:
    (a) lost data: I think an automatic backup/export button is safer, rather than less safe.  Sure horrible code might overwrite data, but at least you can have it backed up everywhere.  Also, just to be clear each bitcoin address only needs to be backed up once, even if used for many transactions.

    (b) backup getting hacked:  Bitcoin already exposes all of its encrypted data publicly, in the block chain.  As long as encryption is sufficient, you're just as safe backing up this server elsewhere.  Further, knowing this is incentive to provide strong safe encryption instead of a misguided reliance on the server never getting hacked.  Security through open approach instead of security through obscurity is always better.


Yes, this is the risk.  However as long as the right Ajax code is used, the rogue admin never has access to the user's passwords.  Ideally, this Ajax code could be hosted by a 3rd party open source repository, unrelated to the data admin.

This is the way I would envision it:
User browses to "SuperAwesomeBitcoinWallet.com", which is registered and maintained by trusted community members.

- SSL Certificate on server A confirms identity and secures the transaction.
- JS code is loaded from server B, an open source repository
- User logs in, and the ajax loads their bank provider of choice server C
- Server C loads custom graphics, branding, super awesome user interface, etc, but the Ajax is still from server B

Server C runs the "business" of branding, customer experience, database storage, etc.  But server C never has access to the user password or unencrypted data.

You see, one of the consistent problem with the tech-heads in bitcoin is this: You assume every user is going to be a techie or can be expected to learn to do things The Right Way. Fortunately for me, real life has beaten that assumption out of me and paranoia has always proven to be invaluable when things go fubar.

We both know how to write a bash script and can recognize the common flags for numerous commands to know when somebody's trying to pull a fast one on us. Not the average bitcoin user we want to reach with a "user-friendly" front end.

The average joe will almost inevitably save the same file to the same location. For many of them, be it on Windows or a Mac, it's going to be the default desktop/Documents folder or equivalent.

You can be almost 100% sure they are going to over-write the same file.




Only if it's my server I'm SSHing into

Otherwise, I'm going to assume the other admin has a modified sshd and some logging service that records every single command I send in.


Sorry but I don't trust any "cloud" folder. Especially not when their TOS specifically disavow any responsibility if things got lost/deleted.


I like Linux, I've been testing out and trying out Linux since Slackware and dial up days. Know what turns off the average user? It's when somebody does the I-use-Linux-so-I-am-more-elite-than-you-fools thing on them and go on a rant about their OS. Sad to say, I used to do that too.

But the average person doesn't care about your OS religion. They want a tool that does what they expect and just works. If there is a problem, the first thing they are going to blame is your program, not the OS, not themselves.

For the record, I use a mix of Windows, Linux (including Android) and even Apple computers/devices. Whatever works best for the purpose and situation.



So you claim, but where's the proof that YOUR system is more secure than any Windows?

The weakest link in any system is always the user and in some cases, an over-cocky dev

3. I have a rule in my IT life: never overwrite anything. This can be so simple as:


6. Right and wrong at same time... All passwords are encrypted and saved into /etc/shadow only (or even a LDAP backend), so, how long will take to decrypt a strong password?! +100 years?!

6.1. Don't you trust in your system, when you type your password to login into a SSH session?! This can have the same level of security than SSH has.

Also, it is perfectly possible to encrypt your Dropbox/GmailFS/Ubuntu One/Whater cloud folder too...

What do you think Xephan?!

I know that deep inside, trust between two parts must exist but, the provider can have a high level of security and strong backup procedures that a single user never dream about. So, where you prefer to host your wallet.dat?! Within a strong cloud that you can trust for sure or within your freak Windows?!

Sorry, I don't know if you are using Windows...

I can garantee that a system created by me, using well know open source tools and pretty well documented, is far, far away more secure than any Windows out there.

BTW, there is no secure Windows. So, every single person wich hosts their Bitcoins in Windows, have the same level, or worst, of security than MyBitcoin... Windows is a joke... Like the todays online wallet providers.

Best,
Thiago

Playing the role of the malignant admin again

3. Sounds like the perfect way for a rogue admin to backup a wrong/empty wallet over-writing the user's backup. Or it might not even need to be malicious, a bug could cause the backup wallet to be wiped. Furthermore, sending it to yet another external system seems to be increasing the vectors by which the wallet could be stolen/attacked.

6. Doesn't stop a rogue admin from capturing the user's passwords in the first place to use for decryption

This is all excellent!

(3) Is a great idea.  Whatever happens to the site (crash, raid, hack, etc) some other system could potentially recover the users bitcoin access.

What about open sourcing the Ajax front end and hosting the code on gitub or another 3rd party?  Your service could still be the main provider- and collect transaction or storage fees.  But if you brand the solution, and you are first to market, then you should be the dominate player even if someone else uses the code (ie open source shouldn't really hurt your market share, and should increase the total market size).

But the key thing is that open source helps the end user trust you, which is what the bitcoin community really needs right now.

I have a lots of ideas to help this...

As for example, I´m gonna build some kind of online Wallet storage based on Eucalyptus and Ubuntu (open source Cloud Computing).

1- Each user will have its own private Bitcoin / wallet.dat "instance";

2- The wallet.dat will be stored withing the "Walrus" (Eucalyptus persistent storage);

3- The Ajax interface can have a "backup wallet button", wich stores your wallet within GmailFS, DropBox, or download it directly to your compúter. Also, after every transaction, the system can automatically backup your wallet in any place you want (pre-configured).

4- The users will be able to download the wallet.dat to its own computer and open it with Bitcoin software;

5- The users of this system, will not have access to the "Cloud Frontend", the bitcoin/wallet will be accessed through a Web Ajax Interface only;

6- The persistent storage of users wallet (Walrus) will be encrypted with the user password, so, the Eucalyptus administrator (ME and my team) will NOT have access to ANY wallet.dat, never.

 In fact, I´m doing this setup right now! But only for my tests and without a Web Ajax Interface...

 This will be easy to use for anybody.

Cheers!
Thiago

True, but there are ways to optimize this strategy once there are volumes. Again assuming the role of the malicious admin, if the system isn't proof against anything I can think of to game it, isn't secure enough to me, I would analyse my user base and their activities for profiling. heck I could do a survey in the name of "improving the service". From there, I should be able to score users into two groups: noobs and savvy. Naturally I would target the noob users for malicious code injection and to further reduce risk and maximize gains, I would only pick on those who store the most bitcoins.

Again, this is defeated by limiting the value stored, making it more profitable for the admin to remain honest than to risk stealing

Storing the frontend on a public service may be one way but I can foresee businesses who would want to customize their frontend, offer value added and such to gain customers. After all, they can't be doing this just out of goodwill. Even not for profit, servers, bandwidth & power need to be paid for. So they would probably end up using their own modifications instead of using an external front end, unless the community as a whole wants to fund such a service, which would require somebody to admin it and then we're back to the admin as a weakness issue again.



That's why I figured 2 factor authentication may be necessary. Trojan can steal the password but server won't act on a transaction that doesn't get fully authenticated.

(1) I see what you're saying, the owner would be more inclined to take the key.  However it is still very different than having unfettered, and hidden access to the key.  The owner would need to make a public move, even if that move is only every X transactions.  He's taking a risk before reward.  And this might expose him for days before any significant payoff which is much different than simply walking off with the $1M in holdings on the server.

(2) I don't think the key is any less secure in the client browser.  Suppose you keep the key on the server- a trojan hijacking the user still has access to their password, through this, to their funds on the server.

I've thought of that as well but this exposes two surface for attacks.
First is the owner can serve up code to steal, not funds, but the key/password necessary and send it back. If I were to do this, I wouldn't send the bad code every time. I'll just set my server to serve up an edited copy of the .js every X transactions. Just a matter of time before I get all the public key and minimize the possibility that anybody checking would hit on the sneaking in. And I definitely won't do that until volume is high enough to justify it, so early scrutiny won't help here.

The other surface is by shifting the signing to the client side, it opens up vulnerability on the user end. A single server(cluster) may be safer in the hands of a group of competent admins, but trying to ensure thousands of users are trojan/virus free? Kinda hard