Did the programmers of the official bitcoin client release the trojan?

[bitcoins5411]

How is it that these geniuses who invented the world's first "cryptocurrency", which is super advanced, etc, forgot to put a simple password in the client and protect the wallet.dat file which actually stores your bitcoins.

Seems almost like they were working in conjunction with the writers of the trojan that steals the wallet.dat file.

Why didn't they encrypt this file? They're not idiots, so it must have been a conscious decision on the part of the programmers to allow people to steal bitcoins more easily.

What do you all think?

[1713581064]

1713581064

[1713581064]

1713581064

[1713581064]

1713581064

[1713581064]

1713581064

[Bert]

Suppose that you keel over dead tomorrow with 20000 BTC in a heavily heavily encrypted wallet.dat. Apart from the sadness of your death, the event does nothing but increase the wealth of others (less coins in circulation, means existing coins will increase in value). It would have a very detrimental effect on your family and/or next of kin. That is the only reason I can conceive of why encrypted wallets.dat were not there day one. I would say that it was an original design decision.

[evoorhees]

Yes, what better way to destroy a potentially hugely profitable endeavor for them by instead opting for a few quick bucks.  

The devs have discussed why the wallet is not encrypted. They have some reasons for doing it, which are debated back and forth. I believe they've now changed their mind and the next version of the client will include this safety feature.

Remember that the code is open-source, so them being devs provides little to no advantage for creating a trojan. You or I could just as easily review the code and find exploits.

[Mistafreeze]

For some reason, I just can't see them doing that. Call me strange, I suppose.

[bitcoins5411]

Suppose that you keel over dead tomorrow with 20000 BTC in a heavily heavily encrypted wallet.dat. Apart from the sadness of your death, the event does nothing but increase the wealth of others (less coins in circulation, means existing coins will increase in value). It would have a very detrimental effect on your family and/or next of kin. That is the only reason I can conceive of why encrypted wallets.dat were not there day one. I would say that it was an original design decision.

I can't imagine that this was the reason. Anyone could leave their BTC password to their heirs in their will. Anyone who has 20,000 BTC in their wallet will take precautions.

[Maged]

There are two main reasons why this was an extremely low priority feature to add:

1) It is extremely dangerous. One wrong character in the code could permanently corrupt everybody's wallet. A larger development team and more testing was needed to stop this. Additionally, it's easy to lose the password. That's something that the community didn't need to worry about back when wallet stealing wasn't an issue.

2) It doesn't protect against much. All but the simplest of trojans will still steal all of your funds. It'll just take slightly more than the two lines of code that's currently needed.

[JoelKatz]

How is it that these geniuses who invented the world's first "cryptocurrency", which is super advanced, etc, forgot to put a simple password in the client and protect the wallet.dat file which actually stores your bitcoins.

There was no known solution. This issues are complex, but there is no good way to do it.

Seems almost like they were working in conjunction with the writers of the trojan that steals the wallet.dat file.

Why didn't they encrypt this file? They're not idiots, so it must have been a conscious decision on the part of the programmers to allow people to steal bitcoins more easily.

What do you all think?

It was a conscious decision, but it had nothing to do with making it easy to steal bitcoins. It had to do with there being no known way to do it. Consider:

1) If people make the password complex, more people will lose their funds by forgetting the password than would have their coins stolen by trojan. Every argument that people with lots of money will pick good passwords and not lose them also argues that the people with lots of money will secure their computers against trojans.

2) If you require the password to be entered for every operation, the password will easily be captured by a trojan. So you have to allow 'passive' operations (such as checking your balance) to work without a password.

3) Therefore a trojan author can know which wallets contain the most bitcoins through these passive operations. He can transfer the encrypted wallets, and use compromised machines to brute force the password.

This means any such feature will either have to force people to use complex passwords they are very likely to forget or allow simple passwords that will create a false sense of security and be easily brute forced by botnets.

Many opportunities were presented for people to suggest proposals for how to secure the wallet better. I've yet to see a good one that only involves encryption software in the client.

[Anonymous]

Cant someone write a keepass plugin that lets you generate a secure password using the keepass client ?

[dogisland]

Password managers such as Keepass are open to attack by key loggers.

To really secure a wallet you need to assume your machine can be compromised by a Trojan that logs keys, can read memory, scan the disk and record screenshots.

You can be sure someone will try to infect your machine with such a Trojan.

[JoelKatz]

Cant someone write a keepass plugin that lets you generate a secure password using the keepass client ?

It doesn't change the problem. Either you need the password often, in which case a keylogger can grab it, or you need it rarely, in which case the botnet owner knows which password files to have his botnet brute force.

And this also suffers from the "false sense of security" problem. You would be amazed at what passwords can be brute forced if an attacker knows which passwords are worth forcing.

Edit: There was a section here pointing out some reservations I had about Keepass. The00Dustin sent me a link to a more detailed page about Keepass security details and they address all my issues. I now have no reservation about the use of Keepass.

That doesn't mean it's not a good idea, just that it doesn't really solve the problem.

[The00Dustin]

I also have some specific issues with keepass. If it is designed to properly secure the password, the design pages don't say so, and in fact suggest the opposite. I don't see anything about iteration or salting -- the documentation suggests that straight SHA-256 is used. The only mention of this type of attack claims it's mitigated by "transforming the master key very often". There might be some way that makes sense, but I can't figure it out.

Forgive me for going slightly off-topic (I agree that a plugin wouldn't help, ultimately, if your wallet is connected to an active copy of bitcoin, it is vulnerable one way or another and all of these ideas only make people feel more secure <sarcasm section=!\ yayyy!>[like the Patriot Act! yayyy!]</sarcasm>).  Anyway, JoelKatz, have you seen this page?  http://keepass.info/help/base/security.html  If not, does it affect your opinion on KeePass?  For the record, I want to know because I use it and not because I'm involved with the project.

[Bitsky]

1) If people make the password complex, more people will lose their funds by forgetting the password than would have their coins stolen by trojan.

So are you basically saying that it's better to leave the door to your house open for a potential thief just because you might lose the key?

2) If you require the password to be entered for every operation, the password will easily be captured by a trojan. So you have to allow 'passive' operations (such as checking your balance) to work without a password.

You can also think about non-text passwords. Like an image of 25 colored fields where you have to click a color code.

3) Therefore a trojan author can know which wallets contain the most bitcoins through these passive operations. He can transfer the encrypted wallets, and use compromised machines to brute force the password.

Bruteforcing salted passwords? Seriously. The investment in computing power required to do that within your lifetime would be larger than the possible gains from breaking a wallet.

You could enforce a minimum password strength. Many websites do this already to avoid "password" or "12345" from being used. I guess making it obvious to a user that his money should be protected the same way isn't that hard. I'm not saying that wallet encryption solves every imaginable problem; but it's a very big step towards security. Besides, if it wouldn't matter, why is there a how-to about using Truecrypt?

[timmey]

wallet encryption is on the developers roadmap, note that the client is still very beta. Of course it won't prevent from key loggers and trojans. Every dumbass can copy a file but not every dumbass can write or use a keylogger.

[davout]

Why didn't they encrypt this file? They're not idiots, so it must have been a conscious decision on the part of the programmers to allow people to steal bitcoins more easily.

Because programmers are human beings and days are 24 hours long.

[The00Dustin]

Viperjbm, I realize you are only brainstorming, but food for thought:

1) The complexity of accessing the wallet by answering 4 questions would be monstrous

2) While the questions could be your own and no one else could know the answers (in theory), that is what a password is supposed to be, an answer that no one else knows.  <rant>IMO, security questions on bank websites are a government-enforced security flaw.  One can drop random passwords in them to circumvent that flaw, but then he can't access his bank stuff without a list of passwords</rant>.

3) Regardless of whether all of the questions answers are cities, and regardless of whether or not they are asked in a random order, a key log could show that the same four things (cities, in this case) were typed over and over again even though the order was different.  At this point, thos four words (cities) are no more secure than four given letters.  IOW, in terms of preventing access to your wallet, that would barely be any more effective than me telling you that my password is four characters long and the characters are A B C and D.  Not going to take long to break that, is it?

In summary, and I mean no offense, all your thoughts so far simply lead to unneeded complexity and steps without any additional benefit.  Encrypting the wallet.dat file makes sense in that it prevents copies of it from being attacked by random people, but beyond that, common sense needs to prevail.  For instance, if there is a keylogger on your system, is your wallet.dat file seriously more precious than your bank account that you log onto with the same system?

[Vladimir]

Oba... how come developers of "grep" (or use almost any other unix program) released a trojan by not including functionality to enable encrypting of the output.

OP, get a life or CompSci education.

[JoelKatz]

Anyway, JoelKatz, have you seen this page?  http://keepass.info/help/base/security.html  If not, does it affect your opinion on KeePass?  For the record, I want to know because I use it and not because I'm involved with the project.

I saw a similar page, but it didn't have as much detail as that one. This one does make clear that the hashes are salted and iterations are used. That's good because it means someone trying to brute force passwords can't use a rainbow table and can't gain efficiency (at least not very much) by trying to brute force many different people at the same time. (I'll edit my earlier post.)

Just make sure to use a password that's not easily brute forceable. And, of course, you still have to worry about a trojan catching your keystrokes as you enter it.

[JoelKatz]

1) If people make the password complex, more people will lose their funds by forgetting the password than would have their coins stolen by trojan.

So are you basically saying that it's better to leave the door to your house open for a potential thief just because you might lose the key?

If losing the key meant you could never ever get into your house again, hell yeah!

2) If you require the password to be entered for every operation, the password will easily be captured by a trojan. So you have to allow 'passive' operations (such as checking your balance) to work without a password.

You can also think about non-text passwords. Like an image of 25 colored fields where you have to click a color code.

If you make a complete proposal, I'll tell you what's wrong with it. The hard part with things like that is they're much harder to remember or write down.

3) Therefore a trojan author can know which wallets contain the most bitcoins through these passive operations. He can transfer the encrypted wallets, and use compromised machines to brute force the password.

Bruteforcing salted passwords? Seriously. The investment in computing power required to do that within your lifetime would be larger than the possible gains from breaking a wallet.

It depends on how long the passwords are. Long passwords bring back the lost password problem.

You could enforce a minimum password strength. Many websites do this already to avoid "password" or "12345" from being used. I guess making it obvious to a user that his money should be protected the same way isn't that hard. I'm not saying that wallet encryption solves every imaginable problem; but it's a very big step towards security. Besides, if it wouldn't matter, why is there a how-to about using Truecrypt?

Again, it's hard to comment on fragmented ideas. Nobody was able to put a good proposal together. Every design suggestion had upsides and downsides and on balance, none were much better than nothing at all. None really justified the risk of creating a false sense of security.