Author

Topic: Multi-factor authentication in the network (Read 1134 times)

legendary
Activity: 960
Merit: 1028
Spurn wild goose chases. Seek that which endures.
June 29, 2013, 09:12:47 PM
#2
The protocol support for a feature like this can be reduced to something much simpler.
Suppose you have a way to mark a transaction as "tentative". That is, even after the transaction is committed to the blockchain, for X blocks it can be double-spent against and - should that occur - defers to any such spend attempts.

Then, your "revokable multi-factor" support can be implemented simply as addresses that read:
(sign the transfer with key 1 AND key 2)
OR
(sign the transfer with key 1, revokable for 1000 blocks [about 7 days])

If someone transfers the coins with key 1 only, and you have key 2, you can successfully double-spend against that person for seven days and move your coins to new, uncompromised keys.
full member
Activity: 168
Merit: 100
Something I would like to see in bitcoin - or would perhaps add justifiable value to an alt-coin.

Optional multi-factor authentication at the protocol level.

Say I want to make my wallet slightly more secure.
I check a box. The client then uses a private key specific to the client, signs all my public keys, and uploads it to the P2P network (blockchain or separate)

When sending coins, the transaction not only needs to be signed by the right private key but also by the client.

In the event I have to restore from backup, obviously new client won't have the key so in that event, the new client requests obsolete of the former client key. If there is not an objection after 7 days, the former client key is no longer needed. However if a client connects to the network and has that key during that 7 day period, it gets an alert that a request was made to revoke its authentication and it can deny that request.

While this multi-factor authentication will make it more burdensome to import keys that have opted into the multi-factor authentication, it will make it more difficult for stolen private keys to be used to steal coins.

A client could even be configured to require biometric sensor to access its client private key needed to send coins, or its client private key could be on a USB device that the user only plugs in when the user needs to send a transaction.

Thoughts?
Jump to: