Announcement header or pricing ticker

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.

Schedule a Demo

"*" indicates required fields