- 14 minutes
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:
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.
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 provider1. 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’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.
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:
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).
The comparisons in the table are discussed in more detail in the subsequent sections, but are summarized here as an overview.
|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|
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.
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.
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.
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.
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.
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.
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:
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).
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.
The recovery methods are not restricted to only OAuth and can include any source that provides a stable token to Bunkyr, including an installed app or hardware authentication device ↩