Bunkyr vs. Web3Auth/Torus

Bunkyr Overview

Bunkyr is a key-management system that generates encryption keys to protect a user’s sensitive data through the use of familiar sign-in methods, eliminating the need for paper recovery codes and seed phrases. For example, a user can generate a backup encryption key for their cryptocurrency wallet just by signing in to their existing Google account, without worrying about the underlying complexity. Keys are derived from multiple distributed pieces of information, meaning that, as long as the same information is provided, a user’s key can be regenerated at a later date without Bunkyr ever storing it.

Keys generated by Bunkyr are comprised of three components, all of which must be present to reconstruct the key:

1. A user-specific token stored by the service provider integrating with Bunkyr
2. The end user’s social sign-in information, provided directly to Bunkyr by the login provider (for example, Google, Facebook, or Apple)
3. Cryptographic hardware hosted by Bunkyr

While the generated keys can be used for any purpose, Bunkyr is intended to be used as a backup mechanism for encrypted data, to protect against a user losing their password (or other primary key). Users never see any Bunkyr interface, and the complexity of the cryptographic hardware is hidden behind a standard REST API.

Security

Bunkyr’s security is anchored by the hosted cryptographic hardware: each user’s key depends on the unique analog properties of each particular hardware instance. Bunkyr does not know which hardware instances are mapped to a given key - that information is encrypted with a key only provided during the key-generation process. Bunkyr must also be provided the user-specific token by the integrating service provider, which is used as input to the cryptographic hardware. With this architecture, Bunkyr’s system knows neither the hardware instances nor does it have the unique input to that hardware required to generate the key.

The final piece is a token provided by the end user, generally an identifier from the end user’s social sign-in (OAuth) token, provided directly to Bunkyr by the OAuth provider¹. Some OAuth providers - such as Sign in with Apple - even return different identifiers for the same user to different sites, meaning that no attacker could obtain this identifier without access to Bunkyr’s internal API keys. This is then combined with output from the cryptographic hardware to generate the user’s final key, which is returned to the integrating service provider for use in encrypting the user’s sensitive data.

When a key is generated for the first time, Bunkyr does generate some components in plaintext, but they are never stored in a manner accessible to Bunkyr - some, like the user-specific token, are returned to the integrating service provider, then securely deleted; others, like the specific hardware instances used, are stored encrypted with a key that Bunkyr does not have access to until it is provided by the service provider.

Web3Auth Overview

Web3Auth’s goals are largely similar to Bunkyr’s: to allow users to easily generate and retrieve keys using nothing more than conventional email links and social sign-ins. Web3Auth uses a distributed network of nodes (the Torus network, which is part of the same company) to require the cooperation of multiple systems to generate a user’s key.

To accomplish this securely, the key is broken up into multiple shares, any two of which can be used to reconstruct the key. Initially, two shares are created: one is stored on the user’s device and the other is broken up into sub-shares and distributed amongst the Torus nodes. More shares (such as more authorized devices, security questions, printed recovery codes) can be added to provide a recovery mechanism in case shares are lost.

Web3Auth is intended to be used as the primary authentication method for all user interactions, and the end user interacts directly with Web3Auth interfaces to log into and recover access their account. The end user’s browser directly interacts with nodes in the Torus network to reconstruct their encryption key.

Security

Web3Auth’s security architecture is built on the Torus network, with each node holding a share of the key-generation information. In order to reconstruct a user’s key, a majority of the nodes (as of this writing, 5 of the 9 nodes) must agree to release their sub-share, and the nodes follow a strict procedure:

1. The user’s browser provides a hash of their social sign-in (OAuth) token to each of the nodes, and receives a cryptographically signed “commitment” from the nodes to release their sub-share if the token is provided
   • Critically, nodes will only provide a commitment if they have not already seen this token hash, preventing reuse by an attacker
2. The user’s browser then provides the real OAuth token along with the signed bundle of commitments to each of the nodes, and each node releases their sub-share if a majority of the nodes have provided a commitment to do so
   • The sub-share is sent encrypted with a public key provided in step 1, so that only the user’s browser can decrypt the sub-shares
3. The user’s browser then assembles the received sub-shares to construct one share of the original key

When a key is initially generated, each node stores a different sub-share without sharing the value with any other node. The network also periodically rotates the values of the sub-shares (again without revealing their value), so a compromised share is only valid for a fixed period of time. Effectively, an attacker would need to compromise at least 5 of the nodes (all operated by different entities, though running the same software controlled by Web3Auth) before the network rotates values in order to obtain the complete share (which is only 1 of 2 shares needed to actually construct the user’s key).

This approach is quite sound, with an attack that could reconstruct a share of the user’s key requiring compromising a large number of nodes or the shared node software. One thing to note, however, is many of these details are not immediately clear from Web3Auth’s documentation - much of the information above and in later sections was obtained by looking through their source code (and there are over 100 public repositories in their GitHub organization, making this a difficult task).

Comparison

Overview

The comparisons in the table are discussed in more detail in the subsequent sections, but are summarized here as an overview.

Bunkyr	Web3Auth
Backup authentication method, outage or data loss does not affect normal login	Primary authentication method, outage or data loss risks all user data
Less than 1 second to generate a user’s key	Greater than 12 seconds to generate a user’s key
Never stores any data that could generate a user’s key, but has the user’s key briefly to return it	Stores data that could compromise a user’s key, but distributes shares amongst nodes for protection
Supports OAuth and other secure authentication methods, all run by third parties (Google, Facebook, Apple, etc.)	Supports OAuth as well as insecure security questions and self-hosted passwordless login
No user interface or client-side code	Users log in directly with Web3Auth, with large client-side SDKs required
Lightweight REST API with extensive documentation and direct engineering support included	Complex interaction with distributed node network, requiring use of poorly documented first-party SDK

Risk to user data

Bunkyr is designed to be a backup authentication method; the Bunkyr API is accessed only during account creation and recovery, with normal logins happening with the service provider’s existing login procedure. This means that if Bunykr suffers a temporary service interruption or even a catastrophic loss of data, users will still have full access to their data via their normal login mechanism.

With Web3Auth functioning as the primary authentication method (and providing the encryption keys to the user’s data), an outage or loss of data will cause users to lose all access to their data, potentially including monetary assets.

Winner: Bunkyr

Performance and scalability

In a recent experiment, logging into Web3Auth with their passwordless email verification took over 12 seconds after clicking the email link. This is a direct result of the security architecture described above, where the user’s browser has to perform multiple rounds of communication the Torus network nodes. This problem will only be exacerbated as more users enroll and Web3Auth requires more nodes, as users must communicate with more nodes.

Additionally, when a new secret rotation period occurs, each Torus node must send multiple messages to each other node, for every user. As the number of nodes and users grows, this secret rotation process will become more expensive, and since key generation must be paused during this rotation period, users may experience frequent service interruptions.

Bunkyr takes less than 1 second to generate a user’s key after they authenticate with their OAuth provider, and since any single hardware instance in the user’s assigned set can be used, this latency will remain roughly constant. In fact, as the number of users grows and more distributed hardware instances are added for capacity and redundancy, a user has a greater chance of accessing a hardware instance that is physically closer to them, decreasing latency even further. All of Bunkyr’s software is implemented using serverless technologies on Amazon Web Services and is deployed to multiple geographic regions, so the software can effectively handle arbitrarily large request loads.

Winner: Bunkyr

Access to plaintext data during key generation

No single Torus node ever has access to all of the sub-shares, and the shares are sent encrypted directly to the user’s browser without Web3Auth’s involvement.

Bunkyr, however briefly, does have access to the user’s plaintext key and the information used to generate it (though, like Web3Auth, Bunkyr does not have access to any of the end user’s encrypted data). All possible precautions have been taken to limit that access to as short a period as possible (after which the information is securely deleted and never stored or logged), but access is available transiently.

Winner: Web3Auth

Access to stored plaintext data

While Bunkyr never stores any of the pieces of data required to construct a user’s key, the Torus nodes always have access to the plaintext sub-shares. These shares are distributed amongst the nodes and obtaining them would require compromising a majority of the nodes in the same secret rotation cycle, but the data is still stored in a manner accessible to the nodes; a single software bug in the node software (which is all identical, and distributed by Torus) or court order could expose the shares.

Bunkyr never stores or logs any of the plaintext key-generation information, so a software bug or court order would not immediately compromise the security of a user’s key. Any data stored on Bunkyr’s system must also be combined with information stored by the integrating service provider, requiring a compromise of both parties to obtain any useful information - even then, the end user’s OAuth token must additionally be compromised in order to recreate the user’s key.

Winner: Bunkyr

Authentication methods

While both Bunkyr and Web3Auth support OAuth/social sign-ins, Web3Auth also supports security questions as well as a Web3Auth-hosted passwordless solution (a user clicks a link in their email to sign in). The answers to security questions are often public record (and considered extremely insecure), and with Web3Auth controlling the passwordless authentication, Web3Auth’s systems could maliciously issue valid authentication tokens for a user to retrieve the key share. This might be able to be mitigated by the service provider in only allowing specific authentication methods, but this still represents a security risk in the default configuration.

Winner: Bunkyr

End-user interface

Web3Auth has fairly intuitive user interface design; however, this still requires educating users about a third party on which they’re entering their credentials. At worst, acclimating users to trusting a third party interface with their credentials may open them to phishing attacks, but even in the best case there will be some confusion, especially if users are accustomed to more traditional login mechanisms.

Bunkyr never presents a user interface - all the end users ever see is the service provider’s normal user interface and their chosen OAuth provider. With everything taken care of in the background, there is no additional education required or additional phishing risk.

Winner: Bunkyr

Developer usability

Bunkyr’s API is incredibly lightweight, with only 5 straightforward REST API endpoints and extensive documentation and examples. At the end of the sequence of calls, the user’s key is simply returned to the service provider’s system. No additional client-side code is needed, and server-side SDKs are in active development and coming soon.

Web3Auth’s procedure requires at least the following steps, in a combination of client- and server-side code:

1. Querying an Ethereum contract for the current list of nodes in the network
2. Contacting each node individually, with at least 3 rounds of communication with each node
3. Manually constructing the share using a polynomial secret-sharing algorithm
4. Retrieving the second share from the end user (prompting their authorized device to release its share, for instance)
5. Manually constructing the final key using a polynomial secret-sharing algorithm

SDKs are provided for most functionality, but no documentation is available for the individual endpoints if the service provider uses an unsupported language or has custom implementation requirements.

Critically, the documentation on how their architecture works is quite vague, full of jargon, and leaves out important security details. For instance, much of the information in this comparison was obtained not from their documentation but from reading the source code for their various SDKs and node software (there are over 100 public repositories in their GitHub organization).

Winner: Bunkyr

Summary

Web3Auth has an excellent security architecture that rivals Bunkyr’s, with attacks on either system requiring extensive breaches of multiple systems or relying on brute-force attacks. Bunkyr never stores information that could be used to reconstruct a user’s key (but does have access to it transiently), whereas Web3Auth stores such data in plaintext (but secures it behind a secret-sharing scheme).

However, Bunkyr’s minimal implementation requirements, lower latency, invisible user interface, and compatibility with existing login methods result in an overall superior user- and developer-experience. All of these additional benefits also come at up to 30% lower cost than Web3Auth’s current pricing which starts at approximately $0.03 per user per month.

If you’re interested in protecting your user data with Bunkyr’s secure, scalable, and fast key-management API, please reach out directly to our engineering team to get started with the integration process. We’re committed to providing hands-on support at every step of the way so you can stop worrying about data breaches and focus on building a product your customers love.