Security Architecture
Built on open-source infrastructure with multiple security audits and defense-in-depth architecture.
Openfort's security architecture leverages secure execution environments to protect your users' assets. Wallet private keys are split using Shamir Secret Sharing and only temporarily reconstructed within browser-isolated secure environments when needed for specific operations, under the wallet owner's control.
Embedded Wallet Key Management Architecture
Openfort implements distributed key sharding through OpenSigner, our open-source key management service. Critical key entropy is split into encrypted shares protected by separate security boundaries.
Shamir Secret Sharing
Private keys are cryptographically split into multiple shares using Shamir's algorithm. The complete key is never persisted - it exists only temporarily in memory during operations. At least two of three shares are required for reconstruction:
| Share Type | Storage & Access |
|---|---|
| Device Share | Stored in browser's domain-partitioned local storage via secure iframe |
| Auth Share | Encrypted and stored by Openfort, accessible only with valid user authentication |
| Recovery Share | Used for wallet recovery, secured via user-managed methods or Openfort's recovery system |
Browser-Isolated Execution
Openfort secures wallets directly on user devices using browser-enforced isolation via iframes. This relies on browser security boundaries that have been battle-tested for decades:
- • Hardware-level memory protection
- • Browser process separation with isolated memory space
- • Strict origin and frame ancestor validation
- • Content Security Policy controls with network access lockdown
Authentication & Access Control
Multiple authentication methods ensure secure user identity verification before any wallet operations:
Authentication Methods
- • Email verification with password-based authentication
- • Social OAuth 2.0 (Google, Apple, Twitter, Discord)
- • Sign In With Ethereum (SIWE) for Web3 native auth
- • Custom authentication (Farcaster, Passkeys, etc.)
Token Management
After authentication, Openfort issues app-specific Access Tokens (JWT) signed per application with 1-hour expiry for rapid revocation. Tokens are required for all wallet operations and are stored as either localStorage or HttpOnly cookies depending on configuration.
Wallet Creation Process
When a user creates a wallet, the secure execution environment follows these steps:
- 1
Entropy Generation
Generate 128 bits of strong entropy from cryptographically secure random number generator (CSPRNG)
- 2
Key Derivation
Convert entropy to mnemonic using BIP-39, derive HD wallet public and private keys
- 3
Key Sharding
Split wallet entropy into key shares using Shamir Secret Sharing algorithm
- 4
Secure Distribution
Encrypt and distribute shares across separate security boundaries (device, auth, recovery)
Important: The complete private key never exists outside the secure execution environment and is immediately sharded after generation.
Transaction Signing Flow
Transaction signing happens entirely within the secure iframe environment with cryptographic operations completing in approximately 20ms:
Signing Process
- →Application passes transaction data through Openfort SDK
- →Secure iframe validates authentication and retrieves encrypted shares
- →Key reconstruction occurs only in iframe's isolated memory using device + auth shares
- →Private key used temporarily in-memory for cryptographic signing
- →Only the signature is returned to your application
- →Key material is immediately cleared from memory
Performance: Because wallets are provisioned directly on user devices, cryptographic signing is extremely fast (~150ms), enabling seamless user experiences.
Wallet Configurations
Openfort offers three wallet types to meet diverse use cases, each with different security and custody models:
1. Embedded Wallet
Non-custodial wallet generated using OpenSigner or onchain passkeys. Supports multiple recovery methods including passwords and passkeys. Keys are sharded and never leave the user's control.
2. Global Wallet
Cross-application wallet that can be used across multiple apps in the Openfort ecosystem. Uses the same embedded wallet infrastructure for key management with additional cross-app authorization.
3. Backend Wallet
Server-side wallets managed by Openfort's Key Management Service for automated and internal transactions. Ideal for programmatic operations and backend services.
Recovery Mechanisms
Multiple recovery paths ensure users can always access their wallets, even if they lose their device:
Off-chain Recovery
Combine any share with the recovery share to reconstruct the private key. Recovery share can be secured via:
- •Automatic Recovery: Openfort's open-source server called Shield secures encrypted recovery share, accessible through normal authentication.
- •Password Recovery: User-set password encrypts recovery share, Openfort has no knowledge of password.
- •Passkey Recovery: Recovery key backed up to user's biometric.
On-chain Social Recovery
Smart contract-based recovery using guardians for self-custody accounts. Users can designate trusted guardians who can collectively approve account recovery through on-chain transactions.
New Device Provisioning
When accessing from a new device, the iframe retrieves the auth share during login, then decrypts the recovery share using the configured recovery method. A new device-specific share is then provisioned for continued use.
Threat Models & Security FAQ
Understanding threat models is essential for building secure systems. We've analyzed various attack vectors and implemented comprehensive defenses:
Cross-Application Security
Can unauthorized applications access the iframe?
No. The iframe enforces frame ancestor checks via CSP and validates all origins against an allowlist configured in the dashboard.
Can unauthorized apps send messages to the iframe?
No. The iframe only accepts messages from verified parent frames with valid access tokens.
User Security
Can an unauthorized user access another user's wallet?
No. Valid access tokens are required to retrieve the auth share needed for wallet reconstruction. Tokens are user-specific and expire after 1 hour.
Protection against browser compromise?
Multiple layers: keys never persist complete, MFA for operations, auth shares not stored on device, emergency kill switches, user-managed recovery options.
Browser Security
Can extensions inject malicious code?
CSP nonces and unsafe-eval blocking provide protection. However, users should be educated about untrusted extensions. Enable wallet MFA for additional protection.
What if browser security is compromised?
Emergency kill switches, token revocation, geographic restrictions, rapid incident response, and regular security updates provide defense in depth.
Infrastructure Security
Can compromised team members access keys?
No. Keys exist only as encrypted shares distributed across security boundaries. Wallet actions are only possible within secure execution environments.
Can unauthorized code be deployed?
No. Multi-party approvals, automated security testing, staged deployments, and signed artifacts ensure only authorized code reaches production.
Security Philosophy
Security is continuous work, not a one-time achievement. We provide flexible wallet infrastructure so you can configure the system appropriate for your use-case, from email-based embedded wallets to hardware-secured cold storage.
Smart Contract Wallets
Programmable wallets at the smart contract layer provide additional security and functionality:
Account Abstraction (EIP-7702 and ERC-4337)
Smart contract wallets enable advanced features like multi-signature requirements, spending limits, social recovery, and gasless transactions. Custodian status depends on the underlying wallet type (non-custodial, cross-app, or custodial).
Security Features
- Multi-signature requirements for high-value transactions
- Time-locked operations for additional security
- Upgradeable security modules via proxy patterns
- On-chain social recovery mechanisms
- Session keys for delegated transactions
Smart Contract Audits
All smart contracts undergo comprehensive security audits by industry-leading firms including CertiK and Quantstamp. Audit reports are publicly available, demonstrating our commitment to transparency and security excellence.
Compliance & Third-Party Audits
Security Audits
Regular comprehensive audits for SSS implementation, smart contracts, and paymasters. Our open-source cryptographic libraries are available on GitHub for community review.
Infrastructure Security
- Regular Penetration Testing: Quarterly security assessments and vulnerability scanning
- Bug Bounty Program: Active vulnerability disclosure and reward program
Compliance Standards
- OWASP Top 10 Web3 Compliant
- GDPR Compliant Data Handling
- AES-256 Encryption at Rest
- TLS 1.2+ for All Traffic
Additional Security Features
IP Whitelisting
Restrict API access to specific IP addresses for enterprise deployments
Rate Limiting & DDoS Protection
Advanced rate limiting with enterprise DDoS mitigation via WAF
Automated Backups
Daily snapshots with 5-minute transaction logs, 7-day retention, multi-region replication
Immutable Audit Logs
Comprehensive logging for all API calls and administrative actions
Reporting Vulnerabilities
If you discover a security issue, please contact our security team at security@openfort.io. We welcome responsible disclosure and reward impactful findings through our bug bounty program.