Pages:
Author

Topic: possible security issue due to stupid users? (Read 3135 times)

member
Activity: 67
Merit: 130
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

https://bitcointools.appspot.com/?k=DEADBEEF gives exactly 1KNrMaMfiqKzRC5fzi1gqTeDC96PAqJPZy
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
February 22, 2012, 09:17:57 AM
#20
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.

sr. member
Activity: 434
Merit: 250
100%
February 22, 2012, 08:35:59 AM
#19
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



legendary
Activity: 1708
Merit: 1066
February 18, 2012, 08:55:22 AM
#18
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

legendary
Activity: 1072
Merit: 1174
February 17, 2012, 08:38:24 PM
#17
@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.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
February 17, 2012, 08:24:01 PM
#16
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).

sr. member
Activity: 266
Merit: 250
The king and the pawn go in the same box @ endgame
"I'm gonna go out on a limb here. I think your friend... is you."


Huh
member
Activity: 67
Merit: 130
"I'm gonna go out on a limb here. I think your friend... is you."
sr. member
Activity: 266
Merit: 250
The king and the pawn go in the same box @ endgame
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.
newbie
Activity: 28
Merit: 0
storing your private keys on the web is a big no no (at least for me)
legendary
Activity: 1708
Merit: 1066
@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://bitcointalksearch.org/topic/m.711171

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.
hero member
Activity: 868
Merit: 1007
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.
newbie
Activity: 28
Merit: 0
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.
legendary
Activity: 1204
Merit: 1015
Quote
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.
newbie
Activity: 28
Merit: 0
Quote
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
kjj
legendary
Activity: 1302
Merit: 1025
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.
hero member
Activity: 812
Merit: 1000
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*
legendary
Activity: 1204
Merit: 1015
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.
newbie
Activity: 28
Merit: 0
Fair enough
I thought there was an import private key feature in the workings, which will allow that.
kjj
legendary
Activity: 1302
Merit: 1025
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.
Pages:
Jump to: