Why not make Bitcoin more Secure with a PIN and TAN System?

[X68N]

I read the Disscussion here,
and i must say that the wallet design is a security Joke,
dont blame the "windows cunts" for this, like i read here for that fom a Linux-fanatic
(i also was young so i could understand it, but i am older now ;-).

Now it is secure like a Creditcard where the "security code" is on the backside ;-).
A thiev could just copy the wallet - and that is not a big deal with a trojan, and easyier to steal.

Why not use/implement a system which could secure the money inside the wallet
like a TAN & PIN Combo? (Transactioncode & Personal Id Number/Password)
(not only encryption alone, because the TANs make the improvement )

1.TANs:
- The idea is that the user gets instead of 100 adresses only 10, but he gets
  100 TANcodes which are synced with the Bitcoinnetwork (Similar like DHT on Bittorent,Distributet Hash Table)
  and work for all these 10 Adresses so he could print the Tans out and delete + shredder the TANfile (or better: it could also just diplayed+printed once
  or saved to an USB without disc acces and printed later)
- Maybe this also could be done over a second communication Channel if needed, like PGP/GPG email.
  (downloaded with another PC so a trojan could not know for which adresses  this TAN list work)
- These TAN codes should be used with mouse only (an virtual keyboard should displayed to click the Numbers)
  The numbers could be Decimal or hexcode (0-9 & A-F) which is also practical.
- The order which the numbers display on this virtual keyboard should be randomly
  switch for every new transaction, and should not be possible for a trojan to read out of the RAM.
  (The client only sends mouse positions, no numbers)

2.PIN,Wallet Encyrption and possible splitting:
- The Wallet should be encrypted and passwordproteced
- It should be possible to import and export different wallets (every wallet with own password offcourse)
So the user could manage better the risk and Money.
The solution is for example, that BC-Client finds and accepts all files in the programm directory with the name wallet_*.dat (*=a unique name)

So the Advantage is not only the security,
with this system it is possible to run a client 24h without fear, to support the network.

[X68N]

mmmmh, no answers
it is too secure or to difficult? ;-)

come on people something should be done like this, i f i was a programmer i would do it my self.
But i am not, so i can only support Bitcoin by running the client, do a little mining
and Share my Ideas of  improvements for Bitcoin.
I really think the Idea of Bitcoin is good, but the security is really like russian roulette on windows machines ;-)

[riush]

Wallet encryption is being worked on right now.

As for TANs, the thing is how to tell the network about your TANs?
Maybe a special kind of transaction which publishes the hashes of the TANs for one address. Later transactions from that address are only valid if they include the plaintext of one of the unused TANs. Could something like that possibly work?

[X68N]

Thanks for the first answer on this .

I know that Wallet encyption comes maybe, my focus is on the TAN system.
Like i wrote it should be possible in the same way like the Bitcoin-network saves
the valid transactions.
So why not just store valid TANs via hashs (encrypted, not plain) in the network too?
(when they are plaintext, everybody just harvest them :-), they must be
encrypted)

The interaction with the Network, could be done the first Time the wallet is created,
or with the help of a second communication channel.
(the Network generates the TANs and send them to a predefined emailadress so,
the TAN can printed out by another PC so the risk can be lowered)


I think that this would be a great soloution.

[kokjo]

Thanks for the first answer on this .

I know that Wallet encyption comes maybe, my focus is on the TAN system.
Like i wrote it should be possible in the same way like the Bitcoin-network saves
the valid transactions.
So why not just store valid TANs via hashs (encrypted, not plain) in the network too?
(when they are plaintext, everybody just harvest them :-), they must be
encrypted)

The interaction with the Network, could be done the first Time the wallet is created,
or with the help of a second communication channel.
(the Network generates the TANs and send them to a predefined emailadress so,
the TAN can printed out by another PC so the risk can be lowered)


I think that this would be a great soloution.

you really don't know how it works, right?
as soon as you broadcast your TAN codes to the network, anyone else could take it and use your money.

scenario:
Node A, is your node. Node A knows Node B-Z, which you don't know anything about. Node B-Z was placed by an attacker, they are cancer nodes, they does not rebroadcast your transaction, instead they capture your TAN codes and gives them to the attacker.
this sucks.

you don't know any thing about this, and therefor you can only be protected from by publickey-cryptography.

[riush]

Well, an attacker would still need to have my private key to be able to sign a different transaction with the TAN.

OTOH, if he already has access to my private key, he can just wait for me to broadcast a transaction (or keylog the TAN (Edit: assuming this is the way he also got the password for the soon-to-be encrypted key)).

[Theo]

I know that Wallet encyption comes maybe, my focus is on the TAN system.
Like i wrote it should be possible in the same way like the Bitcoin-network saves
the valid transactions.
So why not just store valid TANs via hashs (encrypted, not plain) in the network too?
(when they are plaintext, everybody just harvest them :-), they must be
encrypted)

There are two problems associated with this approach:
1. Storage space is limited in the block chain as it is mirrored on all clients. If you're allowing random clients save their TAN in the network, it could be easily spammed. So you would have to introduce a fee for saving TAN hashes in the network, similar to the transaction fee.
2. Online banking TANs with their 6 numbers have a very small search space which is only secure because your bank locks your account after 3 or so wrong entries. This is not possible in Bitcoin because you can brute force the public TAN hashes offline. Thus, the TANs must be impractically long like 30 characters or so.

[kokjo]

I know that Wallet encyption comes maybe, my focus is on the TAN system.
Like i wrote it should be possible in the same way like the Bitcoin-network saves
the valid transactions.
So why not just store valid TANs via hashs (encrypted, not plain) in the network too?
(when they are plaintext, everybody just harvest them :-), they must be
encrypted)

There are two problems associated with this approach:
1. Storage space is limited in the block chain as it is mirrored on all clients. If you're allowing random clients save their TAN in the network, it could be easily spammed. So you would have to introduce a fee for saving TAN hashes in the network, similar to the transaction fee.
2. Online banking TANs with their 6 numbers have a very small search space which is only secure because your bank locks your account after 3 or so wrong entries. This is not possible in Bitcoin because you can brute force the public TAN hashes offline. Thus, the TANs must be impractically long like 30 characters or so.

and if they are 30chars long, we are back to the beginning.

@X68N:
do you really think we are stupider then you?

[X68N]

LOL
thank you for been active here, but i dont wanna hear it is not possible.
I want to discuss HOW IT IS  POSSIBLE :-)

you really don't know how it works, right?
as soon as you broadcast your TAN codes to the network, anyone else could take it and use your money.

scenario:
Node A, is your node. Node A knows Node B-Z, which you don't know anything about. Node B-Z was placed by an attacker, they are cancer nodes, they does not rebroadcast your transaction, instead they capture your TAN codes and gives them to the attacker.
this sucks.

you don't know any thing about this, and therefor you can only be protected from by publickey-cryptography.

you really don't know what i wrote, right? ;-)
The TANs are saved as "hashes" so they are NOT spread public in plaintext.(which you printed out)

scenario A is not possible because, the network accepts only transacions when the are valid
and saved at a minimum set of nodes.
So there must be a feedback between a the Network and the Client that gives a waranty
that makes sure an attacker could not capure a TAN and use it.
This could be done if the broadcost of the original client is send to a defined count but random nodes.
So that for example 10 nodes say broadcast the message the same way like a normal transaction is done.
after this is send this TAN is imidiatly useless by an attacker, because the other nodes already send the correct transaction and TAN.

if it is so useless, why is a normal bitcoin transaction not harmed by an attacker Node B-Z for example?
this answer to this question, why it is not affected, applies exactly on a TAN if it is implemented the same secure way.

Well, an attacker would still need to have my private key to be able to sign a different transaction with the TAN.

OTOH, if he already has access to my private key, he can just wait for me to broadcast a transaction (or keylog the TAN (Edit: assuming this is the way he also got the password for the soon-to-be encrypted key)).

NO, the plaintext TANcode is for security reason send to an pre-dfined email adress.
For example, when you first generate your first wallet, a private key is generated,
and the Public key is sync with the Network.
Exact the same could be done with a TAN codelist, BUT with the difference
the TANcodes are not stored on the  Computer, they should be printed out. (or send to and email Adress and then printed)
This is like a second code which is not possible to copy for a trojan, that is the idea AFTER that first
step. So keylogging is not possible because like i wrote the input is mouse based, no keys to log.
Plese read one more time.

There are two problems associated with this approach:
1. Storage space is limited in the block chain as it is mirrored on all clients. If you're allowing random clients save their TAN in the network, it could be easily spammed. So you would have to introduce a fee for saving TAN hashes in the network, similar to the transaction fee.
2. Online banking TANs with their 6 numbers have a very small search space which is only secure because your bank locks your account after 3 or so wrong entries. This is not possible in Bitcoin because you can brute force the public TAN hashes offline. Thus, the TANs must be impractically long like 30 characters or so.

To 1. dont be so pessimistic please :-)
why should it be allowed for random clients please? only because then the Idea dont work?
No offcourse it should NOT  be allowed for random clients, so it also dont get spammed.
Antispam technique should be implement client and serversided but are NOT
a special task because of the TANs.

2.Like i wrote instead of this it is possible to use more Charakters, for example like the lengh of 12-34 charcters.
There should be a method for protecting the hashes to not be easiliy harvested by an atttacker,

how does the Bitcoin network ensure that the privae key of the user cloud not be cracked offline?
the same way should be used for the TANs.

and if they are 30chars long, we are back to the beginning.
@X68N:
do you really think we are stupider then you?

no if they are 30 Characters long we are not ate the beginnig, never heard that 30 Charcters encrytion is unsafe ;-)
Same answer here
how does the Bitcoin network ensure that the privae key of the user cloud not be cracked offline?
the same way should be used for the TANs.

and no i dont think you are stupider, i just want to discuss a solution here.
There are no personal attacks.

[kokjo]

do really don't understand it do you?
of course, they are stored as hashes. but when you need to proof that you know the plain text, YOU NEED TO SEND THE PLAINTEXT. and the attacker can just capture it, and retransmit a transaction that send your coin to him.

unless you understand this, please don't say more.

[riush]

of course, they are stored as hashes. but when you need to proof that you know the plain text, YOU NEED TO SEND THE PLAINTEXT. and the attacker can just capture it, and retransmit a transaction that send your coin to him.

only if he also has the private key.. the question is, in which scenario does it help? if the attacker doesn't know the private key, there's no need for a TAN, and if he does, he can probably grab the TAN also.

So keylogging is not possible because like i wrote the input is mouse based, no keys to log.

Whatever you enter into your computer, an attacker can grab. If you use a mouse keyboard, i log your mouse movements, if you randomize the virtual key positions, i use ocr, if you make a captcha out of each key, you see where this is going...

[X68N]

do really don't understand it do you?
of course, they are stored as hashes. but when you need to proof that you know the plain text, YOU NEED TO SEND THE PLAINTEXT. and the attacker can just capture it, and retransmit a transaction that send your coin to him.

unless you understand this, please don't say more.

instead of say such unpolite things, i try to solve this "misunderstanding" you think i have...

So i ask the same in another way, how does it work that the Private key in the wallet.dat is not send in plaintext?
(or is this wrong and the privatekey is actually send in Plaintext??)
Just answer this if you know.

Whatever you enter into your computer, an attacker can grab. If you use a mouse keyboard, i log your mouse movements, if you randomize the virtual key positions, i use ocr, if you make a captcha out of each key, you see where this is going...

Like i said i want solutions, if i want to know how it doesn't work i could write a hole book my self ;-)
Dont play to be my Opponent be a helper ;-)
always so negative here...

i doubt that will ocr work, why al this spam capchas are not already passed?
A way to solve this if it is possible is a server sided sessionhash which is randowmly generated as a checksum
Browser, hardware and more etc. so if an attacker could grab the TAN which i doubt really,
he couldnt use it because he has not the exact hardware/screenresolution/browser etc.
and also could not generate this checksum itself because it is not stored in the client, it is generated  serversided.
(even he emultates the same hardware, he gets an other checksum and then also an other TAN is questioned,
because the first than is actually activated be the vicim pc)

lol what a fantasy war ;-)

[kokjo]

do really don't understand it do you?
of course, they are stored as hashes. but when you need to proof that you know the plain text, YOU NEED TO SEND THE PLAINTEXT. and the attacker can just capture it, and retransmit a transaction that send your coin to him.

unless you understand this, please don't say more.

instead of say such unpolite things, i try to solve this "misunderstanding" you think i have...

So i ask the same in another way, how does it work that the Private key in the wallet.dat is not send in plaintext?
(or is this wrong and the privatekey is actually send in Plaintext??)
Just answer this if you know.

the private key is not send in plaintext, this is your misunderstading. bitcoin uses public-key-cryptography. the algoritm used is called ECDSA. (look it up on wikipedia). the private key is used for signing the transaction. and this sign can be verifyed be using a public.

this is how it works:

your client generates a private and public key pair.
by taking a hash of the public key, you get a bitcoin address.
you gives your address to someone, and tell him to pay.

he sends you the transaction by saying: "only the person who can proof that he has the corresponding privatekey, to this address, can spend this x bitcoins", this is signed by his privatekey(s)

your client sees this and knows that you now haves x bitcoins more.

when your client wants to spend it, it broadcasts the public key, along with a signing from the private key, that proofs that your client knows the private key.
your client therefor NEVER broadcasts your private key, only proof that you have it.

and an attaker can not, intercept and change the transaction, without making the transaction invalid.

want to read more: http://en.wikipedia.org/wiki/Public-key_cryptography

i will be glad to explain more to you. but dont try to change anything without trying to understand first, it makes me angry!

[Theo]

To 1. dont be so pessimistic please :-)
why should it be allowed for random clients please? only because then the Idea dont work?
No offcourse it should NOT  be allowed for random clients, so it also dont get spammed.
Antispam technique should be implement client and serversided but are NOT
a special task because of the TANs.

2.Like i wrote instead of this it is possible to use more Charakters, for example like the lengh of 12-34 charcters.
There should be a method for protecting the hashes to not be easiliy harvested by an atttacker,

how does the Bitcoin network ensure that the privae key of the user cloud not be cracked offline?
the same way should be used for the TANs.

1. It must be allowed for random clients because there is no server that could arbitrate who is allowed and who not. If there was an arbitrator, you would have PayPal.
2. Bitcoin ensures that private keys cannot be cracked offline by using a computationally intensive algorithm and long keys. If the TANs have the same size as the private keys, there is no point in using an extra TAN because they do not provide any benefit over the private keys.

[X68N]

@ kokjo
thanks for your explainaition.
I aleready known this, but now we are sure we speak of the same thing.
So if it is possible to sign a transaction without sharing the public key like you discribe it, why do you just wrote on the other hand
a TAN system spread a private key?
My intension was that a theoretical TAN uses exact the same way like you described!
so the difference is...zero and...

@ Theo
that the benefit of of a second private keysystem like TANs are offline and not so easy to capture (and not possible to crack! like you wrote before -> see kokjo's post)
The goal is to protect the prvate key (file) , with a second security layer.


that a server does not exist i know , i just named it to name a schematic system (exchange server with bitcoin network).
Today who does verify the transactions in the Bitcoin network WITHOUT knowing the private key of the users?
(the same way a TAN could be verifyed without getting the private keys)

So we come closer together i think

[kokjo]

you simply dont understand it do ya?

the public key will be shared, therefor the name 'public' key
the privat key will not be shared, and as the name suggest.

you can then with the private key sign a transaction. that transaction can be verified with the public key.
an attacker are not able to change the transaction, without making the signature invalid.

what you are suggesting are (AFAIK):
a) first broadcast a hash of a TAN.
b) then make a transaction with that TAN, and publish that TAN. sure anyone can verify that hash(TAN)=hash_of_broadcasted_TAN

BUT, if your node are surrounded by an evil nodes, and you try broadcast the TAN.
they can ignore the transaction, copy the TAN, and put it in another transaction. bye bye btc.

also if a tan is short, 8-12 digest, it can be bruteforced.

seriously, please try to understand public key cryptography, before trying to change anything.

[X68N]

Hello,
you repead it now the third time, yes
I know how private key encryptions works, didnt you read my answer?
So we could mark this as solved.

In my latest post i wrote just to use a second private key encyption as "TAN"
which is not able to copy by trojans, because it is offline stored on paper.(input protection is secure? because i didnt get an answer)
There is no plaintext or privatekey broadcast, so the evilnodes are not needed (useless ;-) )

to be sure i repeadit it, I know how private key encryptions works

please dont make my suggestion more worse than it could be, i wrote 12-34 charcters
and not 8-12.
Also with a Privatekey encryption 12 Characters are not a problem (could be doubled easy, when adding a TANlistNumber-code, not a TAN)
You said in "bitcoin uses public-key-cryptography. the algoritm used is called ECDSA"
which is safe against bruteforce and evil nodes,
so if a second second privatekey encyption as "TAN" uses the same technique this problem is also solved.

My idea was not to make a big change, just a small.
For example with a new wallet, a user could gernerate 100 bitcoin adresses.
So my idea is instead of using 100 Adresses to modify the system to uses the 100 Adresses as TANs for one Adress.
(like i understand each adress has its own private key or not?)
if so these 100 Privatekeys (99+1) are perfect and easy to modify with a TAN system.

greets

[kokjo]

Hello,
you repead it now the third time, yes
I know how private key encryptions works, didnt you read my answer?
So we could mark this as solved.

for all you have writting, there is no proof that you know who public key cryptography works.
you might think you know, and you may know it, i cant say. but by judging from your posts, you don't. sorry for being rude.

In my latest post i wrote just to use a second private key encyption as "TAN"
which is not able to copy by trojans, because it is offline stored on paper.(input protection is secure? because i didnt get an answer)
There is no plaintext or privatekey broadcast, so the evilnodes are not needed (useless ;-) )

no your input is not secure, but that not a part of the discussion. if your system are invaded by a trojan, you are doomed.

please dont make my suggestion more worse than it could be, i wrote 12-34 charcters
and not 8-12.

if it is just a password-like TAN system, 12-34 should be enough. it could be used to encrypt the private key.
but a private/public key is around 130 characters long (hexadecimal encoded).

Also with a Privatekey encryption 12 Characters are not a problem (could be doubled easy, when adding a TANlistNumber-code, not a TAN)

again a private key is longer. TANs are random numbers.
private and public keys are generated in pairs, they can be short and insecure(around 50 chars hex-encoded), or long and secure (around 130 chars hex-encoded). but if they are 12 long i could crack them in my head, with simple math, and you could too.

You said in "bitcoin uses public-key-cryptography. the algoritm used is called ECDSA"
which is safe against bruteforce and evil nodes,
so if a second second privatekey encyption as "TAN" uses the same technique this problem is also solved.

feel free to pull the private keys out of the wallet and write them down on paper, it can be done with bitcointools(https://github.com/gavinandresen/bitcointools).
but is would just be stupid to make a double encryption/signing, it has no effect at all.

the only place this could be useful, would be if you should send money to two people.
so its needed that they meet, and agree how they sould spend the money. but they dont trust each other.
none of them can unlock the money without the other.

My idea was not to make a big change, just a small.
For example with a new wallet, a user could gernerate 100 bitcoin adresses.
So my idea is instead of using 100 Adresses to modify the system to uses the 100 Adresses as TANs for one Adress.

i does not understand you are talking gibberish.

(like i understand each adress has its own private key or not?)

yes every address has both a public and a private key.
the public one is hashed(to make it shorter, it has nothing to do with security) and published.

if so these 100 Privatekeys (99+1) are perfect and easy to modify with a TAN system.

?

[X68N]

Hello,
thanks for your answer.
So i understand that 2 things dont work, a TAN system with short characterlenght and a tan system with numbers offcourse.

So the main Problem is that there is no instance(s) in the Network which could act intelligent like a Server which decide over valid and invalid inputs and connections.
(Like the Bank, which blocks after 3 false tan inputs, )
So if a privatekey is characters 130 it makes no sense to use this as a TAN, because it is not life proof ;-)

If this could not be done,
thee are only 2 other ways to become a bit more security.
1. encrypt the wallet (built in function, and an option to close the wallet but run the client to support the network)

2. split the money in different wallets (an import export function is a good feature, and the name of the wallet.dat shoul get an random add of for example _5gBS78d to avoid overwriting if a wallet is importet to the client)

what do you think about nr.1 & 2 as an feature request?

[Mageant]

How about having incomplete private keys in the wallet?

Every time you make a transfer using a certain key you would need to add missing characters using a printout that you make when the wallet is created. The program would then also transfer any difference in BTC to a new private key so that effectively each private key is only used once. You could also store the "printout" in some file of your own choosing in case you lose the printout.