Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- No offense but you might want to consider a different styling for the app/site because IMO this one screams "Claude vibe-code style".by majorchord
- 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!by d0mkaaa
- 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
by thehamkercat - 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.by Hamuko
- ive got my own pwd file using a short shell script in bashrc that uses nano, gpg and /dev/shm to keep things in memory (hopefully). works great, is minimalist and there are no hidden surprises.by globalnode
- This sounds an awful lot like PasswordSafe[0] in a different dress. Does it provide any features that set it apart?by 2legit2quit
- 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 toby ramon156
- 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 stackby d0mkaaa
- 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.by arlattimore
- >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.
by NewsaHackO - 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)by d0mkaaa
- I wish there was a password manager with a different focus.
In the way where there would be a server (selfhosted) that has the passwords and is well protected. Then, on the server, I can configure access to the secrets on my clients and — and that is important — restrict the number of secrets that can be accessed per time. And on each client I want to be told if secrets got accessed by another client.
Because, optimally I would use passkeys and other means of authentication, except for initial auth. But if my client gets compromised I don't want it to be able to access and exfiltrate all secrets at once. That is basically the worst case scenario.
I don't understand why it's not common in password managers to have different categories of how important a secret is and better control/transparency to detect compromised clients and contain the impact.
by valenterry - I suspect that's uncommon because basically every password manager works offline so isn't querying the server on each request, and implementing something where you trust a compromised client to rate-limit itself and report back appropriately seems like a lot of work to protect against a pretty specific threat model.by Marsymars
- 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.
- 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.
by mirzap - As a second factor of authentication, a one-time passcode is supposed to be “something you have,” which is still satisfied when stored in a password manager. It no longer serves as a preventative in the event your password manager is compromised, but it’s still fine if any individual password is.by jscd
- Depends what you think the purpose of MFA is.
By and large, I see it as protection for the service provider, not for the me - they prevent the service provider from having to deal with people using weak passwords or re-using passwords that get leaked.
By-and-large, given the option, I wouldn't enable MFA - I appropriately store my strong, unique passwords, and am satisfied with that level of security.
Having MFA forced on my is purely a convenience downgrade without any real security upgrade, and having my password manager automatically fill MFA tokens minimizes that convenience downgrade.
by Marsymars - 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.)
by epihelix - How does it compare to KeePassXC?by gregable
- 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 :) )
by d0mkaaa - If you’re going to vibecode a site, at least write the copy yourself. AI text is exhausting to read.by demibabs
- A vibe-coded password-manager? Sure! where do i sign up?by thehamkercat
- 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.
- It's also half-coded in Javscript, with a grand total of 881 unique dependencies (271 npm + 614 Rust; derived from 38 directly declared dependencies). What could possibly go wrong?!by d3Xt3r
- 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.
by lrvick - It's hard to give a big enough :rolleyes: for this nihilistic bullshit being spouted in 2026. In fact I'm going to go further: I accuse you lrvick of active maliciousness and trying to aid illicit access and discourage people from improving their security, because you have no excuse not to know better.
>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.
"""All""" they need is to get root? Most people access all key stuff on their own devices, and for the vast ultra super majority of the population and vital sites if their personal trusted device is rooted it's over regardless. Your "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" is total fucking make believe, completely ignoring normal things like RECOVERY FLOWS. If you have root on someone's computer and phone you have access to their email and probably messaging as well, and that will suffice to get into nearly everything including the majority of financial institutions (which even now have massive ones that don't even support HSMs at all, let alone leave no recovery route! looking at you Charles Schwab, with total client assets in excess of $12.5 trillion at the start of this year [0]). There isn't any need for "100 times" because most people don't have 100 different critical accounts, rather single digits or even just one actual one that has things like money or comms.
>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.
Literally laughing out loud here. If it's not easy enough for my friends in their 70s to use and like it's WORTHLESS to most security. Including on some level mine or yours, because security has key social/network effects beyond just individuals, stolen money, information, and access is used to fuel further security threats. Job #1 is to make something people like and works with most of what already exists. Otherwise it's yet another case of "ROTATE PASSWORDS EVERY 2 MONTHS NO USE X NUMBERS OH ALSO Y SPECIAL CHARACTERS NO NOT LIKE THAT" which results in everyone just leaving stuff on sticky notes on their screens and doing the bare minimum to fool the system and using the same thing or minor variants everywhere. Theorycrafted garbage made for robots not humans.
>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.
I submit with a straight face you are either literally working for a hostile agency to spread disinformation or you have serious neurodivergence or you are seriously and dangerously bubbled with an (un)healthy splash of Dunning-Kruger mixed in.
----
0: https://pressroom.aboutschwab.com/press-releases/press-relea...
by xoa - > That tiny shell script is the -minimum- security any password manager must have.
So any device without touchid or a yubikey can't use a password manager without typing out your full master password every time you want to access any password?
by Marsymars - 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?by Aachen
- 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?
by Aachen - > 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
Which study? Old software has bugs that live for decades, even security bugs. I don't have a study to cite, just open bug trackers and CVE lists.
by jason_oster