Why Kardix Creates Passwords Instead of Saving Them

Kardix is designed to recreate logins, not store them. Its architecture prioritizes local processing, a visible derivation version, offline availability, and minimal provider-held data. Those choices improve some risks while placing more responsibility on the user.

Kardix began with a simple question: if a password can be recreated reliably from information only the user knows, why should the generator maintain a vault at all? The answer led to a product architecture that differs from familiar cloud password managers. Kardix has no user account for login storage, no synchronized password database, and no recovery email capable of returning generated secrets. The browser performs a repeatable derivation from a private private phrase, an optional PIN, and a stable website name. This article explains why those choices were made, what they improve, and what they deliberately do not claim to solve.

The product is based on derivation, not retrieval

Most password managers are retrieval systems. They encrypt a record, store it, synchronize it, and later decrypt it after the user unlocks a vault. Kardix is a derivation system. It treats the login as the repeatable result of a calculation. When the inputs and derivation version match, the output matches; when any input changes, the output changes.

This distinction shapes the entire interface. Kardix asks for the information required to regenerate a result rather than asking the user to open a collection of saved records. The goal is not to reproduce every vault feature without a vault. The goal is to offer a smaller tool with a different trust and storage model.

Why Kardix does not require an account

A Kardix account would create obligations that are unnecessary for local generation. The service would need sign-in, recovery, email verification, account security, abuse protection, database maintenance, and policies for retained user information. None of those systems are required to calculate a repeatable password in the browser. Removing the account keeps the core product closer to its purpose.

No account also means there is no provider login that must remain available before you can create a login. The user does not need to remember a Kardix username, protect a separate Kardix password, or recover access through a mailbox. This does not remove the need for account recovery at destination services, but it avoids adding another central identity to the chain.

Why generation happens locally

Private inputs are most useful when they remain on the trusted device. Kardix is designed so the private phrase, optional PIN, and website name are processed by browser code rather than sent to a Kardix server for derivation. The generated values appear in the page and can be copied into the destination service. A server does not need the inputs or output to provide the calculation.

Local processing reduces exposure to network logging, server databases, and login handling mistakes on the provider side. It does not make the browser a perfect secure environment. A compromised device, malicious extension, injected script, or fake website can still observe what the user types. Kardix therefore treats local generation as a data-minimization decision, not as proof that every endpoint threat has disappeared.

Why Kardix uses a memory-hard derivation step

A human-memorable phrase has less unpredictability than a long random key. Kardix uses Argon2id as part of its derivation process to make each guess more expensive in memory and computation than a simple fast hash. This matters if an attacker obtains enough information to test guesses against a known generated result. A slow, memory-hard function raises the cost of large-scale guessing.

Argon2id cannot rescue a weak or common phrase. Attackers begin with likely words, leaked passwords, names, quotations, and predictable patterns. The user still needs a long, unique private phrase that has never been used as a normal account password. The derivation function strengthens the guessing resistance of that input; it does not create entropy that the user did not provide.

Why website names are first-class inputs

A single private phrase must not create the same password for every website. Kardix mixes a stable website name into the derivation so each account receives a separate result. Labels can represent a service, an identity, and a revision, depending on the user’s convention. The important property is consistency.

Making labels visible in the workflow encourages users to think about reproducibility. A vault can display the record name later; a stateless system needs the user to reproduce it. Kardix therefore recommends simple conventions and non-secret documentation. A note that says “personal GitHub uses github-personal, revision 2” is operational metadata, not the password itself.

Why the optional PIN exists

The optional PIN provides another private input that can be separated from the main private phrase. Some users prefer to remember a long phrase and a shorter additional secret. Others leave the field empty to reduce complexity. Kardix does not force the PIN because every extra input creates another recovery dependency.

The PIN should not be misunderstood as a replacement for a strong phrase. A short predictable PIN contributes limited guessing resistance on its own. Its value comes from being an additional secret combined with the phrase and label, especially when it is stored or remembered separately. Users should choose the simplest configuration they can reproduce reliably.

Why versioning is visible

Repeatable software must remain stable. A small change in normalization, parameters, character selection, or output formatting can produce a completely different login. Silent upgrades would be dangerous because users could lose the ability to recreate existing passwords. Kardix therefore identifies its derivation process with a version such as KDX2.

Visible versioning gives the workflow a historical reference. Future improvements can use a new version without pretending that old outputs should change. Users can preserve the version alongside their non-secret label metadata. This is one of the most important differences between ordinary password generation and a stateless login system: compatibility is a security and recovery feature.

Why Kardix can work offline

A local generator should remain useful without continuous network access. The Kardix web app can be installed through supported browsers and caches the files needed for the interface and derivation engine. After installation and an initial successful load, the user can open the app offline and generate logins on that device.

Offline use reduces dependence on live servers and can help users verify that derivation is local. It also creates maintenance responsibilities. Browser storage can be cleared, devices can be lost, and installed apps can become outdated. Important users should test a second trusted device and keep the algorithm version and recovery plan independent of one browser installation.

Why Kardix generates more than a password

Online identity often includes usernames, aliases, and PIN requirements as well as passwords. Kardix can derive several login forms from the same underlying process so the user can create consistent, separated values without storing a record. The feature is intended to reduce repetitive personal identifiers and help users avoid reusing the same public username everywhere.

Not every generated field is accepted by every service. Websites enforce different length limits, allowed characters, and username rules. Users must verify the destination requirements before changing an account. When a service needs a special format, record the non-secret rule or revision needed to reproduce the accepted output later.

What Kardix deliberately does not store

Kardix does not need a hosted collection of generated passwords, usernames, or PINs. It also does not need the private phrase or optional PIN. Avoiding those records reduces what the project can expose through a database breach and simplifies the promise made to users. The generator provides a calculation, not custody of the login collection.

This principle should not be stretched beyond its scope. The destination website still receives the generated password. The clipboard may temporarily contain it. The browser may retain page state, and the operating system may expose data to malware or accessibility tools. “No vault” means no Kardix login vault; it does not mean secrets cease to exist everywhere during login.

What Kardix does not replace

Kardix does not replace two-factor authentication, passkeys, recovery codes, device encryption, software updates, or phishing awareness. It cannot tell whether a login page is genuine, and it cannot stop an attacker who controls the device. High-value accounts should use the strongest additional authentication method they support.

It also does not replace a secure document manager. People who need to store passport scans, software licenses, payment cards, shared secrets, or long secure notes may still need an encrypted vault. Kardix is intentionally focused on repeatable logins rather than becoming a general-purpose personal database.

Who benefits most from this design

Kardix is a strong fit for users who value data minimization, understand repeatable inputs, can maintain a naming convention, and want the option to generate logins offline without a provider account. It may appeal to technically curious users, travelers, privacy-conscious individuals, and people who prefer tools with fewer server-side responsibilities.

It is a weaker fit for users who require seamless team sharing, automatic emergency access, broad attachment storage, or fully managed recovery. A tool that is theoretically private but too difficult for a person to use consistently can create more risk than a well-managed vault. Practical security includes usability.

How to verify Kardix for yourself

Do not begin with your primary email or bank. Use a test account and record the exact inputs. Generate a login, close the browser, reopen Kardix, and reproduce it. Install the offline app and repeat while disconnected. Test on another trusted device. Confirm that changing one character in the label or phrase changes the result.

Then inspect the broader workflow. Can you remember the private phrase after several days? Is the label convention obvious? Do you know the KDX version? Are recovery codes available? Verification should cover human behavior as well as software behavior, because most long-term failures happen when a process cannot be reproduced under pressure.

Why the model stays intentionally narrow

Products often grow by collecting more data and adding more account features. Kardix takes the opposite approach for its core function. Every server-side feature would need to justify why it improves repeatable generation enough to accept the additional security, privacy, and maintenance burden. A smaller system can be easier to audit conceptually and cheaper to keep available.

The narrow scope also makes the message more honest. Kardix is not claiming to replace every password manager, identity platform, or authentication method. It offers one specific capability: recreate strong, separated logins locally from inputs the user controls. Users can combine that capability with other tools rather than adopting an all-or-nothing ideology.

Final perspective

Kardix is stateless because the absence of a login vault is not an afterthought; it is the product’s central design decision. Local derivation, no required account, visible versioning, stable labels, and offline installation all follow from that choice. Together they reduce provider-held login data and make the user less dependent on synchronization infrastructure.

The price is equally central: Kardix cannot recover what it never stored. The user must protect the root inputs, preserve reproducibility, and maintain independent account recovery. When those responsibilities fit the user’s habits, the stateless model can be a clear and powerful alternative. When they do not, a conventional vault or a hybrid approach may be safer.

Continue reading

Continue with how Kardix works, the Argon2id derivation guide, and the Kardix security model.