# CarryPass — Stateless Password & Credential Manager with Zero Cloud Dependency **URL:** https://discuss.privacyguides.net/t/carrypass-stateless-password-credential-manager-with-zero-cloud-dependency/28347 **Category:** Project Showcase **Tags:** software **Created:** 2025-06-15T16:41:27Z **Posts:** 52 ## Post 1 by @bbubjlaftyrcmr — 2025-06-15T16:41:27Z Hi PrivacyGuides! I’m excited to introduce CarryPass, a privacy-first, deterministic password manager and credential distribution tool built for offline use, zero trust in infrastructure, and total user control. CarryPass isn’t just another password vault. It’s a stateless web app that works fully offline, runs entirely in the browser, and never stores or transmits any secrets. There’s no backend, no tracking, and no accounts. Everything happens client-side using strong cryptography like Argon2id, PBKDF2, and AES-GCM, making CarryPass resilient even in air-gapped or high-compliance environments. I’m Zoltán, the creator of CarryPass and a long-time privacy advocate. This project was born from personal experience: after being locked out of a hacked account in 2020 and later seeing the cloud-based password manager I used get breached, I realized I could no longer trust hosted infrastructure with my secrets. I built CarryPass to eliminate the need for trust entirely. Over the past two years, I’ve worked to create a tool that gives individuals and teams cryptographically strong password generation and vault sharing — all without needing a server or exposing anything online. ### Key Features - Deterministic Passwords: Strong passwords generated from user input using Argon2id + PBKDF2 + AES-CTR. Nothing is stored. - Offline-First Vaults: Team and member-specific encrypted credential sets are distributed as static JSON files — decryptable only client-side - Optional Service Worker Delivery: Credentials can also be distributed using a Service Worker — enabling secure, offline-capable delivery of encrypted vaults within the app itself, without any cloud sync or backend server. - QR & Air-Gapped Sharing: Secure secrets can be transferred via QR between devices — no pairing, no internet, no account. - TOTP-Backed Unlock: Access passwords paired with a TOTP system provide vault access without relying on external identity providers. - Team Role Separation: Admins can maintain team vaults, while members can only view what they’re assigned. - White-Label Ready: Small teams and user groups can rebrand CarryPass with algorithm separation, ensuring cryptographic uniqueness per deployment. ### Philosophy No telemetry. No sync. No server. No trust assumptions. CarryPass is cryptography in your browser — nothing more, nothing less. All cryptographic operations take place locally, and every aspect of the system is deterministic. You can inspect, audit, and recompile your own version. Each white-label build can get a tweak to the generator algorithm to prevent overlap across organizations. ### Try It Out - Demo:[https://carrypass.net](https://carrypass.net) - Source Code:[https://github.com/racz-zoltan/racz-zoltan.github.io](https://github.com/racz-zoltan/racz-zoltan.github.io) ### Roadmap My short-term focus is on: - Finalizing TOTP secret transfer via keyboard-based grid input, without ever revealing the secret — even to the user - Publishing testable vault + password cracking challenges (for cryptanalysis by the community) - More language support (currently English/Hungarian available) Planned for later: - Offline-first desktop/mobile app (possibly via Tauri) - Editor-submitted vault updates with admin-side validation logs - Full vault changelog audit view for transparency and governance ### Feedback Welcome - What would you want from a truly stateless password-sharing tool? - How can I improve the onboarding flow or documentation for privacy-first users? I’d love your thoughts, questions, and critiques — whether you’re a privacy veteran, developer, or just curious. Thanks for reading! If CarryPass feels like something that belongs in your privacy toolkit, I’d really appreciate your thoughts or suggestions. Zoltán --- ## Post 2 by @anon77345381 — 2025-06-15T19:38:36Z Interesting! What if I needed to change a password for a specific website? How does CarryPass tackle this challenge of stateless password managers? --- ## Post 3 by @bbubjlaftyrcmr — 2025-06-15T21:49:57Z Great question! Thank you for bringing it up. That’s exactly the kind of challenge CarryPass was designed to handle. To make password rotation and revocation easier, CarryPass doesn’t just generate one password, it actually produces **six deterministic variants** from the same input. This is made possible by using **AES in CTR** (Counter) **mode** , which allows deriving a stream of random-looking bytes from a deterministic seed, and then slicing it into multiple independent password outputs. In addition, the more traditional approach is still supported: you can slightly modify an input (like the service name), or more conveniently in CarryPass, simply **increase/decrease the “Security” value** , which changes the key derivation process and results in a completely different (but still deterministic) password. So whether you want structured rotation, or intentional input tweaking (e.g. bumping the ‘Security’ counter), CarryPass keeps you in control. --- ## Post 4 by @bbubjlaftyrcmr — 2025-06-17T18:28:47Z Update: CarryPass was recently added to [Pluja’s awesome-privacy list](https://github.com/pluja/awesome-privacy#password-managers) — a curated list of vetted privacy tools! I’m really honored to see CarryPass recognized there as a privacy-respecting, stateless password manager. This reinforces the vision behind CarryPass: no cloud storage, no syncing — just secure, deterministic password generation and encrypted vault handling, all client-side. Thanks again to everyone here for the feedback and support so far! --- ## Post 5 by @mangomango — 2025-06-18T16:12:48Z Great. Is it supposed to be an alternative go KeePass ? If I understood correctly, the main problem compared to Bitwarden is that it is stored locally ? Are backups avalaible ? Even after reading your website, I am not sure. To understand what is your product. You say it is a password manager but also say “Passwords are never stored — they are safely generated when needed, and can be recreated on any device.” I don’t understand. --- ## Post 6 by @any1 — 2025-06-18T18:08:42Z The difference to KeePass, for example, is that KeePass stores your passwords encrypted on your device, but CarryPass does not store anything on your device and derives your passwords each time from your input (service name, master password, strength parameters). So instead of using your master password to decrypt your KeePass file, CarryPass generates your passwords every time. Given the same input, you will always get the same generated/derived password. You don’t need to back up an encrypted file like in KeePass, but you still need to remember the inputs you used to derive your passwords (service name, master password, strength parameters). --- ## Post 7 by @bbubjlaftyrcmr — 2025-06-18T18:56:35Z You’re absolutely right that CarryPass doesn’t work like traditional password managers such as Bitwarden or KeePass, but it _is_ a password manager, just with a completely different design philosophy. **CarryPass is a stateless password manager** It doesn’t store your passwords, not locally, not in the cloud, not even encrypted. Instead, it uses **deterministic password generation** : enter the same inputs (e.g.: website/service name + master password + settings), and it generates the same strong password every time. No sync or storage, just pure math. **No syncing, no backups needed** Because CarryPass doesn’t store anything, there’s nothing to sync or back up. You can regenerate your passwords on any device, even offline, by simply re-entering your master password, the service name and settings. **Is it an alternative to KeePass?** Not exactly. It’s an alternative approach. KeePass stores encrypted password files. CarryPass skips storage of passwords entirely. If you want to avoid the hassle and risk of managing files, CarryPass offers a simpler, stateless alternative. **Compared to Bitwarden?** Bitwarden is a solid cloud-based manager, but it requires trust in its infrastructure since your vault lives on their servers. CarryPass removes that need entirely: no servers, no syncing, no data ever leaves your device. Everything is generated in real time, in your browser. **Try it yourself right in your browser** The demo on the site isn’t just a preview, it’s fully usable. You can generate passwords, adjust settings, and see how it works. It runs fully offline, and nothing you enter is ever sent or stored by default. **Installable as an app** CarryPass is a **Progressive Web App (PWA)**, so you can install it on your phone, tablet, or desktop just like a native app. Once installed, it works offline with full functionality. --- ## Post 8 by @mangomango — 2025-06-18T19:31:30Z Thanks! @bbubjlaftyrcmr @any1 it is much clearer now for me. You should not assume that the public knows what “stateless” and “deterministic” means. Maybe this is intentional but what you explained in your last message @bbubjlaftyrcmr is not explained at all in the landing page in [https://carrypass.net/](https://carrypass.net/) Note that the demo does not work by default on Vanadium because JIT is disabled by default. First impression : wow, this kind of feel like magic!! :joy: this is indeed VERY different than Bitwarden. However I am not sure it is ready to replace traditional PM because there is no autofill. Username generator is also less customizable, etc. Also I can’t get a list of all my passwords right this is normal ? And btw you need to type your password EVERY time you want to see a password right ? Very inconvenient… The maths are sound but I feel this is not what I want from a password manager right now. --- ## Post 9 by @PaleCrow55 — 2025-06-18T19:53:26Z > [@mangomango](#): > > Also I can’t get a list of all my passwords right this is normal ? Yes, because that information is never stored anywhere. Nothing is ever stored anywhere in a stateless program. Looking at the demo app, it seems that it’s possible to locally store some metadata about the services you have passwords for. --- ## Post 10 by @bbubjlaftyrcmr — 2025-06-19T18:22:09Z _Update (June 2025)_ A [massive new breach just leaked 16 billion passwords](https://www.forbes.com/sites/daveywinder/2025/06/19/16-billion-apple-facebook-google-passwords-leaked---change-yours-now/), including fresh credentials for major services like Apple, Google, Facebook, and more. This reinforces why I built CarryPass around a stateless model: If there’s nothing stored, there’s nothing to leak. Passwords are generated locally, deterministically, and on-demand. No cloud, no sync, no tracking — and now more than ever, **no leaks**. --- ## Post 11 by @PaleCrow55 — 2025-06-19T18:25:03Z > [@16 Billion Apple, Facebook, Google And Other Passwords Leaked — Act Now](https://discuss.privacyguides.net/t/16-billion-apple-facebook-google-and-other-passwords-leaked-act-now/28475/8): > > From what I can tell, this isn’t necessarily due to password _managers_ being leaked, but data from services that need to authenticate passwords being somewhat insecure at times; either from the hash databases being leaked, or passwords themselves being transmitted insecurely. Even if you use a stateless manager, you still need to send data to the service. (reposting here) --- ## Post 12 by @anonymous261 — 2025-06-19T18:29:06Z I wouldn’t assume so, but would it be possible for this type of model to support passkeys? --- ## Post 13 by @PaleCrow55 — 2025-06-19T18:31:40Z I would also assume not. That would require a fixed private key than can be deterministically generated from the input master passphrase. --- ## Post 14 by @bbubjlaftyrcmr — 2025-06-19T18:32:45Z I’ve been reflecting on something Davey Winder (the article’s author) said: _“Password compromise is no joke… it leads to account compromise and that leads to, well, the compromise of most everything you hold dear in this technological-centric world we live in.”_ That’s why I built CarryPass. It doesn’t claim to solve all problems (servers still need to hash and protect credentials properly) **but it reduces your personal risk surface** : - No stored vaults = no vault theft - No sync = no cloud-side compromise - Deterministic password generation = **no password reuse** ever Every password is unique to the service. There’s nothing to sync, nothing to store, and nothing to steal, and that’s one less thing to compromise in a breach like this. --- ## Post 15 by @bbubjlaftyrcmr — 2025-06-19T18:36:57Z Great question! CarryPass isn’t made to work with passkeys, because passkeys need to be stored somewhere on your device or in the cloud. CarryPass doesn’t store anything — that’s kind of the whole point. It just re-creates your passwords when you need them, so there’s nothing to steal or sync. So while both try to make logging in safer, they work in totally different ways. --- ## Post 16 by @any1 — 2025-06-19T18:43:10Z What is the recommended approach when one of your passwords is leaked? Creating a new master password and resetting every single password for every service is not ideal. Would changing the security level for the compromised service be the right approach while keeping the same master password? --- ## Post 17 by @bbubjlaftyrcmr — 2025-06-19T18:49:05Z Great question! You’re absolutely right that resetting everything isn’t ideal. In CarryPass, each service gets **six unique passwords** from the same input settings — so if one of them gets leaked, you can just switch to the next one in the list. If you ever use up all six (for example, after multiple rotations), you can simply **increase the “security” level** setting for that service. This gives you a brand new set of six deterministic passwords without changing your master password or affecting other services. So you don’t need to rotate everything or start over. Just move to the next password, or bump the strength if needed. That’s part of the power of stateless design: **no reuse, no central vault, no cascade risk.** --- ## Post 18 by @Bhaelros — 2025-06-19T19:15:48Z Idea seems good, but I am not sure if it can actually replace my password manager. Correct me if I am wrong. To make this work, first I have to change all of my account passwords to the CP’s new password, and that is generated according to the AppID. Which means, at first step, I have to change hundreds of accounts. Then comes the next pain point. If want to change an account password, I have to create a new AppID, and I have to remember it. Example for gmail, - [gmail.com](http://gmail.com) \> original - [gmail.com#2025](http://gmail.com#2025) - [gmail.com#2025new](http://gmail.com#2025new) - [gmail.com#2025totallynew](http://gmail.com#2025totallynew) - [gmail.com#omg-final](http://gmail.com#omg-final) - [gmail.com#reallymon](http://gmail.com#reallymon) - [gmail.com#whatisgoingon](http://gmail.com#whatisgoingon) If my understanding is correct, then this might be good for very few sites, which doesn’t need password changes but requires complex passwords and security, but for the regular usage I don’t think it can replace a regular password manager. --- ## Post 19 by @bbubjlaftyrcmr — 2025-06-19T20:00:40Z Thanks for the thoughtful feedback, and let me clarify a key point, since this might help: In CarryPass, the **Application ID** is just a local nickname or passphrase used to personalize the app to your browser or device. It helps encrypt your settings and any locally stored data, but it’s **not involved in generating passwords** at all. The actual passwords are generated using your **Master Password** + Service name + Security level (like “[gmail.com](http://gmail.com)”, Security 101). So for Gmail, if you ever need to rotate, you don’t need to keep changing the name to _[gmail.com#somethingnewIhopefinal](http://gmail.com#somethingnewIhopefinal)_. You can: - Simply pick the next password from the 6 deterministic variants CarryPass already gives you - Or bump up the security level slightly (e.g., from 101 to 102) to get a fresh set of 6, so no need to invent new labels So yes, initial migration takes some effort, but after that, password changes are **quick, controlled, and private** — with no syncing, no vaults, and no tracking. It’s definitely a different mindset. CarryPass doesn’t aim to replace every feature of a regular password manager. It’s built for people who prioritize **privacy, control, and zero trust in infrastructure**. Some users run it alongside a vault-based manager, others go all in — and of course, some may find that it’s not for them at all. That’s totally fine. CarryPass isn’t trying to be everything. Just a **privacy-first, no-storage alternative** for those who value control over convenience. --- ## Post 20 by @IksNorTen — 2025-06-19T20:53:00Z My English isn’t that good so I may not understand everything, but what if someone else, by any chance, also using CarryPass, has the same master password as you? Isn’t there a risk that it generates to him your passwords? --- ## Post 21 by @PaleCrow55 — 2025-06-19T20:55:18Z 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](http://strongphrase.net) . --- ## Post 22 by @IksNorTen — 2025-06-19T20:59:17Z 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. --- ## Post 23 by @PaleCrow55 — 2025-06-19T21:00:32Z That’s no different from any brute-force attack. --- ## Post 24 by @IksNorTen — 2025-06-19T21:03:42Z 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. --- ## Post 25 by @bbubjlaftyrcmr — 2025-06-19T21:50:38Z 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. --- ## Post 26 by @bbubjlaftyrcmr — 2025-06-19T21:56:37Z 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**. --- ## Post 27 by @win11.shading291 — 2025-06-20T03:37:16Z > [@bbubjlaftyrcmr](#): > > simply re-entering your master password, the service name and settings Could you develop further? Do you choose the input for Service name? What are the settings? What are the security level? --- ## Post 28 by @Robin_RM — 2025-06-20T04:48:09Z What do you think of this [article](https://samuellucas.com/2024/02/25/deterministic-password-managers-revisited.html)? 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). --- ## Post 29 by @IksNorTen — 2025-06-20T06:08:13Z 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. --- ## Post 30 by @any1 — 2025-06-20T15:43:02Z > [@IksNorTen](#): > > 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. 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. --- ## Post 31 by @bbubjlaftyrcmr — 2025-06-20T17:02:50Z > [@Robin_RM](#): > > What do you think of this [article](https://samuellucas.com/2024/02/25/deterministic-password-managers-revisited.html)? 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). 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](http://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. --- ## Post 32 by @anonymous261 — 2025-06-21T01:40:26Z 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](http://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. > [@bbubjlaftyrcmr](#): > > CarryPass encourages users to **use domain names as service identifier** 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](http://github.com), or even the DOT in githubDOTcom. --- ## Post 33 by @Robin_RM — 2025-06-21T01:49:42Z Interesting! Thanks for taking your time to respond. --- ## Post 34 by @anon48875053 — 2025-06-21T12:46:25Z 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](https://github.com/privacyguides/privacyguides.org/pull/323#issuecomment-970070715) --- ## Post 35 by @bbubjlaftyrcmr — 2025-06-21T21:57:23Z > [@anonymous261](#): > > 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](http://github.com), or even the DOT in githubDOTcom. 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. --- ## Post 36 by @bbubjlaftyrcmr — 2025-06-21T22:22:43Z ### **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](http://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](https://carrypass.net/ctf-whatsmypassword.html) ### **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. --- ## Post 37 by @Cork — 2025-06-22T15:46:57Z 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. --- ## Post 38 by @PaleCrow55 — 2025-06-22T15:57:40Z 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. --- ## Post 39 by @TaivasJumala — 2025-06-23T03:07:25Z 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. --- ## Post 40 by @bbubjlaftyrcmr — 2025-06-23T17:52:18Z 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. --- ## Post 41 by @bbubjlaftyrcmr — 2025-06-23T19:00:33Z You’ve shared some concerns about stateless password managers. Things like: - “What if someone gets my master password?” - “It’s online, so anyone, including attackers, can access the same tool.” - “I want to be the only one who can derive my unique passwords — not just anyone who stumbles on the same setup.” These are all fair points. I don’t take them as criticism as they’re often voiced concerns about the stateless model. To me, they’re helpful signals. They’ve made me think hard about how stateless tools can be improved, and what kind of reassurance people are really looking for. So instead of pushing back on those concerns, I’m **treating them as** **feature requests**. I’m already working on something that builds on CarryPass’s current model, still offline, still privacy-first, but with an extra layer designed specifically to address these kinds of concerns. Not ready to share details just yet, but I just wanted to say: Yes, I hear you, and I’m building with this in mind. --- ## Post 42 by @win11.shading291 — 2025-06-24T19:33:59Z I think the constructive criticism that was provided will be super helpful to you. I also think there weren’t nearly enough encouragement for your project. It’s a completely different approach with its own problems and password manager have also their own set of problems (data breach being the biggest). Keep up the good work and I love the thinking outside the box here! --- ## Post 43 by @moonwriting — 2025-06-24T20:25:35Z > [@win11.shading291](#): > > password manager have also their own set of problems (data breach being the biggest) I think that the danger of a password manager data breach is emphasized too much when considering how these companies are securing people’s data. If I remember correctly, 1Password has even stated that their threat model starts at having their servers compromised, which is why they, and other password managers have designed their systems in a way that the impact of a possible data breach wouldn’t matter that much. In addition to end-to-end encryption and strong KDFs, 1Password has [the secret key mechanism](https://support.1password.com/secret-key-security/), while Bitwarden has achieved something similar with its [multifactor encryption](https://bitwarden.com/blog/bitwarden-security-fundamentals-and-multifactor-encryption/). In both cases, a data breach wouldn’t have any real impact on the user, as the attackers wouldn’t be able to decrypt the exposed data. However, it seems that Proton hasn’t implemented anything similar and their current security model [needs an update](https://discuss.privacyguides.net/t/strongphrase-net-random-passphrases-passcodes-usernames-and-identities/25813/9). Still, even in their case, a sufficiently strong master password would protect your data even in a case of data breach. --- ## Post 44 by @win11.shading291 — 2025-06-24T20:30:41Z Although a data breach of a password manager would be possible, this would be similar to your bank account being hacked which is unlikely as, as you have mentioned, that is their whole business. What I meant is more the daily/weekly data breaches that happen of any services you use. There are many tools to counter that (having one password per site, haveibeenpwnd, etc.), but the risk is there nonetheless. --- ## Post 45 by @xecrets — 2025-06-25T08:12:51Z Very cool, and very interesting. I have some thoughts—not criticisms, just ideas—from a security and usability viewpoint. The way it’s implemented now, you need to remember the service name (that’s fairly simple) plus possibly a private suffix. If the private suffix is unique, you need to remember it for every service. If it’s system-wide or the same, it adds very little security. Also, I don’t think it should be there at all—see below. Neither should the Application ID. From a UX standpoint, I’d much prefer that normalization of the service name happens “behind the scenes” instead of just disallowing typing of ignored characters. This allows for better UX and better visual confirmation of using the correct service name. There is no provision for multiple usernames with the same service, which seems inconvenient. Yes, you can use the service suffix as a workaround, but see below for why I think the concept of a service suffix should be removed entirely. Entering the master password every time seems like a troublesome UX—it’s just not going to happen. Part of the benefit of a password manager with a “sign-in metaphor” is that you’re spared the trouble of typing a high-entropy password every time. If you move to a different browser or device, you need to remember the setting of 5 options (32 choices), plus a length and a security level, in addition to service names and possibly suffixes. Having worked for 25+ years with encryption of data at rest (i.e., files), I know the most common reason for encrypted data loss is typing a password different from what you think you typed. This can easily happen here, since the master password is in no way verified and must be entered every time. The risk is significant that the password generated won’t be the same next time. If the service lacks a password reset, you’re in trouble. There should be a mechanism to validate that the correct master password is used consistently. You mention a visual fingerprint, but I didn’t see it in the demo, and it’s a little weak as a confirmation mechanism but certainly better than nothing. I would suggest an alternative to generate a few words as a strong visual signal, like “anchor boat frisbee nerd” etc. Or both. Collisions are not really a problem, as long as the number of possibilities are reasonably large. It’s always helpful to be able to remember and type frequently used passwords. I’d really like to see an option to generate smart passwords. This would make it easier to recognize if the correct parameters are used, as you’d have a rough idea of what the password should look like. This isn’t likely with random jumbles of characters. I use such a generator for my passwords: [https://github.com/xecrets/xecrets-words](https://github.com/xecrets/xecrets-words). It shouldn’t be hard to map the raw entropy created to more memorable passwords. While I appreciate the elegance of a stateless generator with no stored data, it would still be practical to export non-secret settings, including service-specific password configurations, since different services have different requirements. You could also store which password in the rotation is active. This allows users to back up or share convenience settings without compromising security. The system remains deterministic and reproducible even if settings are exportable. One thing to consider is how to handle service and user names. While they shouldn’t need to be secret, in practice their exposure depends on the service’s strength. Knowing them may aid social engineering or phishing. I think it would be valuable to back up service-specific settings without exposing names. This requires further thought. An important aspect of designing cryptographic (or crypto-adjacent) systems is facilitating analysis. A key rule is to reduce the number of secrets. A good cryptographic algorithm’s security should depend only on the key—nothing else. Not implementation details, no other secret or obfuscated parameters. Applied here, the password generator’s strength should depend only on the master password. Nothing else should be secret or contribute to the system’s security. Therefore, the application ID is superfluous—it shouldn’t be needed or add any strength. The same goes for other parameters, including the service suffix. I think your system provides this, though I haven’t analyzed it in detail. From the description, it seems to work fine with just the master password as the only secret. Security systems should be convenient enough to be used and should rely on a single secret. If you have to remember many separate things for each service, it becomes a barrier for use. I’ve probably missed or misunderstood something above, if so, please comment and correct. All in all, nice and interesting work. I’m considering how to apply these ideas in my own apps or how to use this concept, either as-is with your app or with some tweaks for personal use. Thanks! --- ## Post 46 by @bbubjlaftyrcmr — 2025-06-26T18:25:26Z > [@win11.shading291](#): > > I think the constructive criticism that was provided will be super helpful to you. > > I also think there weren’t nearly enough encouragement for your project. > > It’s a completely different approach with its own problems and password manager have also their own set of problems (data breach being the biggest). > > Keep up the good work and I love the thinking outside the box here! Thank you! I really appreciate this. You’re absolutely right: every approach has trade-offs, and while CarryPass tries to eliminate one class of risks (like server-side breaches), it introduces other challenges like putting more responsibility on the user to choose and protect a strong master password. But that’s also where the opportunity lies: to rethink what a password manager _can_ be when we remove assumptions like always needing a backend or central storage (even though I know that’s not a novel concept in itself). What I’m aiming for is a fresh take that combines determinism, zero cloud dependency, and real usability in one package while staying true to statelessness (as far as possible), not losing sight of privacy, and still offering room for real-world flexibility where needed. Hearing encouragement like yours really helps, especially when building something that goes against the grain. Thanks again for taking the time to share this! --- ## Post 47 by @bbubjlaftyrcmr — 2025-07-01T06:14:55Z > [@xecrets](#): > > Security systems should be convenient enough to be used and should rely on a single secret. If you have to remember many separate things for each service, it becomes a barrier for use. > > I’ve probably missed or misunderstood something above, if so, please comment and correct. Not at all! Thank you very much for your thoughtful and constructive feedback! I really appreciate the way you’ve engaged with the system. This kind of critical input genuinely helps refine both the security model and the usability experience. CarryPass is actively evolving in the direction you outlined: **reducing the mental burden** of using a stateless model while keeping its privacy-first, zero-knowledge foundation intact. Features like **remembering your service-specific settings locally** , **exportable non-secret configurations** , **support for multiple usernames per service** , and even a **reworked approach to master password use** , with more persistent, session-based handling to avoid repetitive entry, are all being shaped by exactly the kinds of concerns you raised. Your comment affirms that I’m heading in the right direction, and your perspective, especially the emphasis on minimizing secrets and supporting predictable behavior, is deeply valuable. **Thanks again for taking the time to explore the app and give such a detailed comment!** --- ## Post 48 by @yipii — 2025-07-01T15:29:51Z I might have found a use case for this tool: deniability / no trace of a list of account. Could be a nice addition to a conventionnal password manager .. For some specific websites. So I went to a website to register and… I needed an email address. Ive been using email alias for a while, and I would like to continue with this approach. Normally I would save both the unique email address and password in the password manager, but this being stateless… I would need a way to generate a **stateless email address**. Perhaps generating something@whatever.xyz ? Most website now force user to validate, so generating an non existant email on non existant domain will not work most of the time. Perhaps generating just the first part of the email address before the @ and letting user go to a temp email like yopmail ? Maybe using the first password as email, and second password as password. Thought there are more restriction on available character on email address. Would need to lower the password complexity. Maybe I can simply pick 1 temp email address and reuse across accounts like in the past. Maybe implementing somehing like Strongpass for identity generation or username or email generation, but stateless ? [Example](https://strongphrase.net/#/identity). So yeah, thinking about it later, there is a ton of workaround for username/email generation and it can still works, abeit a little bit more complicated. --- ## Post 49 by @starkle — 2025-07-02T22:17:51Z OP, it comes across like all your posts are AI generated. That would be against the rules here. As for your app, I take issue with the license. You say it is licensed as MIT for personal use, but at the same time say only non-commercial usage is allowed. So on the one hand we are licensed to “sell copies” per the MIT license, but on the other hand commercial use is disallowed? How is commercial use defined? You also say “integrating with proprietary service” requires a commercial license, which is also at odds with the MIT license. It’s just sloppy. It’s also not [open source](https://opensource.org/osd). I also don’t think this app is very useful, frankly. It requires users to remember both the master password and the configuration for each online account they have a password set for. The point of a password manager is to remove the need to remember a bunch of stuff. You keep saying that leaking the master password isn’t the end of the world because attackers would also need to know the site configuration. But if that site configuration contributes meaningful bits of entropy, then they also contribute meaningful burden of memorization for the users. Personally I wouldn’t use an “offline” tool that I can only access via a website, especially a password tool, in the first place. Even if it is programmed to function client-side only. I know this forum has a reputation for being negative but I hope it’s clear that my criticism is warranted. --- ## Post 50 by @dngray — 2025-07-12T09:47:38Z CarryPass won’t be listed for the same reason we don’t list other “stateless” password managers. Instead of remembering a main password, you’ve gotta remember the settings, so there is nothing gained by doing that. It signficantly limits what kind of data can be stored. > [@starkle](#): > > OP, it comes across like all your posts are AI generated. That would be against the rules here. Yeah I got that feeling too, please stop using LLMs to write drawn out bloated pieces which don’t improve your argument. --- ## Post 51 by @TaivasJumala — 2025-07-18T00:06:59Z If someone changes his main password couple of months. It will be miserable to achieve that as it costs tons of time for migration if adopting this measure. And if somehow one lost his main password, how can he save his data from being cracked at the instance of finding leakage? --- ## Post 52 by @bbubjlaftyrcmr — 2025-07-20T19:09:47Z **CarryPass started as a minimalist, stateless password manager, built for those who don’t want cloud sync, and don’t believe in giving their secrets to anyone, including the application itself.** I’ve been following your feedback and concerns on this forum, and I’ve thought hard about how to turn those into meaningful improvements, without compromising on privacy, determinism, or statelessness. I’ve reworked some parts of CarryPass to answer those questions, improve usability, and eliminate pain points while staying true to my privacy-first philosophy. All of the following comments directly contributed to changes in the current version: @anon77345381 “What if I needed to change a password for a specific website?” @mangomango “And btw you need to type your password EVERY time you want to see a password right ? Very inconvenient…” @any1 “What is the recommended approach when one of your passwords is leaked?” @Bhaelros “…for the regular usage I don’t think it can replace a regular password manager.” @IksNorTen “This “accessible to anyone” aspect makes me uneasy when I use a password manager.”; “Someone might know your master password…”; “you still—and unintentionally—retain the predictability of a service’s password, provided someone knows both the master password and the service in question” @anonymous261 “Trying to input capital letters, spaces, or special characters for the service identifier isn’t working for me.” @xetrets “I’d much prefer that normalization of the service name happens “behind the scenes” instead of just disallowing typing of ignored characters”; “There is no provision for multiple usernames with the same service”; “Entering the master password every time seems like a troublesome UX”; “There should be a mechanism to validate that the correct master password is used consistently”; “It shouldn’t be hard to map the raw entropy created to more memorable passwords.”; “…it would still be practical to export non-secret settings, including service-specific password configurations,…”; “You could also store which password in the rotation is active.”; “I think it would be valuable to back up service-specific settings without exposing names.” ; “the password generator’s strength should depend only on the master password.” ; “Security systems should be convenient enough to be used and should rely on a single secret. If you have to remember many separate things for each service, it becomes a barrier for use.” ### **One secret** A strong master password is the foundation of stateless security. This should be the only thing the user has to remember. CarryPass now derives everything from just one master secret, a “personal key”. This secret is now a deliberate combination of a strong passphrase you choose, and a 6-icon sequence you tap during setup. The icons act like a kind of second factor that’s hard to keylog, hard to guess, and easy to remember. This icon sequence is also part of the strength of the masterpassword. ### **No obscure parameters to remember** The old “private suffix per service” idea has been scrapped. Now a clear variant number is used if the user wants a different password version. ### **No need to remember many settings** CarryPass now supports custom password profiles. These are reusable presets that let you define a preferred password type once (e.g.: “PIN-style”, “bank login”, “Mixed character set”) and use it across multiple services. For quick starts, there are also preprogrammed password profiles already built in. You can save these service-specific password settings, encrypted with your session key without hinting at the service name in local storage. You can also export and re-import this data as a non-secret settings file, so even switching devices or backing up your setup is painless. The result is that three months from now, when you return to that one obscure site, CarryPass still remembers exactly how the password was generated, even though it never stored the password itself. It stays stateless, but with all the practical comfort of a stateful app. ### **Multiple usernames** Just like with passwords, CarryPass now offers six usernames per service at each generation. ### **Readable passwords** CarryPass now supports Diceware-style passphrases, selected from large, secure wordlists (EFF words). These are more memorable than character soup, without sacrificing entropy. The number of words depends on the variant counter, so you can rotate them easily while keeping them memorable. ### **Password rotation tracked** CarryPass now lets users rotate password sets via a variant number, and track which version is active per service. You can sync this info across devices through encrypted export if needed. Instead of easily forgettable suffixes all changes stay reproducible with no secrets added. ### **Backward compatibility preserved** For users coming from the earlier version of CarryPass or those working with shared credentials, backward compatibility is fully preserved. The new system uses a local “personal key” to secure your settings and enable personalization and it is now part of password generation. However, it can be disabled when needed. When the personal key is switched off, CarryPass behaves just like the earlier version. This mode is also essential for team vaults, where users must generate the same passwords for the team vault encryption and decryption. Thank you for all your comments and support! You can check out the latest version here: [https://carrypass.net/](https://carrypass.net/) --- ## Post 53 by @jonah — 2025-07-21T04:29:06Z Thank you for sharing! Please send a message to [@moderators](/groups/moderators) addressing the [comment above](https://discuss.privacyguides.net/t/carrypass-stateless-password-credential-manager-with-zero-cloud-dependency/28347/50) before continuing this thread.