Skip to content
BlokSec Docs

Security FAQ

Common questions from security architects and CISOs evaluating BlokSec.

Can BlokSec access my private key?

Section titled “Can BlokSec access my private key?”

No. The private key is encrypted with AES-256-GCM using a key-encryption-key (KEK) that requires three inputs: the server salt (stored in the database), the device salt (embedded in the QR code, not stored), and the user’s PIN (never stored). BlokSec’s servers hold only the encrypted envelope and the server salt. Without the device salt and PIN, the encrypted key cannot be decrypted.

During authentication, all three factors are brought together momentarily to decrypt the key, produce a signature, and immediately discard the plaintext key from memory. BlokSec never persists the decrypted private key.

What happens if a user loses their phone?

Section titled “What happens if a user loses their phone?”

Two recovery paths are available:

  1. Backup restore — If the user previously created an encrypted backup (a QR code secured with a passphrase), they can restore their identity on a new device. All accounts are automatically recovered because account keys are deterministically derived from the master seed.

  2. Admin re-enrollment — The IT administrator unregisters the user’s devices from the admin console, which revokes the old device and generates a new claim QR code. The user scans this QR code on their new device to re-enroll from scratch.

In both cases, the lost device is immediately revoked. Even if someone finds the phone, they would need the user’s biometrics or device PIN to open the app, and the server-side revocation means the device’s credentials are no longer accepted.

Is BlokSec phishing-resistant?

Section titled “Is BlokSec phishing-resistant?”

Yes. There are two key reasons:

  1. No password to steal — BlokSec doesn’t use passwords. There’s nothing for a phishing page to capture. Users authenticate by approving a request on their own device, not by typing credentials into a web page.

  2. Device-bound approval — Sign-in requests are delivered as push notifications to the user’s registered device. The user sees the application name, location, and IP address on their phone. A phishing site might trigger a BlokSec sign-in, but the user would see the request details on their phone and can deny it if it looks suspicious.

How are keys revoked?

Section titled “How are keys revoked?”

Keys are revoked through the admin console:

  • Remove a device — Sends a revocation push notification to the device and removes it from the user’s registered devices. The app resets on that device.
  • Unregister all devices — Removes all devices and resets the user’s cryptographic identity (DID). Generates a new claim QR for re-enrollment.
  • Suspend a user — Temporarily blocks all authentication without revoking keys. The user’s credentials remain intact and can be reactivated.
  • Terminate a user — Permanently deletes the user’s identity across all organizations.

Revocation is immediate. Once a device is removed, authentication requests from that device are rejected by the server.

What is the blast radius of a compromised tenant?

Section titled “What is the blast radius of a compromised tenant?”

Tenants are fully isolated. Each organization (tenant) has:

  • Its own set of users and accounts
  • Its own applications and federation configurations
  • Its own encryption keys and certificates
  • Its own data stored in separate database documents

A compromise of one tenant’s admin credentials would affect only that tenant’s users and applications. Other tenants are unaffected. There is no shared key material or cross-tenant data access.

Does BlokSec replace MFA?

Section titled “Does BlokSec replace MFA?”

BlokSec is inherently multi-factor. Each authentication requires:

  1. Something you have — your registered mobile device (possession)
  2. Something you are or something you know — biometrics (Face ID, fingerprint) or PIN to unlock the app

For QR-based authentication (BlokCode), a third factor is added: 3. Something you know — the PIN or passphrase used to decrypt the private key

BlokSec satisfies multi-factor authentication requirements without layering separate MFA products. It combines multiple factors into a single user action (approve on your phone), making it both more secure and more convenient than password + OTP.

How is data encrypted at rest and in transit?

Section titled “How is data encrypted at rest and in transit?”

In transit: All communication between clients and the BlokSec API occurs over TLS (HTTPS). Push notifications are delivered through Apple Push Notification Service (APNs) and Firebase Cloud Messaging (FCM), both of which use encrypted transport.

At rest: User data is stored in MongoDB with encryption at rest enabled at the infrastructure level. Private keys are additionally encrypted at the application level using AES-256-GCM before being stored, providing a second layer of encryption independent of the database encryption.

What standards does BlokSec implement?

Section titled “What standards does BlokSec implement?”
StandardImplementation
OpenID ConnectFull OIDC Provider (oidc-provider v8) with authorization code flow, PKCE, refresh tokens
SAML 2.0SAML Identity Provider with signed assertions, configurable NameID formats
WS-FederationPassive sign-in support for Azure AD and Microsoft 365 integration
Ed25519Digital signatures using Curve25519 via Web Crypto API
AES-256-GCMAuthenticated encryption for private key protection
PBKDF2-SHA256Key derivation with 100,000 iterations
HKDF-SHA256Second-stage key derivation for dual-salt architecture