Bitcoin Protocol Implementation of Native Two-Factor Authentication

At a town-hall style discussion in June, Bitcoin Foundation Chief Scientist Gavin Andresen cited wallet security as the most pressing issue in the bitcoin community. Though his solution at the time was hardware wallets, such as Trezor, he recently posted an alternative on GitHub: 2-factor authentication built into the client.

The challenge facing users hosting wallets on their own computer is that their PC becomes a single point of failure. Once a security vulnerability occurs, a sophisticated attacker will have little trouble locating a wallet file, transferring it to their own computers and logging keystrokes to determine the password. Hardware wallets reduce the likelihood of this occurring by moving wallets offline and are used only to sign transactions.


Unfortunately, the hardware wallet solution may not be viable for all use-cases, such as some mobile devices, so two-factor authentication can provide an additional layer of security. The basis of Gavin’s proposal is a second server that must also sign transaction in addition to a user’s local wallets. The proposal for implementing two factor authentication involves 3 steps:

  1. Create a 2-of-2 multisig wallet, meaning that that in order for a transaction to be valid it must be signed by 2 different private keys.

  2. One of the keys is stored on a local PC. The other key is stored on a remote server that provides 2nd party authentication for transactions. This server should also be synchronized with an authenticator that provides one-time-passwords (OTP) such as Google Authenticator or Yubikey.

  3. To spend coins a user is prompted to submit their OTP which is verified by the server. The user’s client and the server then submit signatures for the transaction and the coins are transferred.


Two-factor authentication requires two devices to be compromised, both the user’s computer as well as the authenticator or server. If either device alone is compromised the malicious party will not be able to spend the compromised BTC since transactions require two signatures.

Having an off-site server authenticate transactions will enable increased customization for transaction controls, such as additional verification for high value transactions or limits on BTC transfers per day. This could be built into the bitcoin-qt client, however, that would be difficult to enforce on a stolen wallet file. These controls would likely be built on a layer in the wallet software above the wallet file itself, so a stolen wallet would not be subject to the additional security if it was used by the attacker’s own software.

An established system for two-factor authentication would reduce the security risk of web wallets such as the one on Currently, encrypted wallets are hosted on the site’s servers and decryption occurs through javascript after the user enters a password, so the password never enters the site’s system. While this is a significant improvement over shared wallets where companies directly hold bitcoin, it does require trust that the javascript on their website has not been compromised. Using the protocol’s two-factor authentication would reduce the risk of javascript exploits by additionally requiring the server’s signature through the use of an OTP.


Wallet creation and backup becomes significantly more complex. If the server’s private key was stored on the local computer as a backup, then any security compromises on the local computer would make that private key vulnerable. Additionally, storing a backup of the local private key on a server would make users equally as vulnerable, if not more so. This effectively forces a third location for the backups to be stored. A flash drive may prove a usable solution for most, but once the drive is reattached to a local computer it is vulnerable to any attack vectors that may have compromised the local wallet.

Since all transactions from the wallet are being verified by a 3rd party server – unless a user creates their own server – the 3rd will be able to monitor all transactions from your wallets. For those with privacy concerns, having a 3rd party record of all personal transactions is less than ideal. Especially if those servers can be compromised by three-letter agencies concerned with collecting user information. Additionally, if the 3rd party wanted to stop specific addresses from spending coins it would be within their power to do so.

The largest question that remains to be address is where central servers will be located. In order to maintain the integrity of a decentralized payment system a significant amount of thought must be placed into decentralizing the servers as much as possible. What country would the servers be located in? Are they going to be open-source and available to everyone, and if so what security risks does that entail for storage of public keys? Does a store of key information for monetary access make the servers subject to regulation? Most likely it will have to be a closed system on a trusted provider such as an exchange to properly ensure private key security.

The final question is what redundancy can be put in place to increase availability in the event of a server outage. If the server required for the second half of your signature receives a DDoS, or undergoes technical difficulties, what are your options for sending out transactions? Backup servers are an option, but as more locations that store the private key more attack vectors become available. In a time-sensitive scenario, USB backups are an option, as mentioned earlier, however, if the local computer is compromised then two-factor authentication becomes irrelevant.

About the author  ⁄ Phillip Archer


  • Reply
    July 31, 2013

    Most of those concerns can be solved by using a 2-of-3 system, or even a 2-of-2 OR 1, instead of just 2-of-2, where to spend money you either have to sign the transaction with both of the keys you and the online service has, OR use the single key stored on paper and backed up at home. With 2-of-3, you would either use your and service’s key, or your and your cold storage/backup key.

    Glad to see Gavin working on this. He mentioned this would be his top priority project through the summer.

    • Reply
      Phillip Archer Author
      July 31, 2013

      2-of-3 doesn’t solve any problems that simply having a 2-of-2 with a backup does. If you’re going to use a second private key on the same computer it’s as compromised as just having an encrypted wallet. That is the same as having the server’s private key in cold storage. Alternatively you could use the backup key on a separate computer, but at that point your almost running your own private 2FA server.

      • Reply
        July 31, 2013

        Hmm, you’re right. Maybe combine 2-of-2/3 with deterministic addresses somehow, where you can generate the seed on a hardware wallet, create two keys for spending use, and always have the master key on the hardware that never touched the web? (Like a more advanced version of Armory)

  • Reply
    July 31, 2013

    All one need to do is to keep 256 bits secret. How hard can it be? Apparently impossible task for MS Windows generation.

Leave a Comment

74 Flares Twitter 47 Facebook 17 Google+ 8 LinkedIn 2 Email -- 74 Flares ×