|
Title: Wallet encryption Post by: jhansen858 on June 17, 2011, 07:29:42 PM http://it.slashdot.org/story/11/06/17/141228/Trojan-Goes-After-Bitcoins
This is really bad. Title: Re: Wallet encryption Post by: stevang on June 17, 2011, 07:56:49 PM Its time to focus on protection of the user wallets now!
I thought bitcoin is about encryption!? So how hard can it be to offer an encryption for the running client and for the client files? I would love to be able to add a second level of verification with my yubikey also (optional). The more ppl loose their wallets to hackers and trojans the less people will stick with the bitcoin currency. Are there not enough topics in the press yet to do something about it? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? Title: Re: Wallet encryption Post by: bbit on June 17, 2011, 09:29:12 PM At some point people are going to have to trust someone to help protect stuff - might be worth checking this out ...
http://www.bitprotection.info at least you can get coverage against your wallet if anything happens... just a thought... Title: Re: Wallet encryption Post by: DukeOfEarl on June 17, 2011, 09:52:51 PM Just wait until the first buffer overflow exploit in the client. Then things will really get interesting.
Title: Re: Wallet encryption Post by: enmaku on June 17, 2011, 09:56:58 PM https://github.com/bitcoin/bitcoin/pull/232
Already in the works. Please google / search forums before posting yet another "OMGZ WE R INSECURR!!1" thread. Title: Re: Wallet encryption Post by: bitlotto on June 17, 2011, 10:00:31 PM Just wait until the first buffer overflow exploit in the client. Then things will really get interesting. Interested. Explain. Title: Re: Wallet encryption Post by: enmaku on June 17, 2011, 10:03:49 PM Just wait until the first buffer overflow exploit in the client. Then things will really get interesting. Interested. Explain. By giving an application carefully malformed input which is larger than the field it was expecting you can sometimes cause your malformed input to overwrite part of the copy of the application that is sitting in active memory, effectively rewriting some of its code to your own ends. This means that one could, for example, rewrite the code that sends BTC substituting whatever variable holds the recipient's address with a static wallet address, so it would look like you sent person A coins but actually sent them to attacker B. Buffer overflows are very scary, but they're also pretty hard to pull off in a meaningful way. I don't expect to see many such exploits in the wild any time soon. Title: Re: Wallet encryption Post by: bitlotto on June 17, 2011, 10:11:10 PM Just wait until the first buffer overflow exploit in the client. Then things will really get interesting. Interested. Explain. By giving an application carefully malformed input which is larger than the field it was expecting you can sometimes cause your malformed input to overwrite part of the copy of the application that is sitting in active memory, effectively rewriting some of its code to your own ends. This means that one could, for example, rewrite the code that sends BTC substituting whatever variable holds the recipient's address with a static wallet address, so it would look like you sent person A coins but actually sent them to attacker B. Buffer overflows are very scary, but they're also pretty hard to pull off in a meaningful way. I don't expect to see many such exploits in the wild any time soon. Title: Re: Wallet encryption Post by: passerby on June 17, 2011, 11:52:33 PM I think the utility of wallet encryption in absence of a smartcard is very limited, if at all exists.
Title: Re: Wallet encryption Post by: enmaku on June 18, 2011, 01:07:45 AM Just wait until the first buffer overflow exploit in the client. Then things will really get interesting. Interested. Explain. By giving an application carefully malformed input which is larger than the field it was expecting you can sometimes cause your malformed input to overwrite part of the copy of the application that is sitting in active memory, effectively rewriting some of its code to your own ends. This means that one could, for example, rewrite the code that sends BTC substituting whatever variable holds the recipient's address with a static wallet address, so it would look like you sent person A coins but actually sent them to attacker B. Buffer overflows are very scary, but they're also pretty hard to pull off in a meaningful way. I don't expect to see many such exploits in the wild any time soon. I think that's the idea, scripts like this one (http://"http://forum.bitcoin.org/index.php?topic=17965.msg228234;topicseen#msg228234") are popping up more and more often. People like the ease of use that a one-click payment option offers, but it can also lead to deliberate attacks on the client itself. It would also be possible for programs on the same local machine to attempt to overflow the bitcoin client through input methods not normally used by humans (like RPC) or even just directly manipulate its memory space. Title: Re: Wallet encryption Post by: Martin P. Hellwig on June 18, 2011, 02:05:40 AM I think the utility of wallet encryption in absence of a smartcard is very limited, if at all exists. As the wallet is only needed when sending an transaction it is perfectly alright to encrypt it and prompt the user for a password to when needed.Title: Re: Wallet encryption Post by: joan on June 18, 2011, 09:49:42 AM Ok, but for most users the only place that would occur would be the address input or amount right? (I know just a tiny bit about buffer overflows) The address would have to be pretty malformed to work right? I guess if you're opening bitcoin with a script it would be easier... Another input is the data sent from node to node. A malicious node could craft a transaction that the victim node will process to check for validity. The vulnerability could be in the transaction processing routine.Title: Re: Wallet encryption Post by: mp420 on June 18, 2011, 12:28:02 PM Sorry for the thread hijack, but I did not want to make a new one just to outline my scheme for storing bitcoins securely.
How to make a secure savings wallet - a paranoid approach 1) Create a fresh, minimal install of Linux of the flavour of your choice. Preferably not on your primary computer. A "live" OS could suffice, too. 2) Install GnuPG and Bitcoin. 3) Start Bitcoin and let it download the blockchain. Create as many empty accounts as you need. 4) Take the computer offline. 5) Create a new GPG identity and a keypair. No need to use a passphrase for the private key. 6) Back up the wallet and encrypt it with the public key. 7) Transfer the encrypted wallet out of the system (on a USB memory, a CD or some other approach) and store it in several places both online and offline. Do the same to the list of accounts. 8) Write out, or type out on a mechanical typewriter, print out on a line printer or in some other analog or near-analog way transfer the private key out of the system and store it EXTREMELY securely. Preferably in two places, with a cover letter that explains what the key is good for and how to use it. 9) Shut down and erase the temporary Linux system. If paranoid, physically destroy the disk. 10) Transfer the funds to the account(s) and wait for the transaction(s) to get confirmed. 11) Enjoy the illusion of safety and start worrying over the VALUE of your savings. Any thoughts? Title: Re: Wallet encryption Post by: Jaagu on June 19, 2011, 02:04:17 AM Sorry for the thread hijack, but I did not want to make a new one just to outline my scheme for storing bitcoins securely. How to make a secure savings wallet - a paranoid approach 1) Create a fresh, minimal install of Linux of the flavour of your choice. Preferably not on your primary computer. A "live" OS could suffice, too. 2) Install GnuPG and Bitcoin. 3) Start Bitcoin and let it download the blockchain. Create as many empty accounts as you need. 4) Take the computer offline. 5) Create a new GPG identity and a keypair. No need to use a passphrase for the private key. 6) Back up the wallet and encrypt it with the public key. 7) Transfer the encrypted wallet out of the system (on a USB memory, a CD or some other approach) and store it in several places both online and offline. Do the same to the list of accounts. 8) Write out, or type out on a mechanical typewriter, print out on a line printer or in some other analog or near-analog way transfer the private key out of the system and store it EXTREMELY securely. Preferably in two places, with a cover letter that explains what the key is good for and how to use it. 9) Shut down and erase the temporary Linux system. If paranoid, physically destroy the disk. 10) Transfer the funds to the account(s) and wait for the transaction(s) to get confirmed. 11) Enjoy the illusion of safety and start worrying over the VALUE of your savings. Any thoughts? I've always been curious about what happens when you are going to use your precious wallet again. You have to download the entire blockchain -- it might take an hour or two -- during this time your wallet is exposed to all kind external threats, isn't it? Sure, you could speed up the process by downloading most of the chain (e. g. from http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/ (http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/) and using rescan switch, but it does not eliminate threats. Besides, you might need to revive your wallet after soooo many years and by this time there are absolutely new clients with no place for 'wallet.dat' (there might be new built-in encryption etc.). What will you do then? Title: Re: Wallet encryption Post by: Garrett Burgwardt on June 19, 2011, 02:42:25 AM Just wait until the first buffer overflow exploit in the client. Then things will really get interesting. IIRC, there already was one, where someone generated a crazy amount of coins for themselves. There was a panicked update spree and the 'good' blockchain overtook the bad one once everyone had updated. Title: Re: Wallet encryption Post by: foo on June 19, 2011, 06:35:53 AM Just wait until the first buffer overflow exploit in the client. Then things will really get interesting. IIRC, there already was one, where someone generated a crazy amount of coins for themselves. There was a panicked update spree and the 'good' blockchain overtook the bad one once everyone had updated. |