Security
At Openfort, safeguarding the data and digital resources of your users is our utmost concern. We understand the crucial role we play in supporting our customers' applications and deeply value the trust placed in us.
Our system's design and infrastructure have been rigorously evaluated through multiple security assessments, audits, and penetration tests. Recognizing security as an ever-evolving challenge, we continually subject our systems to these evaluations to identify and remedy emerging vulnerabilities.
The process of embedding, maintaining, and testing security measures within your application is a significant endeavor. We dedicate ourselves to implementing industry-leading practices to protect your users' data and digital assets.
Highlighted below are key practices we employ:
Openfort Authentication Methods#
Openfort facilitates a variety of authentication techniques to confirm the identities of your users, including:
- Email verification using a one-time password (OTP) and password-based verification.
- Social account verification (Google, Apple, Twitter, Discord, Github) through OAuth2.0.
- Ethereum wallet ownership verification using Sign In With Ethereum (SIWE).
Token Issuance#
Following identity verification via any method mentioned, Openfort grants tokens for session authentication within your app.
- App Access Token: This token, helps ascertain user authentication within your app. It's a JSON Web Token (JWT), signed uniquely for your app, ensuring its authenticity and protection against forgery. This token helps your front and back end verify user authentication and originates from authenticated users. Its validity spans one hour, facilitating prompt session revocation and minimizing exposure risks.
User Data Encryption and Backup#
Openfort encrypts all database information at rest, with daily full snapshots and transaction log backups every five minutes, ensuring a week's worth of data restoration capabilities.
Traffic Encryption#
All network traffic employs TLS 1.2 encryption or higher, with HTTPS Strict Transport Security (HSTS).
API Security#
Access to Openfort's API for user data management requires authentication via the app's API secret.
Signer Configuration#
Based on client needs, we offer three types of signer setups:
-
Embedded self-custodial signer
1. App embedded signer
- Creation and recreation of the private key occurs in a separate iframe within the Openfort subdomain.
- Offers more flexibility for individual applications.
- The user is custodian of the private keys.
2. Ecosystem embedded signer
- Creation and recreation of the private key occurs in a separate iframe within the ecosystem's subdomain.
- Offers interoperability at the ecosystem level granting apps and game with cross-app capabilities.
- The user is custodian of the private keys.
-
- Reserved exclusively for developer accounts. Ideal for automatic transactions and internal transactions.
- Openfort is custodian of the private keys.
Embedded self-custodial signer#
Using Shamir Secret Sharing (SSS) technology, when a user creates an account, the private key is generated in an isolated iframe, which manages the user's private key and handles wallet operations. Here is how it works:
- Openfort API: This component is responsible for storing metadata associated with a user's wallet, such as the wallet's address. It's a foundational layer that links a user's identity with their wallet operations securely.
- Isolated iframe: A crucial element in ensuring the security and privacy of a user's private keys. The isolated iframe operates as a secure environment, managing the private key and executing wallet operations. This setup is pivotal because it keeps the private key confined to an in-memory state within the iframe, never storing it in a database or allowing it to persist beyond the session. This isolation also means the private key is protected from potential exposure or theft, as it's inaccessible to both the app's code and the Openfort SDK.
- Openfort SDK: Offers a high-level interface for applications to interact with the embedded signer seamlessly. It simplifies the integration process, allowing developers to incorporate wallet functionalities without needing to delve into the complexities of blockchain technology.
The design philosophy ensures that the wallet's private key is always under the user's control, aligning with the principles of self-custody. This means that neither Openfort nor any integrating application has access to the wallet's private keys, safeguarding user autonomy and security.
The isolated iframe operates as a secure environment, managing the private key and executing wallet operations. If you'd like to host your own iframe instance, please refer to the Advanced self-hosted documentation.
Architecture#
While the underlying key management and mechanics remain consistent across all setups, the hosting location of the iframe (ecosystem subdomain vs. within the app) determines whether the signer is cross-app or app-specific.
Key management#
Openfort's approach to key management and wallet recovery is built on a foundation of security and user control. When a user sets up an embedded signer, the process involves:
- Generating a Public-Private Keypair: Utilizing a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) to ensure randomness, the iframe generates a keypair. This process involves selecting 128 bits of entropy and converting them into a mnemonic using the BIP-39 standard, from which the public and private keys are derived.
- Private Key Splitting: To enhance security, the private key is divided into three shares using Shamir's Secret Sharing, a method for distributing a secret amongst a group of participants. The shares are:
- A Device Share, stored locally on the user's device within the iframe's storage.
- An Auth Share, encrypted and held by Openfort, retrievable via the SDK during login.
- A Recovery Share, encrypted with either user-provided entropy (like a strong password) or with automatic recovery.
Recovery is facilitated through a service known as Shield, which manages the recovery share. It's important to note that the authentication share is retained within Openfort.
Deployment Options: You can either use the self-hosted or the managed Shield service.
Managed Shield service considerations When Openfort manages Shield on your behalf, the primary security objective is to prevent Openfort from having control over both the authentication and recovery shares simultaneously. This precaution is essential to avoid the possibility of reconstructing the private key.
To accomplish this, when registering your project with shield, you will get an extra parameter called encryption_share. This parameter is one of the 2 shares of a splitted encryption key (that uses the same Shamir's Secret Sharing algorithm) that is used to encrypt the recovery share. This way, Openfort can't decrypt the recovery share without the encryption share.
This setup ensures that the full private key is reconstructed only in memory and never persists, requiring at least two of the three shares for reconstitution.
Account recovery#
Users are able to recover their private key even if they lose their device or if they lose access to your game. We support two methods of recoverability.
Offchain recoverability:
- If the user loses access to their device and is unable to retrieve their device share, they can combine their auth share and decrypt their recovery share to reconstitute the full private key.
- If the user loses access to your app and is unable to retrieve their auth share, they can combine their device share and decrypt their recovery share to reconstitute the full private key.
Onchain recoverability: Using social recovery to update the owner of the smart account. You can choose to set up Openfort is the entrusted guardian uppon account initialization as well as set up guardians that you help your users can recover access to their smart account. Lear more about social recovery.
Openfort custodial signer#
Developer accounts are tailored for the internal mechanics of your game. The signer is stored with Openfort KMS in order to manage the operations of the game. Each account can serve several purposes like escrow assets, being used to deploy contracts or simply as a treasury to transfer purchases of NFTs. The dev accounts are ERC2771 compatible to offer gasless transactions.
Architecture#
For developers and studios requiring managed wallets, Openfort leverages Google Cloud KMS to generate and securely store wallet private keys. This process allows for the automated creation of developer wallets, streamlining the management of in-game currencies, assets, and player transactions.
Key Management#
The KMS ensures that all cryptographic keys are stored securely, with stringent access controls and audit trails. This setup not only provides a high level of security but also complies with industry standards and regulatory requirements, ensuring that sensitive information is protected against unauthorized access.
The use of a KMS allows for robust key management and recovery processes. In the event of key loss or compromise, the KMS provides mechanisms for key recovery and rotation, minimizing the risk of asset loss and ensuring continuity of game operations.
Smart Contract Accounts#
Openfort smart accounts offer programmability directly at the wallet level. Custodianship of these smart accounts depends uppon how the signer that "owns" the wallet is managed.
Third-Party Reviews#
All of Openfort’s cryptographic libraries (notably around Shamir's Secret Sharing) are open-sourced and have undergone an audit. The latest smart contracts and paymasters were also audited.
If you are a security researcher and would like to reach out to us, please do so using security@openfort.xyz.