p.enthalabs

Show HN: Sesame - a local-first, open-source password manager

27 points · 12 visible top comments · 2026-08-28 19:14:14 UTC

usesesame.app · Read Story HN original

I have been working on Sesame, an open-source password manager that keeps your vault local by default. You don't need an account to create or use a vault, and the hosted service never receives the vault itself. It's still early software and the independent security review isn't finished yet, so I am mainly interested in feedback, testing, and people looking through the code.

(Linux support is yet to be released on v0.1.2, but currently is in the works.)

Comments

ramon156 · 2026-08-28 19:34:07 UTC
how does this compare to vaultwarden + bitwarden? my only concern there is that VW can throw self-host support out the door whenever they like. not that they'd have a reason to
d0mkaaa · 2026-08-28 19:44:17 UTC
vaultwarden + bitwarden is way more mature right now, but the main difference is that sesame is local-first by design. Vaultwarden also depends on staying compatible with bitwarden's clients/api, while this owns the whole stack
alacritas0 · 2026-08-28 22:24:59 UTC
bitwarden clients are open source, so it would be possible to fork them if bitwarden ever makes user unfriendly decisions
gregable · 2026-08-28 20:58:55 UTC
How does it compare to KeePassXC?
d0mkaaa · 2026-08-28 21:11:45 UTC
KeePassXC is definitely much more mature right now. I mean, Sesame is similar in being local-first and not requiring a cloud service, but I am aiming for a more modern consumer style experience. There is still a lot of work ahead to get it up to speed. I might also build more products around it eventually, so there’s a consistent ecosystem.

(and of course, it would be great to eventually surpass some of the existing projects :) )

gonzalohm · 2026-08-28 22:33:51 UTC
What do you mean by a "consumer style experience"?
NewsaHackO · 2026-08-28 23:13:40 UTC
subscription style paid program, of course. Starting at 1 dollar a month now, until they get market penetration, then they will jack up prices (for increased opex, ostensibly). The classic SaaS playbook.
konaraddi · 2026-08-28 21:26:38 UTC
Does it purge passwords from memory on vault lock?
d0mkaaa · 2026-08-28 21:52:06 UTC
Yes. Every lock entry point (manual, auto-lock timer, app shutdown) funnels through one function, so the behavior can't drift, that calls lock_for_lifecycle, which drops the unlocked session. Dropping UnlockedVault zeroizes the 32-byte vault key and the whole in-memory payload in place before deallocation: names, logins, notes, cards, SSH keys, TOTP material, history, trash. Parsed import rows are wiped on lock too, and a session epoch is bumped so any pending browser fill approval dies with the lock! (also to mention it does not cover swap and hibernation files) ((also to mention I couldn't link the lines to mentioned functions but if you want to take a look, look at these lines: src-tauri/src/vault/mod.rs:78 sesame-core/src/lib.rs:197 sesame-core/src/lib.rs:225 types.rs:2184 ))
arlattimore · 2026-08-28 21:31:33 UTC
I like that this could be self hosted. I don't have anything against the big password managers (I use and pay for one), but they are a massive target for hackers for obvious reasons. If everyone could self host their own vault on a personal domain, the reward for hackers is much more difficult to get access to.
d0mkaaa · 2026-08-28 21:57:30 UTC
I don't really have anything against the big password managers either. I just don't love having to pay for a full year upfront with some of them. More than that though, a lot of them just don't quite fit what I want, or they feel a bit dated to use, like KeePassXC. That's a big part of why I started building Sesame. (and hoping to expand later on to have a more pleasurable ecosystem)
NewsaHackO · 2026-08-28 23:23:27 UTC
>I like that this could be self hosted.

For now. I note that all of the repos that are attached to the project have a license except sesame-server, which I do not think is an accident.

cyberax · 2026-08-28 21:35:33 UTC
I don't see the support for passkeys listed anywhere?
d0mkaaa · 2026-08-28 21:37:04 UTC
Passkeys will be added in the coming weeks
swyx · 2026-08-28 23:23:11 UTC
please prioritize, i'm keen on that
majorchord · 2026-08-28 22:00:35 UTC
No offense but you might want to consider a different styling for the app/site because IMO this one screams "Claude vibe-code style".
d0mkaaa · 2026-08-28 22:13:16 UTC
Yeah I can see what you mean, but it wasn't really intentional. I mainly wanted to avoid the usual black/blue security-product look. I will probably keep the general direction but give it more of its own identity over time. Thank you for sharing your opinion!
thehamkercat · 2026-08-28 22:15:18 UTC
it _is_ vibe-coded, you can read the commit descriptions in sesame-desktop repo

I wouldn't trust any password manager or critical applications like this written after 2024

bitwarden/KeePassXC are already more than enough

Hamuko · 2026-08-28 22:19:18 UTC
It's good that vibecoded software look vibecoded, because I then immediately know not to trust that it works, not to trust that it's secure, and not to trust that the maintainer will give a shit about it in six months.
vladkens · 2026-08-28 22:03:05 UTC
Again Tauri. How then it different from Bitwarden? Desktop != Web
oscarcp · 2026-08-28 22:16:06 UTC
How does it compare to a local deploy of PSONO?
thehamkercat · 2026-08-28 22:17:17 UTC
A vibe-coded password-manager? Sure! where do i sign up?
giancarlostoro · 2026-08-28 23:27:02 UTC
I never thought about wanting an HN comment as a wearable shirt before, but this ones one I would buy. But seriously, I love Claude and building all sorts of projects, but something as crucial as a password manager is a little bit too risky.
danielmartins · 2026-08-28 22:26:30 UTC
I still don’t get why password managers builders think it’s a great idea to store MFA token together with the password, totally defeating the purpose of MFA in the first place.
epihelix · 2026-08-28 22:54:55 UTC
I use this for MFA that's forced upon me, rather than MFA I request and want.

(It still protects against a password leak, though, so doesn't entirely defeat the purpose of MFA.)

mirzap · 2026-08-28 23:03:31 UTC
Not really. MFA still protects against the much more common case where the password itself is compromised, either through a breach, reuse, phishing, interception, bad storage, etc. An MFA code is short-lived and can’t simply be reused later, unlike a password.

Keeping the password and MFA secret in the same password manager reduces separation (if someone fully compromises your vault, they will gain access to both factors). But that doesn’t make MFA pointless; it just means it doesn’t protect you against that particular failure mode.

And if someone has full access to your password manager, you already have a much bigger problem.

Aachen · 2026-08-28 23:26:32 UTC
I loosely monitor new password managers that appear with surprising regularity on F-Droid. Most have security issues that can be trivially found. It's conceptually simple software (running strings through a function before writing it to disk): nice for learning a new language, but should everyone's practice implementation seriously land in stores? So I'm skeptical of any new ones appearing from scratch, praising all their features and slick UI, with no mention of what was wrong with the incredibly diverse set of existing password manager projects. A study I read a few months ago showed that old code has fewer bugs than new code, which seems intuitive but it's nice to have actual data on it as well

Why a whole new project that needs to re-learn the gotchas that the predecessors ran into? Could any grievances have been pull requests or, worst case, a fork?

lrvick · 2026-08-28 23:32:19 UTC
So you decrypt -any- password on a system with malware, and malware gets -all- the passwords. Makes life super easy for an attacker.

All they would need to do is install a wrapper for sesame that waits for the next database unlock and exfiltrates all passwords in plain text to a pastebin somewhere.

To prevent this, you need to encrypt each password to a key held in a yubikey, nitrokey, or similar with a touch policy. Now as an attacker if I want to get the users whole database of 100 passwords I must trick them to tapping a blinking smartcard or touchid 100 times. Presumably the user would notice something is wrong, and stop. Damage control.

This is how I have been doing password management for over a decade with password store, the standard unix password manager. That tiny shell script is the -minimum- security any password manager must have.

I get that most major password managers like 1password and lastpass also get this wrong. I submit with a straight face that they have never let any capable security engineers near their products. They have a negligent design end to end and must not be replicated.

Aachen · 2026-08-28 23:38:20 UTC
Isn't this a fundamental issue with all popular password managers? Your setup where each decrypt requires a physical action is superior of course (even if an attacker is still likely to get 2-3 of the most important secrets before you start to investigate why a login isn't working), I just mean that most people don't have this and it's not a particular flaw with OP's implementation right?