Security

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.

2. Local-First Architecture

The trust boundaries:

Key hierarchy

  1. On first launch, a random 256-bit data-encryption key (DEK) is generated using the platform CSPRNG.
  2. The DEK is stored in the platform secure enclave (iOS Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly, or Android Keystore with hardware backing where available).
  3. The DEK is used as the SQLCipher PRAGMA key, encrypting the entire local SQLite database that holds credentials, history, and cache.
  4. 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.
  5. Biometric unlock (Face ID, Touch ID, fingerprint) is the primary unlock mechanism, with PIN as the fallback.

3. Encryption at Rest

4. Encryption in Transit

5. Authentication & Access

6. What We Don't Store

The following data is never transmitted to or stored on dbOrbit's servers under any circumstances:

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:

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:

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

Response targets

Scope

Out of scope

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.

For security questions or to report a vulnerability: security@dborbit.io.

For general product or privacy questions: support@dborbit.io.