Security & Trust at Openfort
Protecting your users with industry best practices.
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:
Authentication methods#
Openfort facilitates a variety of authentication techniques to confirm the identities of your users, including:
- Email verification using password-based verification.
- Social account verification (Google, Apple, Twitter, Discord, Github) through OAuth2.0.
- Ethereum wallet ownership verification using Sign In With Ethereum (SIWE).
- Custom authentication methods to match your specific needs (Telegram, Farcaster, etc.)
Token Issuance & Session Management#
After authentication, Openfort issues an app Access Token (JWT):
- Signed per application; 1-hour expiry for rapid revocation.
Data Encryption & Backup#
- Encryption at Rest: All databases encrypted using AES-256.
- Regular Backups: Full daily snapshots; transaction log backups every 5 minutes; 7-day retention.
Network & API Security#
- TLS Everywhere: TLS 1.2+ with HSTS enforcement for all traffic.
- API Secrets: Each application has a unique API secret for server-to-server communication.
- Rate Limiting & WAF: Protect against brute-force and automated attacks.
Wallet Configurations#
Openfort offers three wallet types to meet diverse use cases:
- Embedded Wallet
- Cross-App Wallet
- Backend Wallet
1. Embedded Wallet#
Documentation → Embedded Wallet Integration
Users retain full control of their private key, which is generated and used entirely in a secure, isolated environment in the application’s domain.
Architecture & Workflow#
- Key Generation:
- 128-bit entropy seed generated in an isolated iframe, converted to BIP-39 mnemonic, and used to derive the keypair.
- Private Key Handling:
- Private key remains in memory within the iframe and is never persisted to any database.
- Shamir Secret Sharing (SSS):
- Splits the private key into three shares:
- Device Share: Stored in iframe’s local storage.
- Auth Share: Encrypted by Openfort; fetched via SDK on login.
- Recovery Share: Encrypted with user password or Shield service.
- Splits the private key into three shares:
2. Cross-App Wallet#
Documentation → Cross-App Wallet Setup
A wallet used across multiple applications within the same ecosystem. Functionally identical to the embedded non-custodial wallet, but scoped for interoperability.
- Hosting Domain: Iframe served from the ecosystem’s subdomain.
- Use Cases: Shared user identity and assets across games, dApps, or partner applications.
3. Backend Wallet#
Documentation → Server-Side Wallets
Backend wallets managed by Openfort’s Key Management Service (KMS) for automated and internal transactions.
Architecture & Workflow#
- Key Generation & Storage: Google Cloud KMS generates and stores private keys securely.
- Usage: Automated game transactions, escrow, contract deployments, and gasless ERC-2771 compatible actions.
Open source Key Management & 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.
- Reconstruction: Any two shares restore the private key in memory only.
- Off-chain Recovery: Combine Auth + Recovery or Device + Recovery.
- On-chain Social Recovery: Use Guardians and smart-contract-based recovery for self-custody accounts.
Smart Contract Accounts#
Programmable wallets at the smart contract layer; custodian status depends on the underlying wallet type (non-custodial, cross-app, or custodial).
Third-Party Reviews & Audits#
- Open-Source Libraries: Cryptographic libraries under GitHub.
- Security Audits: Comprehensive audits for SSS, smart contracts, and paymasters (latest reports available upon request).
Reporting Vulnerabilities#
If you discover a security issue, please contact our security team at security@openfort.xyz. We welcome responsible disclosure and reward impactful findings.