Wenme

Security architecture

The platform has
no passwords to lose.

Wenme’s security model starts from the absence of the most-attacked primitive in identity. No password fields. No reset flows. No credential-stuffing surface. Below: what we replaced them with, and the cryptography that holds it together.

⌐ proofs · last verified 2026-04-13

Critical CVEs
0
Exploitable, last scan 2026-04-13
Auth methods
6
Passkey · TOTP · magic link · backup · SAML · OAuth
JWT signing
Ed25519
EdDSA · migrated off RS256, March 2026
Data at rest
AES-256-GCM
Authenticated encryption · per-tenant rotation
Network
AS64005
Own ASN · BGP-announced · two sites

01 / 04

One hundred percent passwordless.
Not a marketing claim.

Some vendors say “passwordless” and keep a password database as fallback. We removed the column. The legacy handlers, the reset emails, the breach-notification flow tied to hash leaks — all gone in the March 2026 cleanup.

0
password fields in DB
0
password reset flows
100%
phishing-resistant primary auth

02 / 04

Six authentication methods.
One adaptive flow.

Wenme detects what your device supports — biometric, hardware key, TOTP, magic link — and picks the strongest method available. Users on a five-year-old desktop fall back gracefully. Users on a current phone never touch a fallback.

01

WebAuthn / FIDO2 passkeys

Hardware-backed cryptographic keys, biometric verification on-device. Public-key cryptography end-to-end — no shared secrets, phishing-resistant by design.

  • · Public-key cryptography
  • · TPM / Secure Enclave
  • · Cross-platform sync
02

TOTP authenticator apps

Time-based one-time passwords, RFC 6238 compliant. Works with Google Authenticator, 1Password, Authy, Bitwarden, and any TOTP-compatible client.

  • · 30-second rolling codes
  • · SHA-256 HMAC
  • · Offline verification
03

Magic-link email

Single-use cryptographic tokens delivered by email. Always available as ultimate fallback. Bound to email and IP class for the duration of the auth flow.

  • · Single-use tokens
  • · 15-minute expiry
  • · Rate-limited per email
04

Backup codes

One-time recovery codes hashed with bcrypt (cost 12). Designed for physical storage. Never saved to localStorage. If the device is lost, the codes still work.

  • · 8-character alphanumeric
  • · bcrypt cost 12
  • · Single-use invalidation
05

SAML 2.0 federation

SP-initiated SSO with corporate IdPs. RSA-SHA256 signed assertions. Single-Logout supported. Federate against ADFS, Okta, Azure AD, JumpCloud.

  • · RSA-SHA256 assertions
  • · Single Logout (SLO)
  • · Group-to-role mapping
06

OAuth 2.1 / OIDC

Latest OAuth 2.1 standard with mandatory PKCE. No implicit grant. DPoP sender-constrained tokens (RFC 9449) optional for FAPI-tier clients.

  • · PKCE S256, mandatory
  • · No implicit grant
  • · DPoP optional

03 / 04

Infrastructure security.
Everything below the application.

The platform runs on infrastructure operated by KaritKarma — our own ASN, our own racks, our own kernel-tuned hosts. There is no hyperscaler in the path between your user and their ID token.

Data protection

Encryption at rest
AES-256-GCM, authenticated. Per-tenant key rotation.
Encryption in transit
TLS 1.3 enforced via Cloudflare Full (Strict) mode.
JWT signing
Ed25519 (EdDSA) with PKCS8 key management.
PII hashing
bcrypt cost 12 for backup codes and personal data.
Secret storage
Centralized .env (chmod 600), 48-char cryptographic passwords.

Operational security

Health monitoring
Health checks every 60s across all services.
Security event logging
Severity-based audit trail with alerting on HIGH/CRITICAL.
Session management
30-min idle timeout, 7-day absolute timeout, activity tracking.
CSRF protection
Token-based validation on all state-changing operations.
Container hardening
All caps dropped, read-only root, encrypted volumes.

addendum Post-quantum readiness

Quantum-ready foundations.
Honest about today.

AES-256-GCM and SHA-256/512 already meet the post-quantum bar (Grover-resistant). Ed25519 is the strongest classical signature in production use today, but it is not quantum-resistant — and we don’t pretend otherwise. JWKS publishes the algorithm identifier explicitly, so when ML-DSA (NIST FIPS 204) stabilizes in the Go standard library, the migration is a key rotation, not a redesign.

And because Wenme has no password column, the harvest-now-decrypt-later threat against bcrypt’d password databases doesn’t apply at all. There is nothing to harvest.

Read the cryptography spec sheet

addendum Audit trail

Every interesting event,
structured for SIEM.

The security_events table records authentication failures and successes, privilege-escalation attempts, CSRF violations, MFA bypass attempts, session timeouts (idle and absolute), LDAP bind failures and sync errors, and DC failover events. Each row is severity-tagged (CRITICAL / HIGH / MEDIUM / LOW / INFO) and emitted as structured JSON for direct ingestion by Splunk, Elastic, or Datadog.

Severity tiers
CRITICAL · HIGH · MEDIUM · LOW · INFO — alert routing per tier.
Event coverage
Auth, MFA, CSRF, sessions, LDAP, OAuth consent, admin actions.
Format
Structured JSON. SIEM-ready out of the box.

04 / 04

Compliance, plainly stated.
Implementation vs. certification.

GDPR is implemented in code. SOC 2, HIPAA, and PCI DSS technical controls are in place; formal certifications are on the 2026 roadmap. The compliance page splits these out, line by line.

GDPR
Implemented
SOC 2
Controls in place
HIPAA
Safeguards met
PCI DSS
Technical controls met

For the line-by-line breakdown of which standards we implement and which certifications are pending, see the compliance page.

Read the compliance breakdown

Get started

Move identity
off passwords.

Schedule a technical walkthrough with KaritKarma. We’ll show you the threat model, the source, and the deployment options — on-prem, hosted, or hybrid.

Vulnerability disclosures: [email protected]. Coordinated disclosure preferred. We respond within one business day.

last reviewed 2026-04-13