CarryPass — Stateless Password & Credential Manager with Zero Cloud Dependency

[bbubjlaftyrcmr]

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.

[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!

[moonwriting]

@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, while Bitwarden has achieved something similar with its 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. Still, even in their case, a sufficiently strong master password would protect your data even in a case of data breach.

[win11.shading291]

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.

[xecrets (Svante Seleborg)]

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. 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!

[bbubjlaftyrcmr]

@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!

[bbubjlaftyrcmr]

@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!

[yipii (It's a meee Yipii !)]

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.

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.

[starkle]

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.

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.

[dngray (Daniel Gray)]

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.

[TaivasJumala]

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?

[bbubjlaftyrcmr]

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:

@banana “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/