Technical documentation

Security and technical design

Security depends on both the cryptographic design and how the user protects the inputs. This page documents Kardix’s intended model and limitations.

Published June 12, 2026 · Reviewed by the Kardix editorial team · About 387 words

Local browser processing

Kardix is designed to process the passphrase, PIN, and label inside the browser. Those values are not intentionally submitted to a Kardix account or online credential vault. The bundled Argon2 library is hosted with the site so the core derivation does not need a third-party API.

Local processing reduces one class of exposure, but it does not make the browser trusted by default. A compromised operating system, malicious extension, modified website deployment, or injected script can still observe inputs.

Why Argon2id is used

Argon2id is a memory-hard password derivation function. Its purpose is to make each password guess more expensive than a fast hash would be. That slows attackers who obtain enough information to test guesses offline. It cannot turn a weak, predictable passphrase into a strong secret.

Normalization and exact inputs

Deterministic tools must define how spaces, capitalization, Unicode characters, labels, and empty fields are handled. Otherwise visually similar inputs may unexpectedly produce different results. Kardix users should treat inputs as exact and test recreation before adoption.

Threat model

ThreatWhat Kardix can doWhat it cannot do
Cloud vault breachAvoid storing generated credentials in a Kardix cloud account.Protect credentials saved elsewhere.
Weak master inputUse memory-hard derivation.Prevent guessing of common phrases.
Malware or keyloggerNothing reliable inside the same compromised device.Hide keystrokes from the operating system.
Forgotten inputsProvide repeatability when inputs are known.Recover secrets that were never stored.

Operational safeguards

  • Serve the site over HTTPS.
  • Keep dependencies minimal and locally hosted where possible.
  • Use a strict Content Security Policy when deployment allows it.
  • Version the generator and publish material changes.
  • Avoid logging form values or adding analytics around secret fields.
  • Encourage passkeys and multi-factor authentication for important accounts.

Responsible disclosure

Security reports should include the affected page, reproduction steps, browser, expected behavior, and observed behavior. Do not include real passwords, passphrases, PINs, or account data. Contact details are listed on the support page.