6 ms·
Show HN: Sesame - a local-first, open-source password manager
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.)
- riverbirch 1mo ago[flagged]
- ramon156 1mo agohow 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 1mo agovaultwarden + 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 1mo agobitwarden clients are open source, so it would be possible to fork them if bitwarden ever makes user unfriendly decisions
- gregable 1mo agoHow does it compare to KeePassXC?
- d0mkaaa 1mo agoKeePassXC 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 1mo agoWhat do you mean by a "consumer style experience"?
- NewsaHackO 1mo agosubscription 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.
- gregglain 1mo agoCurious what was the use case that drove the creation?
- konaraddi 1mo agoDoes it purge passwords from memory on vault lock?
- deleted 1mo ago[deleted]
- d0mkaaa 1mo agoYes. 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 ))
- VladVladikoff 1mo agoThis response feels very AI generated. Which does not bode well for my faith in this project if the maintainer doesn’t even know basic facts about how it works and has to ask his AI.
- arlattimore 1mo agoI 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 1mo agoI 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 1mo ago>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 1mo agoI don't see the support for passkeys listed anywhere?
- majorchord 1mo agoNo offense but you might want to consider a different styling for the app/site because IMO this one screams "Claude vibe-code style".
- d0mkaaa 1mo agoYeah 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 1mo agoit _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 1mo agoIt'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 1mo agoAgain Tauri. How then it different from Bitwarden? Desktop != Web
- d0mkaaa 1mo ago[dead]
- oscarcp 1mo agoHow does it compare to a local deploy of PSONO?
- thehamkercat 1mo agoA vibe-coded password-manager? Sure! where do i sign up?
- giancarlostoro 1mo agoI 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.
- written-beyond 1mo agoI don't have an issue with a vibe coded password manager, LLMs are insanely good. The issue, atleast to me, is the UI is extremely low effort LLM slop. I'd have appreciated something native that was super fast.
- Greenpants 1mo agoReminds me of letting an LLM generate a strong password in the first place. Very practical, very quick, no terminal commands needed! I'm sure some have done exactly this. But then you realise your password is always shared with your LLM provider, and it's not so random after all (unless it used tools).
- d3Xt3r 1mo agoIt'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?!
- danielmartins 1mo agoI 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 1mo agoI 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 1mo agoNot 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.
- jscd 1mo agoAs 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.
- Marsymars 1mo agoDepends 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.
- Aachen 1mo agoI 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?
- willangelo 1mo agoSide note: have you experimented with different ones? Do you recommend any in particular?
- cure_42 1mo agohttps://www.privacyguides.org/en/passwords/ https://www.privacyguides.org/en/passwords/
- Aachen 1mo agoPrivacyGuides (mentioned in a sibling comment) usually has some strange logic for what makes something a good option but it's broadly useful to get some options and ideas My answer is to more generally look for what's been around, whose authors haven't turned out to be malicious (even after 10+ years of being popular enough that they'd get the motherlode with one malicious update), have had good security responses and seemingly good security practices... so basically look at the oldest thing that meets your needs and search e.g. HN and read its Wikipedia to find out about any red flags. Compare that to two runner-ups A specific feature I'd recommend is phishing-resistant browser integration, that is, autofill for the browser but it only suggests passwords that you've stored specifically for this website. If another domain asks for it, it shouldn't suggest it and that then raises alarm bells of like "did the website change domains or is someone pretending to be them?". There have been bugs in browser integrations but it's not that regular, you still need to be among the unlucky few that visit a malicious website or ad before it gets found out and fixed, and my professional opinion is that it's easily worth it (our company helps with custom/targeted phishing simulations) - just like the having of a password manager (single point of failure for (nearly) all your credentials) is a tradeoff in the first place that seems to generally pay off. Perhaps memorise a few strong passwords though, like for bank/broker login and such things that would be truly disastrous and also likely that someone has a use for the thing they hack (they're not going to care about your nudes nearly as much as when they can drain hard cash)
- lrvick 1mo agoSo 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 1mo agoIsn'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?
- lrvick 1mo agoIt is a negligent and blatant design flaw in all popular implementations, yes. Mooltipass and Password Store are the only two password managers to do the bare minimum. That is ridiculous. Anyone who corrects this, with a good UX solution, will win the password manager wars. It is so so so easy to do, so it is unthinkable only the CLI password manager written in bash bothers to do it. Ask an LLM to implement it for you if you must, but no one has any excuse to skip the most basic security function of a password manager: do anything at all to protect it from malware. The bar for password managers is in hell.
- demibabs 1mo agoIf you’re going to vibecode a site, at least write the copy yourself. AI text is exhausting to read.
- globalnode 1mo agoive 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.
- 2legit2quit 1mo agoThis sounds an awful lot like PasswordSafe[0] in a different dress. Does it provide any features that set it apart? 0 - https://www.pwsafe.org/relatedprojects.shtml https://www.pwsafe.org/relatedprojects.shtml
- senectus1 1mo agoyou got to pay 10 euro a year to self host?
- valenterry 1mo agoI 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.
- Marsymars 1mo agoI 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.
- valenterry 1mo agoRight. That's why I think that the client syncing (all) credentials is just what I don't want/like and there must be a server, since a compromised client can obviously not be trusted to doing any rate-limiting. And the server also needs to inform about usages, since otherwise a compromised client could just extract everything slowly over time. Does that make sense? Otherwise, basically just one compromised client means that suddenly all my credentials need to be considered stolen and have to be changed everywhere.
- pregnenolone 1mo agoWebView...
- cobrabts 1mo ago[dead]
- lofaszvanitt 1mo agoWhen will we read an article about how to pwn pw-managers. How to hook clipboard and the like and steal everything inside.
- jamiebuildsfree 1mo ago[flagged]
- heliskyr2 1mo ago[flagged]
- papacoder101 29d ago[flagged]