Security
Last updated: May 1, 2026
dbOrbit was built around a single hard constraint: your database credentials and the data inside your databases should never reach our servers. This page describes how that's enforced — the cryptographic primitives, the key hierarchy, the trust boundaries — and how to report a vulnerability.
1. Security Posture
dbOrbit is a local-firstmobile database client. All credentials, SSH keys, query history, schema cache, and saved queries live exclusively on your device, encrypted with AES-256 via SQLCipher and gated by hardware-backed keys (iOS Keychain / Android Keystore). We do not host a centralized identity service. We do not proxy your database traffic. We do not collect query content. There is no "forgot password" flow that goes through our servers because there is no password on our servers to recover.
If our backend were fully compromised tomorrow, an attacker would gain access to anonymized analytics counts, subscription entitlement records, and OTP delivery logs — and nothing else of yours.
2. Local-First Architecture
The trust boundaries:
- On-device only: credentials, SSH keys, recovery email, PIN hash, query content, results, schema cache
- Hardware-backed key storage: the AES-256 data-encryption key (DEK) lives in iOS Keychain / Android Keystore and never leaves the secure enclave
- Optionally synced (user-initiated): encrypted GitHub backup blob, recovery-email OTP, anonymized analytics
- Never collected: credentials, query content, schema details, host addresses (see Section 5)
Key hierarchy
- On first launch, a random 256-bit data-encryption key (DEK) is generated using the platform CSPRNG.
- The DEK is stored in the platform secure enclave (iOS Keychain with
kSecAttrAccessibleWhenUnlockedThisDeviceOnly, or Android Keystore with hardware backing where available). - The DEK is used as the SQLCipher PRAGMA key, encrypting the entire local SQLite database that holds credentials, history, and cache.
- The PIN is independent: it gates app-level unlock, not encryption. PIN is stored as a PBKDF2-SHA256 hash with a per-install random salt and 100,000 iterations.
- Biometric unlock (Face ID, Touch ID, fingerprint) is the primary unlock mechanism, with PIN as the fallback.
3. Encryption at Rest
- SQLCipher — AES-256 in CBC mode with HMAC-SHA512 authentication, 4096-byte page size. Encrypts the entire application database.
- SecureStore (iOS Keychain / Android Keystore) — stores the SQLCipher key, optional secrets, and small SSH keys (Ed25519 ~400 bytes, RSA-2048 ~1.7 KB fit directly; RSA-4096 keys are wrapped with the DEK and stored as a SQLCipher blob).
- GitHub backup (optional) — when enabled, the backup blob is encrypted with AES-256-GCM using a key derived from your PIN via PBKDF2-SHA256 (100,000 iterations) with a per-backup random salt. We never receive a plaintext copy.
- Recovery-email OTP — codes are time-bound (10 minutes), single-use, and not stored on our servers after delivery.
4. Encryption in Transit
- Database connections — TLS via the operating system's networking stack (
react-native-tcp-socketexposesnetandtlsbindings topgandmysql2). - SSH tunneling — pure-JS SSHv2 implementation (
ssh2) running over the same TCP socket layer with cryptography backed byreact-native-quick-crypto(OpenSSL on iOS / BoringSSL-style on Android). - API traffic — all dbOrbit API endpoints (subscription sync, recovery OTP, hosted-database management) use HTTPS with TLS 1.2 minimum. HSTS enabled.
- App distribution — App Store / Play Store transport is signed and encrypted by the platform.
5. Authentication & Access
- App lock — biometric primary, PIN fallback. Required to view any sensitive screen.
- Auto-lock — configurable timeout (off, 30s, 1m, 5m); locks immediately on app backgrounding when set to anything other than off.
- Recovery email — optional, used only for OTP-based PIN reset. Email is stored locally; OTP delivery via ZeptoMail.
- Temporary PIN — when the recovery email is verified, you may request a one-time temporary unlock code by email if you forget your PIN. Disabled if no recovery email is set.
- Clear all data — destructive option in Settings → Security that wipes the SQLCipher database and SecureStore entries on the device.
- No cloud account — there is no email/password login. The app cannot be unlocked remotely or by us.
6. What We Don't Store
The following data is never transmitted to or stored on dbOrbit's servers under any circumstances:
- Database passwords, SSH private keys, or any connection credentials
- SQL query content, query results, execution plans, query parameters
- Database, schema, table, or column names
- Database host addresses, IP addresses, port numbers, connection strings
- PIN codes, biometric identifiers, authentication tokens
- Data stored in or retrieved from your connected databases
- Keystroke logs, clipboard contents, screen recordings
Anonymized analytics events pass through an on-device privacy scrubber before transmission. The scrubber operates on event payloads before they are serialized for the network — it's not a server-side filter.
7. SOC 2 Readiness
We follow controls aligned with the SOC 2 Trust Services Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy) appropriate for our scale. Specifically:
- Principle of least privilege for all internal systems; access is reviewed quarterly
- Centralized audit logging on backend services with 12-month retention
- All production secrets stored in a managed secrets manager; no plaintext credentials in source control
- Mandatory two-factor authentication on all production access
- Vendor security review for all subprocessors before onboarding
- Incident response runbook with severity levels, communication templates, and a post-incident review process
- Annual penetration test of internet-facing infrastructure
A formal SOC 2 Type II audit is on our roadmap. Current and prospective enterprise customers may request a copy of our security questionnaire (e.g. CAIQ, SIG Lite) by emailing security@dborbit.io.
8. CCATS / Export Compliance
dbOrbit uses standard cryptographic primitives — TLS via the operating system, AES-256 for data at rest (SQLCipher and AES-256-GCM for GitHub backup), and PBKDF2-SHA256 for PIN hashing. We have self-classified the App under U.S. Export Administration Regulations §740.17(b)(1) as eligible for the encryption-export exemption on the basis that:
- The cryptographic functionality is ancillary to the App's primary purpose, which is database client tooling
- The cryptographic primitives are publicly available and standard (AES-256, PBKDF2, TLS, SSHv2)
- The App does not provide cryptographic functionality as a service to third parties
We file the annual self-classification report with the U.S. Bureau of Industry and Security as required. The corresponding ITSAppUsesNonExemptEncryption declaration in the iOS application bundle is set to false consistent with this classification.
9. Vulnerability Disclosure
Security researchers are encouraged to report issues responsibly. We commit to a good-faith response and treat researchers as collaborators, not adversaries.
How to report
- Email: security@dborbit.io
- Subject line: "Vulnerability report — [short description]"
- PGP: available on request
- Please include: a description of the issue, steps to reproduce, affected versions, and your assessment of impact. If you have a proof of concept, attach it.
Response targets
- Acknowledgement: within 3 business days
- Initial triage: within 7 business days
- Critical-severity fix or mitigation: within 14 calendar days
- Coordinated disclosure: we ask for at least 90 days before public disclosure of unfixed issues; we'll usually be much faster
Scope
- The dbOrbit iOS and Android applications (current production version)
- The
dborbit.iomarketing and account site - API endpoints under
api.dborbit.ioandproxy.dborbit.io
Out of scope
- Issues affecting third-party services we use (Mixpanel, Sentry, RevenueCat, ZeptoMail, GitHub) — please report those to the relevant vendor
- Self-XSS or social-engineering attacks against our staff
- Reports requiring physical access to a victim's unlocked device
- Denial-of-service via volumetric traffic
Safe harbor
Activities conducted in good faith in accordance with this policy will not be subject to legal action by us. We will not pursue or support pursuit of civil or criminal action against researchers who comply with the scope and reporting guidelines above. If a third party initiates legal action against you for activities conducted in good faith under this policy, we will make our authorization known.
10. Recent Security Updates
A rolling log of security-relevant changes will be maintained in this section. Patch-level updates that fix non-security bugs are tracked in our standard release notes and not duplicated here.
- May 1, 2026 — Initial publication of this page. Backed by the architecture documented above as of dbOrbit version 0.1.0.
Contact
For security questions or to report a vulnerability: security@dborbit.io.
For general product or privacy questions: support@dborbit.io.