Contact FAQ Guide Setup
Get Bitfi

Everything in life revolves around money.

Enable Bitfi 2FA, you are uniquely qualified to authenticate.

  • request_method

    possible values: register; authorize

  • device_id

    (string) any Bitfi Device ID

  • data_for_signing

    (hex string) 16 bytes, ie MD5 or Guid data

  • request_id

    (string) optional

  • derivation_index

    (unsigned integer) optional, default: 0

  • public_key

    (hex string) required for method: authorize

  • match_profile

    (boolean) optional for method: register

  • user_message
  • display_code
  • completed (boolean)

    indicates final message

  • notified (boolean)
  • signature_der

    (hex string) returned after completed request

  • request_id
  • public_key

    (hex string) returned after registration

  • error_message

REGISTER METHOD: When a user on your site elects to use Bitfi 2FA.

1. Send the client unique data for signing (exactly 16 bytes as a hex string).

2. Allow user to enter Device ID then start the websocket and send message with the request object. The request object should include at least the data_for_signing and this device_id.

3. The public key and a signature will be provided as part of the response message once user completes, perform server-side validation of this signature and store the public key in your user db.

AUTHORIZE METHOD. All future authorizations after registration.

1. Send the client unique data for signing (exactly 16 bytes as a hex string); and stored public key received with registration.

2. Allow user to enter Device ID then start the websocket and send message with the request object. The request object should include at least the data_for_signing, this device_id and the public_key.

3. A signature will be provided as part of the response message once user completes, perform server-side validation of this signature and complete user login.

Perform Sha256 hash of the data you submitted for signing, then with Secp256k1 invoke verify method. See Reference

With every REGISTER and AUTHORIZE request the response object will include a unique request code once the user opens the device and a handshake is established, at this time the device will be displaying a notification reflecting this code along with a message prompting its user to proceed with the method. Your client is expected to prominently display this code for easy user reference. The WS will be closed and device will communicate an "Invalid session" error if a new request is initiated for this device after user accepts and before request is completed.

With REGISTER,value of match_profile may True to ensure user information (salt and secret phrase) is also capable of deriving public keys for an established profile with the Bitfi dashboard. Device will prompt users to repeat the information when setting this value to False.

Both REGISTER and AUTHORIZE methods can include optional request_id, any string with no more than 200 characters will be returned with response once task is completed.


Any platform can extend Bitfi 2FA on their website and mobile app, there is no required authorization header for the request.

Any individual with a Bitfi device can accept the request and authenticate with their salt and secret phrase.

Bitfi's authentication is the result of an individual's personal cryptographic key, after strong key derivation from private information (salt and a secret phrase) using the same derivation methods that take place when signing a transaction to transfer an asset.

The Bitfi device is a secure and very restricted environment for the user to provide the information to perform this calculation, but it does not have any piece of the information needed to achieve the result. The same individual can use any Bitfi device to authenticate if entering the required secrets, which the device uses only for an instance when it must derive the cryptographic key and calculate the signature before disposing of what's been entered.

The public key provided by a Bitfi 2FA user is a remarkably close extension of that individual, far closer than what might be used in connection with other 2FA methods, therefore uniquely suited to prove that identity.

Does Bitfi know where users are authenticating? No. The websocket is designed to run on the client (locally) so not possible to determine the website performing the request. In fact, it's possible we won't know that a website is using Bitfi 2FA until they tell us.

Will the website using Bitfi 2FA get user balance information? No. The public key transmitted during registration is derived from a parent key ("BFA") designated exclusively for 2FA, so keys derived from it won't be associated with an asset.

It's possible a website, with other types of 2FA, already offers excellent security as result of their specialty, like certain redundant methods which are not within our purview and which properly ensure the desired security for its users, so we cannot state that Bitfi 2FA will result in more security for all sites where you have used alternate 2FA.

We can say that Bitfi 2FA will allow you to authenticate with a level of certainty capable of satisfying even the largest financial institutions, such as banks which commonly require a branch visit (or other daunting task) to complete a high value transaction, where traditional 2FA isn't an acceptable method.



Bitfi 2fa. Enterprise level security for everyone.

John Wethington (@bitfidev)

Meet the engineer whose redesigned board is now serving to effectively eliminate USB boot data on all 2020 Bitfi devices, whose exhaustive work and research led to this most remarkable achievement...absolutely brilliant!

Ben Tasker (@bentasker)

Bitfi was built upon the core principle that no keys are ever stored on this device, so few things are more important to us than ability to assure that no part of a user's secret salt or phrase will persist in hardware. Ben's comprehensive report and assistance through were absolutely crucial, the theoretical analysis he presented identified certain flaws in the approach and there is no doubt that his oversight and expertise were of great value when helping us get in proper shape with strict memory management.

Andrew Tierney (@cybergibbons)

The security researcher we can't live without. Andrew's continued vigilance has proven essential for users and certainly positive for Bitfi, keeping marketing in check when overzealous with statements and shaking up developers when solutions are needed. An example of this collaboration is Bitfi's 3-KEY salt hash which has become an important security feature for users.

Any one of these experts will serve as an excellent reference when looking to understand an approach taken with 2FA; whether working on a new app or managing security at Wells Fargo,
bizarre sm exhibit a:
we encourage you to connect with these and other researchers for a direct and independent analysis of Bitfi 2FA.

You should not contact John, Ben or Andrew if trying to advocate a "Trustless" system; you'd have a better shot presenting means by which the protomolecule might meet the spore network...