Author

Topic: Client wallet handling (Read 1529 times)

sr. member
Activity: 294
Merit: 252
January 10, 2011, 01:05:18 PM
#8
If you encrypt only part of your wallet and don't open that section very often, then you may discover and remove the malware before it has a chance to steal everything. Especially since the malware will probably steal the unencrypted portion.
That's one of the reasons I would like to allow multiple wallets, so that you could have your "savings" wallet that you rarely have to open, which would make it more secure.

I've actually got my wallet manager app working now with "dummy" wallets, which it allows Bitcoin to create and then deletes afterward. This is to allow Bitcoin to continue running and contribute to the network without exposing your decrypted wallet for that period of time.
administrator
Activity: 5222
Merit: 13032
January 10, 2011, 05:51:45 AM
#7
If you encrypt only part of your wallet and don't open that section very often, then you may discover and remove the malware before it has a chance to steal everything. Especially since the malware will probably steal the unencrypted portion.
legendary
Activity: 1526
Merit: 1134
January 10, 2011, 05:45:52 AM
#6
Anyone with access to your computer can just install a program that steals your wallet anyway. They wouldn't have to write it themselves. It only takes one person to write a point-and-click wallet stealer app and you're done. It'd just sit in the background and wait until you type in your password, then extract and send the keys to whomever ran it.

I hear the argument about raising the bar. I've used similar arguments many times myself. Bar raising can work and be useful in cases where there are many attackers who aren't communicating, and it doesn't really matter if you lose (as long as you don't lose most of the time). Spam filtering, credit card fraud and things like that are a good example.

I don't think it applies in this case. BitCoin and a program trying to steal your wallet compete on a level playing field. You can't raise the bar. If you get a virus on your computer designed to steal BitCoins you WILL lose your wallet and there's nothing you can do about it, no matter what kind of password protection or encryption you implement. It really is that trivial.



legendary
Activity: 1106
Merit: 1004
January 10, 2011, 03:20:48 AM
#5
Why? None of that will stop a virus that is written to steal your coins.

Security doesn't limit itself to protection against viruses.

This is a good point.

Ok, viruses can steal bitcoins even if the wallet is encrypted. But an unencrypted wallet is much more vulnerable than that. Any asshole that happens to have access to your computer may steal them from you. This may vary from an angry-ex-(girl|boy)friend to a computer technician who was there just to fix something...

Anyway, currently only geeks use the client, so this is not a big issue. But if we want to go mainstream, we need more security/safety features. The simple fact that the client doesn't ask confirmation before sending a transfer for example is quite dangerous... a typo and you can get screwed!
sr. member
Activity: 294
Merit: 252
January 09, 2011, 06:44:08 PM
#4
Why? None of that will stop a virus that is written to steal your coins.

I think we have to accept that there's no way to use BitCoin securely from a malware infected computer at the moment and there probably won't ever be. If you want to use BitCoin from a possibly compromised machine you need to do it via a 2-factor protected mybitcoin style site in which the wallet is held remotely and transactions are signed using some kind of electronic signing calculator (see CAP).

Right now, even if the Bitcoin client is not running, your wallet is stored unencrypted. There's no reason to make it that easy to steal your wallet. The changes I proposed would allow the client to handle multiple wallets in a manner that is more secure than the current handling of a single wallet. For instance, I've been working on a wallet manager that stores the wallet(s) encrypted, and only decrypts it to launch the Bitcoin client. The problem with this is that you cannot run as a node while also keeping your wallets securely stored. (Aside... I just realized a potential workaround - let the client create a new wallet instead of using one of the user's.)

There's no way to do anything securely. Security is not a binary value. The point is enhancing the default security level that the Bitcoin program provides.
Right on.
sr. member
Activity: 288
Merit: 263
Firstbits.com/1davux
January 09, 2011, 06:16:46 PM
#3
Why? None of that will stop a virus that is written to steal your coins.

Security doesn't limit itself to protection against viruses.

I think we have to accept that there's no way to use BitCoin securely from a malware infected computer at the moment and there probably won't ever be.

There's no way to do anything securely. Security is not a binary value. The point is enhancing the default security level that the Bitcoin program provides.
legendary
Activity: 1526
Merit: 1134
January 09, 2011, 06:03:29 PM
#2
Why? None of that will stop a virus that is written to steal your coins.

I think we have to accept that there's no way to use BitCoin securely from a malware infected computer at the moment and there probably won't ever be. If you want to use BitCoin from a possibly compromised machine you need to do it via a 2-factor protected mybitcoin style site in which the wallet is held remotely and transactions are signed using some kind of electronic signing calculator (see CAP).
sr. member
Activity: 294
Merit: 252
January 09, 2011, 08:35:43 AM
#1
Hey guys, I had some fairly simple (imho) ideas for ways to handle wallets more securely in the future. Let me know what you think. Has this been discussed already?

Users should be able to manage multiple wallets.
The client should not open a default wallet when starting, just act as a node.
Wallets should be encrypted.
Users should be prompted for the password when opening a wallet.
When new addresses are generated, an encrypted backed should be copied to user defined locations.
Jump to: