E-Wallet better or not?

[JohnnyCashout]

Should you trust Bitcoin E-wallets?

http://janelondon.files.wordpress.com/2010/11/images.jpg?w=260&h=194

[1714048183]

1714048183

[1714048183]

1714048183

[1714048183]

1714048183

[1714048183]

1714048183

[1714048183]

1714048183

[1714048183]

1714048183

[gopher]

I have a better idea

Why don't you find someone who is capable of re-writing the official Bitcoin client in PHP, with a small addition like built-in authentication having the password scrambled with one of your keys (256-bit PKI authentication). Make sure you trust him not to embed a trojan horse in the code though.

Then find a reputable and well established web-hosting service company and rent a single page php only account (<$10/year), where you run your PHP script Bitcoin client.

That way you can have your wallet in the cloud, accessible from any device you may have, regularly backed-up by the cloud service, but still keep it private and secure and sleep peacefully knowing that no stammer can steel your BTC.

The Vibanko.com sourcecode is open:
https://gitorious.org/vibanko

Vibanko looks like an e-wallet service run by someone else, where you send your coins to someone else's address - therefore that could allow a scammer to steal and run away with ones BTC - I do not see a fundamental difference between the proven scam sites and Vibanko - I don't understand what makes it "reliable and trustworthy bitcoin wallet service" as it claims.

But yes, I agree that Bitcoin Consultancy should be capable re-writing the official Bitcoin client in PHP for ones use in private-on-line-e-wallet arrangement - that way the risk of entrusting some anonymous entity with your coins is eliminated.

[dogisland]

It's for these reasons I built http:// strongcoin.com

We don't have a wallet.dat.

We create you keypairs in the browser, then encrypt the private key in the browser before storing it server side. Only you can decrypt the key as only you know the passphrase.

The only time you actually need access to your private key is when creating a payment. Again we decrypt the key browser side and create the transaction which we then send on to the bitcoin network.

So all the benefits of an e-wallet with a huge reduction in the risk.

[dogisland]

So there is no risk that you will walk off with the bitcoins deposited there? This sounds like a very good implemantation of an online wallet.

Has anybody used this service before? How is the reliability? The ease of use?

That's correct I can't access the private keys so I can't spend the coins.

There are about 30 people using the service currently and I've had some great people on this forum help me with issues. The main bulk of the JavaScript was built Stefan Thomas over at bitcoinjs.

In the next few days I'll be launching some testing bounties to help nail down any remaining issues.

In terms of usability there are still some things that don't flow as I'd like, I have some ideas for improvements.

[casascius]

That's correct I can't access the private keys so I can't spend the coins.

The only itch I have with regards to StrongCoin is that although it may now be designed in such a way that the operator can't spend the coins, there is nothing saying that the site at any point couldn't be covertly modified either by its operator - or by an intruder - to start collecting people's passwords.  And since people aren't checking the Javascript each time they use it, such an attack would be quite successful.  Average Joe doesn't have a chance of checking the client-side code for security, even if he wanted to.  It's a conceptual flaw, so to speak.

For argument's sake, the paper wallets I sell by mail carry the same conceptual flaw - in theory I could scam my customers - and a paper wallet where NOBODY has any possibility of scamming is going to be a higher quality paper wallet.  My customers knowing my IRL identity is a good control, but still, 1 person potentially having your keys is 1 person too many from the ideal.

Compare to BitAddress.org, which generates paper wallets, and arguably could carry out the same attack.  But BitAddress.org has been built in such a way that one can copy the .html file and run it from an offline computer.  In effect, the average joe has a solid way to audit that the paper wallet generator he is running offline isn't communicating secrets to a server, simply by observing that it still runs without his internet connection.  If a current or future build of the bootable LinuxCoin CD had a copy of BitAddress.org's generator pre-installed, it would be about the best way I can think of for someone to generate their paper wallet (assuming they didn't have to fight with installing printer drivers).

[dogisland]

The only itch I have with regards to StrongCoin is that although it may now be designed in such a way that the operator can't spend the coins, there is nothing saying that the site at any point couldn't be covertly modified either by its operator - or by an intruder - to start collecting people's passwords.  And since people aren't checking the Javascript each time they use it, such an attack would be quite successful.  Average Joe doesn't have a chance of checking the client-side code for security, even if he wanted to.  It's a conceptual flaw, so to speak.

I'm aware of this issue too. Possible solutions I'm considering are...

1. Some sort of browser plugin that verifies the JavaScript.
2. An external trusted 3rd party/parties that validate the JavaScript. i.e. Some sort of Pingdom service that does an SHA of the HTML and JavaScript.
3. Hosting the JavaScript on on Github.

If anyone else has a suggestion I'd love to hear it.

But BitAddress.org has been built in such a way that one can copy the .html file and run it from an offline computer. 

That's true, but it can't make payments. So I think StrongCoin currently has the best balance between convenience and security.

[casascius]

That's true, but it can't make payments. So I think StrongCoin currently has the best balance between convenience and security.

If all of your code were available as a downloadable client as an .html file, or a series of .html files (that could be saved to someone's hard drive, or burned to the LinuxCoin CD), and used ajax calls or something similar to query for transactions on the blockchain and submit signed transactions via your website, it could be deemed a whole lot more secure.  The risk isn't in interacting with your website, it's the theoretical risk that you or an attacker could serve a different page once in a while.  A third party can't really rule that out, because they can only validate the page you sent them.

Yes, this would interact with the internet, but somebody else could validate that it had no capability of "leaving the sandbox" at the request of the server, and then it would be good.