So, bitcoin client still use unencrypted wallet.dat

[mouse]

You are more likely to lose your BitCoins through forgetting your password than you are to have them stolen by a trojan.

Maybe thats true, in your case. But if bitcoins are 'successful' they will end up in the hands of a lot of users where this is not going to be true. I tihnk on average your statement will be false (and this prediction is tied to the adoption level of bitcoin in general).

BTW, I run keypass, with a monster master key. So I probably wouldnt remember my own bitcoin password. It would be stupidly complex. I would prefer that personally to a wallet.dat file in the open.

[JoelKatz]

You are more likely to lose your BitCoins through forgetting your password than you are to have them stolen by a trojan.

Maybe thats true, in your case. But if bitcoins are 'successful' they will end up in the hands of a lot of users where this is not going to be true. I tihnk on average your statement will be false (and this prediction is tied to the adoption level of bitcoin in general).

Maybe if BitCoins are successful it will be because a solution comes around that doesn't have either of these issues.

BTW, I run keypass, with a monster master key. So I probably wouldnt remember my own bitcoin password. It would be stupidly complex. I would prefer that personally to a wallet.dat file in the open.

Someday I should tell you about the day my daughter fall and hit her head, and the many things she did that day that she has no recollection of. If you change your keypass password, keep a backup that can use the old password for at least a few days.

"If I'm in the hospital why don't I have one of those things on my wrist?" "Look at your wrist." "Oh!"
"Are you not supposed to tell me how I got here so they can see if I remember?" "Actually, I have several times."

I don't want to let the perfect be the enemy of the good. But I've yet to see a solution that I think is better than what we have now, for the average person.

[MikesMechanix]

You haven't proposed a complete scheme, so you're comparing the advantages and disadvantages of something that exists to something that isn't even specified.

The scheme is so standard from pgp, gpg, bcrypt, truecrypt etc it should be obvious.

For example, under 'encrypted', you assume the thief cannot brute force your password.

The password (or in this case, passphrase) is as secure as the user chooses. ANY is better than none, because even a weak one needs some effort and custom tools to crack.

That will mean that your password will have to be the kinds of things a human being can't memorize reliably. Yet you don't consider the risks of forgotten passwords.

Then, write it down.

Anyone who has been around computers for at least ten years has had the experience of using a system you used to use regularly one time after a year or more of not using it and having no idea what your password is. This is the #1 way people will lose their BitCoins.

So you put lots of money in a bitcoin wallet and then don't use it?

People tend to be careful when it comes to money. If they aren't, they only have themselves to blame. I can't see how other peoples' idiocy is an excuse to hinder my security.

Remember, if your password is only needed to transfer coins, the thief will know exactly how valuable cracking your wallet is. And he'll probably have access to a vast network of compromised machines to use to brute force your password.

The first sentence makes no sense whatsoever. And I don't care how vast his network is, he is not going to crack my password in the remaining lifetime of the universe.

[bcearl]

IMO, that's just inviting disaster. The client should only be running on machines that are inherently secure. Doing this will encourage people to run the client on insecure machines, which will compromise their wallets even if they are encrypted. Strong passwords will be forgotten, leading to lost BitCoins. Weak passwords will be brute forced, accomplishing nothing.

Yeah, but a forgotten password is everybody's own fault, while the average BTC user can't be expected to only keep his wallet on his walled-off linux machine with only carrier pigeon connectivity.
Of course, most known cases of theft have been linked to gross negligence, but that's just how people work - you don't worry until it's too late.

I, for one, would welcome wallet encryption, even if it's not 100% secure and perfect. I mean, what is 100% secure?

But a forgotten password results in lost coins for the whole network, while stolen coins are still circulating.

[bcearl]

You haven't proposed a complete scheme, so you're comparing the advantages and disadvantages of something that exists to something that isn't even specified.

The scheme is so standard from pgp, gpg, bcrypt, truecrypt etc it should be obvious.

That's tools, not schemes.

[MikesMechanix]

But a forgotten password results in lost coins for the whole network, while stolen coins are still circulating.

Why do you say that as if it were a bad thing.

[bcearl]

But a forgotten password results in lost coins for the whole network, while stolen coins are still circulating.

Why do you say that as if it were a bad thing.

It isnt a bad thing that it may happen sometimes, but it would be a bad thing if it was the default.

[MikesMechanix]

You haven't proposed a complete scheme, so you're comparing the advantages and disadvantages of something that exists to something that isn't even specified.

The scheme which should be used is the same kind of passphrase encryption as used in tools such as pgp, gpg, bcrypt, truecrypt etc, that it should be obvious.

That's tools, not schemes.

Easier to understand now?

[bcearl]

You haven't proposed a complete scheme, so you're comparing the advantages and disadvantages of something that exists to something that isn't even specified.

The scheme which should be used is the same kind of passphrase encryption as used in tools such as pgp, gpg, bcrypt, truecrypt etc, that it should be obvious.

That's tools, not schemes.

Easier to understand now?

That doesn't protect you against malware at all.

[MikesMechanix]

That doesn't protect you against malware at all.

Please see the 9th post in this thread.

FWIW they are already implementing this. And I'm done arguing.

[bcearl]

encrypted:
1)- thief steals your hard drive : thief more or less s.o.o.l
2)- thief hacks your PC : thief needs to grab wallet.dat, install a keylogger and wait patiently until user makes a payment, which could be today, next week, or never
3)- get a trojan : needs to target Bitcoin specifically and wait until a payment is made as above
Average time needed to steal all user's coins : days to weeks

1) Only true if you have full disk encryption. Otherwise, your operating system may have placed the unencrypted private data anywhere (temporary files, swap space ...)

2) Nonsense. Malware can just read the RAM of your Bitcoin client.

3) See second.

[MikesMechanix]

1) Only true if you have full disk encryption. Otherwise, your operating system may have placed the unencrypted private data anywhere (temporary files, swap space ...)

2) Nonsense. Malware can just read the RAM of your Bitcoin client.

3) See second.

1) Only if the client implementation allows this to be done. Memory pages can be locked and prevented from swapping to disk.

2) The private keys need only be unencrypted when payments are made or new addresses are created. And while possible in theory, for multiple reasons, reading the RAM of the Bitcoin client is probably the most difficult way to get the keys. A simple keylogger or even replacing the bitcoin client with your own (it's open source, after all) would work just as well. The thing is, these are very specific attacks and much more involved than just making a copy of wallet.dat. And the hacker still needs to wait until the passphrase is actually typed, giving the user time to notice something is wrong.

3) See second

And now I'm really done repeating myself.

[JoelKatz]

You haven't proposed a complete scheme, so you're comparing the advantages and disadvantages of something that exists to something that isn't even specified.

The scheme which should be used is the same kind of passphrase encryption as used in tools such as pgp, gpg, bcrypt, truecrypt etc, that it should be obvious.

That's tools, not schemes.

Easier to understand now?

I don't think you understand the issue. By a "complete scheme", I mean answers to questions like:

1) Is password complexity enforced? If so, what are the complexity rules?

2) Is any other way provided to get into the private keys other than the password?

3) What is the password needed for? Only to send money? Or even to see what accounts exist on the system?

And so on.

Without a complete scheme, there is no way to evaluate the advantages and disadvantages. As I've said, I can't think of a scheme whose advantages outweigh the disadvantages.

[bcearl]

1) Only true if you have full disk encryption. Otherwise, your operating system may have placed the unencrypted private data anywhere (temporary files, swap space ...)

2) Nonsense. Malware can just read the RAM of your Bitcoin client.

3) See second.

2) The private keys need only be unencrypted when payments are made or new addresses are created. And while possible in theory, for multiple reasons, reading the RAM of the Bitcoin client is probably the most difficult way to get the keys. A simple keylogger or even replacing the bitcoin client with your own (it's open source, after all) would work just as well. The thing is, these are very specific attacks and much more involved than just making a copy of wallet.dat. And the hacker still needs to wait until the passphrase is actually typed, giving the user time to notice something is wrong.

That's a trivial task. Every other video game kiddie knows how to cheat by manipulating RAM data. Reading only is even easier.

[MikesMechanix]

I don't think you understand the issue.

I don't think you understand what within wallet.dat needs to be protected and how passphrase based encryption works. If you did, you'd know the answers to your questions 2 and 3 are obvious.

Without a complete scheme, there is no way to evaluate the advantages and disadvantages. As I've said, I can't think of a scheme whose advantages outweigh the disadvantages.

Well, I'll leave you here demanding your scheme.

[bcearl]

You haven't proposed a complete scheme, so you're comparing the advantages and disadvantages of something that exists to something that isn't even specified.

The scheme which should be used is the same kind of passphrase encryption as used in tools such as pgp, gpg, bcrypt, truecrypt etc, that it should be obvious.

That's tools, not schemes.

Easier to understand now?

I don't think you understand the issue. By a "complete scheme", I mean answers to questions like:

1) Is password complexity enforced? If so, what are the complexity rules?

2) Is any other way provided to get into the private keys other than the password?

3) What is the password needed for? Only to send money? Or even to see what accounts exist on the system?

And so on.

Without a complete scheme, there is no way to evaluate the advantages and disadvantages. As I've said, I can't think of a scheme whose advantages outweigh the disadvantages.

You are making a bit of a strawman argument here.

Mike did not propose such a stupid idea to just protect the current wallet.dat file by password. He distinguished between the private and public keys, and he proposed that those private keys are protected only. And those private keys are only decrypted when an actual transaction is made.

It does not protect against everything - as I argued - but it isn't as stupid as you quote it either.

[JoelKatz]

Mike did not propose such a stupid idea to just protect the current wallet.dat file by password. He distinguished between the private and public keys, and he proposed that those private keys are protected only. And those private keys are only decrypted when an actual transaction is made.

It does not protect against everything - as I argued - but it isn't as stupid as you quote it either.

I presumed that this was what he intended, and I pointed out the problem with that scheme. A human will have to choose a password simple enough that they can remember it for many years but complex enough that an attacker cannot brute force it even if the attacker specifically knows which wallets have the largest BitCoin balances and the attacker has a botnet to use to brute force passwords on.

I wasn't kidding about my example. I really did have a password I used at least 20 times a week for more than six years that I didn't use for 8 months and forgot. It was a short/simple password too.

How bad this is depends to some extent on password complexity rules. If you force a very complex password, you ease the brute forcing issue. If you don't, you ease the password forgetting rule. Maybe someone knows how to make this work. I don't.

Users do not really understand the concept of a password that absolutely cannot be bypassed. A regular question on many forums is some variant of "I forgot the password to my X, how do I recover it?" where X is a WinRAR archive or a disk encryption scheme. They are stunned that the answer is "you're 100% screwed".

But I cannot do a fair job of criticizing a scheme without knowing what that scheme is. Nor is it fair for him to argue we should add encryption because he imagines a scheme that is not actually capable of being realized.

[BubbleBoy]

The real solution is multi-device confirmation of big bitcoin transactions. You'd send coins starting on your computer, but the transaction wouldn't be valid until it was signed by another device, which would somehow contact you (NOT through your computer) and ask you for your OK before sending it along

It seems easier to implement an embedded wallet that plugs into USB and stores the private key. The device has a small LCD screen and an "Approve" button. When you spend something in your bitcoin client the transaction is sent to the USB device for signature. The USB device checks the amount to be spent, and prints to the user the net amount to be spent: Pay 20B ?
Upon pressing Approve the transaction is signed with the private key and sent to the client for broadcast into the network. There's no way rouge software to fake the displayed amount or the Approve button.

Such a device would cost 10-20$ in large quantities and would be practically impossible to hack.
http://www.mini-box.com/picoLCD-20x2-OEM

[Jazkal]

http://en.wikipedia.org/wiki/Two-factor_authentication

Someone give me a client that I can use two-factor authentication with. Until then, all other methods are insecure to some extent or other.

[JoelKatz]

http://en.wikipedia.org/wiki/Two-factor_authentication

Someone give me a client that I can use two-factor authentication with. Until then, all other methods are insecure to some extent or other.

Two-factor authentication exacerbates the problem. Now, instead of one thing that can go wrong causing you to lose your bitcoins (loss of the wallet), there are three things -- loss of the wallet, loss of the password, and loss of the second factor.