possible security issue due to stupid users?

[Costia]

It looks to me from reading about ECDSA that the private key can be anything - a random number
Currently a lot of users are afraid to lose access to their wallets - so they make backups etc..
I am concerned that some users will find out the private key can be anything they want and will generate\use easy to remember keys like DEADBEEF (address:1KNrMaMfiqKzRC5fzi1gqTeDC96PAqJPZy)
Whenever I need to change the password for my bank account - there is a minimal complexity required - it won't let me use a simple password.
Can something like this be implemented for the bitcoin client? some kind of a complexity check of the private key?
rejecting the key will cause a lot of trouble, but for example the client can create a new address and transfer all the funds there if a simple private key is detected, or at least warn the user that the key is bad.

[1660974754]

1660974754

[1660974754]

1660974754

[1660974754]

1660974754

[kjj]

The stock client doesn't accept human input for private keys, it generates them at random.  To get a custom key in, you need to manipulate the wallet database.  If you are clever enough to do that, you are clever enough to accept your own losses.

[Costia]

Fair enough
I thought there was an import private key feature in the workings, which will allow that.

[Maged]

Fair enough
I thought there was an import private key feature in the workings, which will allow that.

Even that doesn't use a raw hex format. You'd first need to use a tool to covert the hex into Sipa Wallet Import Format, and if you know how to do that, you clearly know how to run a wallet tool that will let you bypass any stupidity checks.

Also, I'd love to know your algorithm for detecting stupid inputs. Even then, all you do is create a better idiot that will defeat your idiot checks.

[payb.tc]

Fair enough
I thought there was an import private key feature in the workings, which will allow that.

Even that doesn't use a raw hex format.

whaaaaaaaaa? disappointed.

*goes back to qt tutorials*

[kjj]

Also, I'd be surprised if there aren't already a half dozen people running scripts to find and sweep transactions signed by weak keys.

[Costia]

Also, I'd love to know your algorithm for detecting stupid inputs. Even then, all you do is create a better idiot that will defeat your idiot checks.

I want it to be regular idiot proof, not malicious\suicidal idiot proof
meaning that your answer for not letting input hex private keys is good enough for me

[Maged]

Also, I'd love to know your algorithm for detecting stupid inputs. Even then, all you do is create a better idiot that will defeat your idiot checks.

I want it to be regular idiot proof, not malicious\suicidal idiot proof
meaning that your answer for not letting input hex private keys is good enough for me

Although... It looks like Armory allows the import of hex keys, so there may be some concern there.

[Costia]

And someone (could be malicious)  can write a "vanity private key" script\software to allow the creation of weak WIF formatted keys
Though this seems quite unlikely to me.

[Steve]

Wallets shouldn't really allow private keys to be imported easily…instead they should sweep the coins of a private key into other addresses that the wallet contains.  Similarly, they shouldn't easily allow private keys to be extracted from the wallet, instead they should allow funds to be transferred to a newly generated private key that is not considered a part of the wallet (though the wallet might want to remember them in case it becomes necessary to later sweep those coins back into the wallet).  You could think of the new private key as a wallet itself (or maybe like an envelope with cash in it).  With import/export, the risk of multiple wallets getting the same private keys in them and thoroughly confusing your typical user is too great.

[jim618]

@Steve
I agree with you that it can be very confusing to have the same key in multiple wallets.
It can be very powerful however - you can have a wallet in, say, blockchain.info and MultiBit that have the same private keys and both get updated in lockstep with each other.

See this post:
https://bitcointalk.org/index.php?topic=43616.msg711171#msg711171

This would be very useful to monitor what was going on (and say topup a child's account).
I agree though that people would have to understand private keys in detail for it not to all go wrong.

I have the feeling people will start to "preload" a private key and then simply email it to a friend (with all the security risks that entails).  In which case you would have to do a sweep just for peace of mind.

[Costia]

storing your private keys on the web is a big no no (at least for me)

[ZodiacDragon84]

storing your private keys on the web is a big no no (at least for me)

Agreed. I think etotheipi  should see this too, as mention of Armory is involved security wise.

[Joric]

"I'm gonna go out on a limb here. I think your friend... is you."

[ZodiacDragon84]

"I'm gonna go out on a limb here. I think your friend... is you."

[etotheipi]

storing your private keys on the web is a big no no (at least for me)

Agreed. I think etotheipi  should see this too, as mention of Armory is involved security wise.

Just noticing this thread, now.  This discussion is exactly the reason I never implement "brainwallets," and why I added entropy/salt into the deterministic wallet algorithm.  I was concerned that users might start using simple, memorizable root keys, and end up sharing wallets. 

Unfortunately, there is just no way to avoid this.  All keys are 32-bytes exactly, so I can't filter based on length.  All keys will have all letters of the hex alphabet in them, so I can't filter based on any kind of special-character like used on passwords.  I could implement some kind of entropy-measurement algorithm, but it doesn't stop users from simply hashing their password as the private key (or root key, for that matter).  By design, the hash is supposed to look like pure entropy, so it's a lost cause at that point.

Sure, I can do a sanity check and catch a few of the most obvious violators.   But, I think the title of this thread says it all:  there's only so far you can go to protect stupid users.  If they're protecting a lot of money behind a simple private key... well they're likely to do other grossly-insecure things and compromise themselves, anyway (such as copying their unencrypted wallet to Dropbox because they believe no one else has access to it).

[Pieter Wuille]

@Steve
I agree with you that it can be very confusing to have the same key in multiple wallets.
It can be very powerful however - you can have a wallet in, say, blockchain.info and MultiBit that have the same private keys and both get updated in lockstep with each other.

Jim,

that feature is called "determinstic wallets" usually - it is specifically designed for ease of backup and the ability to have several clients share the same (piece of) wallet without them diverging from eachother. Using some EC math tricks, you can do very nice things, such as a "read only" version that does not allow spending.

Read more here.

[jim618]

Hi Pieter,

Thanks for the reference link.

Note that the export and then reimport of an arbitary private key from one wallet to another is not the same "word usage" as what is commonly refered to as a deterministic wallet (as I understand it).

AFAIK With a deterministic wallet there is usually some key definition function that uses a passphrase to generate the private keys for the wallet.   With an export of an arbitary key and then a reimport somewhere else there is no private key synthesis, just a straightforward key copy.

The net result - the same key in two wallets - is the same mind.

Jim

[goodlord666]

I am concerned that some users will find out the private key can be anything they want and will generate\use easy to remember keys like DEADBEEF (address:1KNrMaMfiqKzRC5fzi1gqTeDC96PAqJPZy)

How is DEADBEEF a key? I thought the Hex of a private key was much longer than that, i.e.:
9A 32 B7 50 A3 26 8C 74 79 D8 A0 F7 FE 9C 59 DF B9 09 86 9B 1B F4 83 E5 6D 11 BA E1 CC 3E 42 37

[etotheipi]

And also: why would having people being punished
for their own stupidity be a problem ? Seems to me
like a feature rather than a bug.

I absolutely love the concept of negative reinforcement for being stupid, but it's not always that simple.  They may have created their private keys months before any kind of security breach happens, and even forgotten or not realized that their private key was so simple.  Then, 6 months later, they're on the forums complaining about how their BTC were stolen, and sending all the client developers on a security breach investigation.  Their refusal, of forgetfulness, to mention that they used a simple password is irrelevant:  they will still waste a lot of people's time and generate negative exposure for Bitcoin (about how it's insecure, etc).

Since I'm a client developer, liability issues enter my mind quite frequently (not legally liable, but guilty-conscience liability).  Even if it wasn't my fault, I don't want to deal with figuring out what happened, especially since users don't like to admit that they did something else most other people would criticize them for (like 4-char passphrases).   At least if you have to go through a lot of effort to make that mistake, then you should already be aware of the consequences and how likely they would be.