Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

usesesame.app

Post reply on HN
Print view View original

51–60 of 86 posts

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

#51

Post by Marsymars »

lrvick wrote: post #42
Marsymars wrote: post #37

Earlier quoted context omitted.

> 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?

Every modern device under the sun ships with a hardware security module of some kind which could, if nothing else, rate limit decryptions and ensure decryptions can only happen on that machine. There are so so many hardware anchors free for the taking. The same hardware Microsoft, Google, and Apple use to verify you are running a "genuine" OS these days can also do general purpose encryption and decryption with rate…

Sure, what does "the Secure Enclave or TPM could theoretically do this" do for me, if I've got a a trio of desktop PCs running macOS/Linux/Windows with no Touch ID between any of them and I want to keep my passwords synced and reasonably accessible?

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

#52

Post by VladVladikoff »

d0mkaaa wrote: post #11
konaraddi wrote: post #6

Does it purge passwords from memory on vault lock?

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,…

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

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

#54

Post by lrvick »

what wrote: post #46
lrvick wrote: post #39

Earlier quoted context omitted.

It 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 yo…

You can’t have a good UX with this setup, which is why none of the major password mangers do it.

Of course you can.

Random non technical executive goes to a login page, and a popup happens on an external device like a phone or keychain dongle, watch, or any secondary display that asks "Allow aws.amazon.com root access to open browser tab on laptop xyz?" and if the page you are on right now says "doordash.com" and you did not ask to decrypt aws root credentials, then you say "nope, that does not seem right" and the attack is stopped cold.

The first mistake was letting non technical executive have aws root access in the first place, but the password manager only releasing a single credential at a time with a physical button press on a trusted screen can still be a last line of defense for our most sensitive credentials.

Being user friendly and being able to have any defense at all against malware are not mutually exclusive.

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

#55

Post by gregglain »

d0mkaaa wrote: post #5
gregable wrote: post #4

How does it compare to KeePassXC?

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…

Curious what was the use case that drove the creation?

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

#56

Post by cure_42 »

willangelo wrote: post #36
Aachen wrote: post #29

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…

Side note: have you experimented with different ones? Do you recommend any in particular?

https://www.privacyguides.org/en/passwords/

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

#57

Post by jason_oster »

Aachen wrote: post #29

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…

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

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

#58

Post by cure_42 »

Marsymars wrote: post #51
lrvick wrote: post #42

Earlier quoted context omitted.

Every modern device under the sun ships with a hardware security module of some kind which could, if nothing else, rate limit decryptions and ensure decryptions can only happen on that machine. There are so so many hardware anchors free for the taking. The same hardware Microsoft, Google, and Apple use to verify you are running a "genuine" OS these days can also do general purpose encryption and decryption with rate…

Sure, what does "the Secure Enclave or TPM could theoretically do this" do for me, if I've got a a trio of desktop PCs running macOS/Linux/Windows with no Touch ID between any of them and I want to keep my passwords synced and reasonably accessible?

You use a yubikey? Duh?

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

#59

Post by lrvick »

Marsymars wrote: post #51
lrvick wrote: post #42

Earlier quoted context omitted.

Every modern device under the sun ships with a hardware security module of some kind which could, if nothing else, rate limit decryptions and ensure decryptions can only happen on that machine. There are so so many hardware anchors free for the taking. The same hardware Microsoft, Google, and Apple use to verify you are running a "genuine" OS these days can also do general purpose encryption and decryption with rate…

Sure, what does "the Secure Enclave or TPM could theoretically do this" do for me, if I've got a a trio of desktop PCs running macOS/Linux/Windows with no Touch ID between any of them and I want to keep my passwords synced and reasonably accessible?

The most user friendly way for someone with only one device and no external trusted screens is with the help of a recovery enclave all your secrets are encrypted to.

Whenever you add a new secret, you have it encrypt a copy to ideally a smartcard on your keychain and as a hail mary to each of a quorum of of keys held by secure enclaves that run an open source remotely attestable VM using TDX or SEV-SNP for provably encrypted memory, proof it is not logging, etc. You can also shamir-split encrypt to m-of-n geodistributed key shares stored offline as a double hail mary. All of this would be automatic and transparent to the user.

When you add a new device you must approve from an existing device.

That cryptographic approval, ideally a passkey tap, can start a process to bulk decrypt passwords and re-encrypt them to the TPM key in the new device in a hosted remotely attestable secure enclave the device verifies. The user can be given a chance to cancel this transfer within a reasonable period of time like 48 hours. This extra time could be bypassed if a user has a second device attached to their account. A user could also release one credential at a time manually and explicitly on both devices following the usual rate limit rules etc, or bypass the limit if both devices can be directly connected, or use an offline recovery yubikey or last resort offline bootable recovery usb for expedited recovery as well, etc. Good to have multiple fallback recovery methods that tolerate at least one machine being compromised at all times.

This is just one example scheme. There are many many ways to solve this in a way users are protected without them having to learn to do anything more complicated than account recovery on any web service ever.

I really hope someone rips this off and runs with it. My team and I have open sourced everything required, as have many other teams.

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

#60

Post by valenterry »

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.

Post reply on HN