Then don’t use a password that’s likely to be used by someone else. For a secure memorable passphrase, use something like EFF diceware or strongphrase.net .
Of course that’s obvious to not “use a password that’s likely to be used by someone else”.
But what if you’re very, very unlucky? Of course there’s a small chance that it happens, but it still may happen.
Someone could also try to test billions and billions of passwords just to check if CarryPass returns to them some credentials from one unlucky password.
That’s no different from any brute-force attack.
The difference with classical and local password manager (like KeePassXC) is that you need to actually get the vault file before trying bruteforcing it. You can’t bruteforce somethig you don’t have, except if you use something like Bitwarden.
I’m not trying to say “It’s better or not”, just trying to know if my understanding is correct. Because if that’s correct, it may be an issue.
True.
If someone uses the exact same master password and knows which services you use and the exact same settings, then yes, they would get the same password. But that’s not a vulnerability or risk — that’s just how the world works. The same inputs will always produce the same outputs, in any deterministic system.
But in that case, the problem isn’t CarryPass — it’s that you picked a master password someone else could easily guess or use.
That’s why CarryPass puts the control in your hands:
-
Choose a strong, unique master password (like a diceware passphrase)
-
Use realistic but non-obvious service names (e.g. not just gmail)
-
And you can increase the security level or tweak settings at any time to rotate passwords deterministically
It’s up to the user to make sure their inputs are private and strong, but if they are, then the risk is extremely low.
But here’s the thing: this applies to every password manager.
If someone knows your master password in a traditional manager, they can open your entire vault.
That’s why choosing a strong, unique master password is important. This is not something unique to CarryPass. It’s universal.
Great point — and it’s true that in theory, someone could try billions of master passwords and see what CarryPass generates.
But in practice, CarryPass is designed to make that kind of brute-force attack extremely difficult and slow:
-
Every password is generated using PBKDF2 with Argon2-enhanced salt, which makes each guess computationally expensive
-
You can’t query “the system” for matches, because CarryPass is offline and doesn’t store anything
-
So an attacker would have to guess the correct password, correct service name, correct settings — and know where to try it
It’s like trying billions of keys on a door you don’t even know exists.
So yes, there’s a theoretical chance, but it’s no greater than someone guessing a master password in any traditional manager. The key is: if your inputs are strong, you’re safe, even if the code is public.
1 Like
Could you develop further? Do you choose the input for Service name? What are the settings? What are the security level?
What do you think of this article? Personally I don’t think deterministic passwords replace password managers, they lack additional features like saving card data or would be difficult to manage if you manage many accounts with different usernames that you may not remember, but I would see it useful as an addition for those accounts you need to open on a foreign device that you don’t trust installing or registering in your password manager account, in this case instead of remembering multiple password phrases, you would only have to remember one (master password).
Thank you for your explanations and your objectivity. I now have a clearer picture. Yes I understand that unlike Bitwarden or LastPass, you don’t keep anything on your servers.
However, you still—and unintentionally—retain the predictability of a service’s password, provided someone knows both the master password and the service in question.
Even though an attacker would need to know those two things—and that’s far from guaranteed—it remains possible (not everyone uses a high-entropy master password).
My opinion may hurt you, and I’m sincerely sorry because I can see you’ve invested a great deal of time and effort in creating your tool, completely rethinking the basic structure of a conventional password manager. Yet in my view, for the reasons mentioned earlier, your manager is no better suited than a local password manager such as KeePassXC, which first requires access to the victim’s vault—something that isn’t guaranteed—whereas CarryPass or Bitwarden potentially give anyone who learns your master password and the target service access to all your passwords.
Someone might know your master password without being able to reach your vault (because they don’t have your files); unfortunately, that isn’t the case with Bitwarden or CarryPass.
What may make your service slightly more appealing than Bitwarden, though, is that you must know two things to retrieve that service’s password.
This “accessible to anyone” aspect makes me uneasy when I use a password manager. I need to be sure that I—and only I—can reach my vault, not that a malicious user on a public website could amuse themselves by trying tens of billions of different combinations and I might end up as one of the unlucky ones hit.
Granted, that scenario is extremely, extremely rare. But just as some people are lucky enough to win the lottery, or others unlucky enough to be in a plane crash, I don’t see why the risk you mention couldn’t possibly happen.
The only concern, in my opinion, would be if you use a password on a site where a breach occurred or that has no rate limiting—it could theoretically be possible to try and brute-force your other logins by trying all possible combinations of master password + service name + security level to get the same password used in the breach, and then you would only have to guess the service name and security level for other passwords. However, this is not something you should worry about, because at the current moment this is virtually computationally impossible—provided the CarryPass implementation is not flawed.
1 Like
I agree with much of what you said: deterministic password tools aren’t here to replace traditional managers entirely, especially not for use cases like syncing card data or managing dozens of logins with unique usernames.
That said, your point about foreign or untrusted devices is exactly the kind of scenario where CarryPass really shines. It’s not that CarryPass was built only for that — but it’s where its stateless design, zero installation, and no cloud dependency offer a real advantage. You only need your master password, and you can safely derive credentials without leaving a trace behind.
Also, thanks for sharing the article! It raises great points about the challenges of deterministic password managers. Here’s how CarryPass addresses several of them:
Unavoidable State
“Some settings must be remembered to reproduce passwords.”
CarryPass lets users optionally store settings encrypted in localStorage. While many settings (like length or character sets) aren’t secret, CarryPass encrypts them anyway to prevent even metadata leaks. This keeps reproducibility and usability intact without leaking how you generate passwords.
Domains & Phishing Protection
“A major drawback is the user must remember which inputs go into the derivation.”
CarryPass encourages users to use domain names as service identifiers. This makes phishing harder: if you try to use the wrong domain (like githuhb.com), the derived password won’t work. It’s simple, memorable, and protects against lookalike URLs.
Resetting Passwords
“Rotating a password means remembering a new version of inputs.”
CarryPass automatically derives six deterministic variants from each input, making password rotation trivial. You can also tweak a setting (as is traditional) like “Security” for a new password while retaining the rest of the profile.
Master Password Typos
“Typos produce incorrect passwords silently.”
CarryPass uses visual fingerprinting (a small image or phrase tied to your inputs) to catch typos early, before you copy the wrong password.
Exposed Site Passwords
“A leaked password could be reversed to the master password.”
CarryPass uses an Argon2 → PBKDF2 → AES-CTR pipeline. This makes preimage attacks computationally infeasible, especially because the AES-CTR step removes entropy patterns and avoids structural leakage.
Master Password Compromise
“Losing your master password compromises everything.”
This is true for all password managers. But in CarryPass, passwords are tied to specific settings and services, so compromise is more compartmentalized. An attacker would also need the exact service name, generation settings, and correct master password.
Insecure Implementation
“Many deterministic tools are solo projects, rarely audited.”
CarryPass is applying for a third-party security audit, and I fully intend to publish the results, good or bad. Until then, I’ve applied best practices in crypto (Argon2id, CTR mode) and welcome feedback.
Salt Reuse
“If the same salt is used, changing the master password has little effect.”
CarryPass mitigates this by letting users store per-site encrypted profiles, so they can change settings (and thus derived salts) even if the master password is reused. Still, we acknowledge this as a known tradeoff in deterministic models.
Limited Derivation Options
“Users can’t control the derivation process.”
CarryPass offers full control:
-
Length, character sets (upper/lower/digits/symbols/separator)
-
Memory hardness via Argon2 (tuned by the “Security” setting, which scales memory size for better resistance against brute-force attacks)
-
CPU intensity via PBKDF2 (tuned by the “Security” setting, which also scales iteration cost for better resistance against brute-force attacks)
-
Per-site profiles with custom settings stored encrypted and locally
Modulo Bias
“Random characters from modulo arithmetic can be biased.”
CarryPass uses AES-CTR to produce high-entropy, uniformly distributed pseudorandom bytes, far beyond the quality of typical sources like Math.random(). While output characters are currently selected using modulo, which can introduce minor statistical bias when the charset length doesn’t divide 256 evenly, the input randomness is cryptographically sound, which is a critical difference.
Unlike implementations that rely on low-bit-width or weak PRNGs, CarryPass starts with a secure 128-bit+ keystream, and will soon adopt rejection sampling to eliminate even minor output bias to provide both strong entropy and uniformity.
2 Likes
So, comparing hardware passkeys to CarryPass:
-
Both are offline and randomly generate secrets
-
Hardware passkeys are immune to phishing, are impossible to get without physical access, and you don’t have to remember as much
-
CarryPass doesn’t require any storage, and is accessible anywhere there is a device with a browser that can connect to carrypass.net
So it seems to me that hardware passkeys are still preferable to passwords, including deterministic manager ones. However, use of a good deterministic password manager may be one of the best options for if passwords are required.
Trying to input capital letters, spaces, or special characters for the service identifier isn’t working for me. It doesn’t seem like I’m able to type the period in github.com, or even the DOT in githubDOTcom.
Interesting! Thanks for taking your time to respond.
Stateless password managers used to be recommended on PG in the past, but not anymore. For those wondering why, I would recommend reading this entire discussion: Remove LessPass and Spectre by freddy-m · Pull Request #323 · privacyguides/privacyguides.org · GitHub
2 Likes
Thank you for bringing it to my attention. I have included more explanation in the tooltip now. Service name is normalized, so only lowercase letters and numbers remain in the input field.
CarryPass Public Challenge: Can You Derive the Password?
Many people feel uneasy about using stateless password managers.
They worry that if their master password is ever discovered, it could lead to the same catastrophic outcome as with a breached password vault - total compromise of all their credentials.
This challenge exists to examine that fear directly, and publicly.
A known master password was used to generate a login password for carrypass.net using the public CarryPass generator.
Your task is to determine the exact combination of service input, password length, charset, and security number — and enter the correct variant of the generated passwords to solve the challenge.
Try it here: CarryPass Public Challenge
Why This Matters
With vault-based password managers:
- If your master password is cracked, your entire vault is exposed.
With CarryPass:
-
There’s no vault. There’s no stored data.
-
Even with the master password, you only get a password if you know the correct settings for a specific service.
You’re not unlocking a database, you’re trying to match a lock without knowing its shape.
If You Succeed
-
You’ll receive a timestamped flag
-
You’ll be asked to submit a screenshot, your generator settings, and an alias
-
If you choose, you’ll be publicly acknowledged in the PrivacyGuides Showcase
Think stateless is too risky?
Here’s your chance to prove it — or prove why. Although not impossible, it’s much harder to break than it looks.
Why Is This Hard?
Even though the password is derived deterministically, the difficulty comes from:
-
The attacker having to guess the exact service input (after normalization)
-
Choosing the correct password length
-
Picking the right charset (letters only? full? alphanumeric?)
-
Setting the right security number / iteration level
-
Selecting the correct variant index (CarryPass generates multiple)
The number of combinations grows exponentially, and there’s no vault to attack or decrypt.
Why It’s Harder with CarryPass
CarryPass doesn’t just hash inputs and hope for the best.
It strengthens deterministic password generation with real cryptography:
-
Argon2id - a memory-hard function that resists GPU and ASIC attacks
-
PBKDF2 - iterated key derivation using HMAC-SHA for structured stretching
-
AES-CTR - a secure stream cipher mode to transform the output into high-entropy passwords
Each password is derived from:
-
Your master password
-
Normalized service name
-
Security number
-
And a composite salt enhanced through Argon2
The result? Even though CarryPass is deterministic and stateless, it’s not naive.
Each output is hardened by layers of slow, verified crypto designed to make brute-forcing mathematically expensive.
Bonus Challenge: Explain Why
If you’re a cryptography enthusiast or security researcher, you’re welcome to go beyond solving, and explain why it’s hard.
Mathematical breakdowns, attack modeling, or entropy estimates are welcome.
If it’s weak, show how. If it’s strong, show why.
I’ll include standout explanations alongside solvers.
If someone were to use this for all of their passwords, what’s to prevent the site from disappearing and consequently locking them out of all of their passwords?
This is an interesting project, but I want local control over my passwords.
It’s open source, so you can run the algorithms anywhere, not just on the main website.
Keeping a backup of the code to generate your passwords would be the equivalent of keeping a backup of the stored/encrypted password database.
1 Like
I think people won’t like it. The problem here is that there is a probability that someone happen to crack it.(Although it’s very, very rare) However, as long as the encrypted file of KeePass or Bitwarden vault doesn’t leak, the probability here is zero. People don’t like it may just don’t want to take a risk at the beginning of managing passwords, we may rather detail with risk of KeePass file leakage which is something we feel under control.
Yet your plan maybe better mathematically, I just can’t fight against my human nature.
Thanks — this is exactly the kind of feedback the challenge is meant to surface.
You’re right: with vault-based tools like KeePass or Bitwarden, if the vault never leaks, risk is low.
But that “if” — the presence of a file — is also the main stressor.
CarryPass shifts the model:
-
No vaults to store, sync, or protect
-
Nothing is saved — nothing to steal
-
If someone has your master password and guesses your exact inputs, they can derive a password — but that’s far from easy, and you can make it even harder with private labels
Even a leaked master password plays out differently:
-
In CarryPass, it’s just one layer — the attacker still needs the right service input and settings
-
In vault-based systems, if the vault is accessible, the entire dataset is at risk
In vault-based tools, you protect the safe.
In CarryPass, there’s no safe to find — only keys you build when needed.
Even if someone precomputes a million possible passwords and one happens to match the challenge, in real life they wouldn’t know it’s correct until they try logging in.
And real login attempts leave traces, trigger rate limits, or get blocked entirely.
In CarryPass, breaking one password doesn’t unlock others — and verifying any guess requires going live.
2 Likes