Comment by Aachen
2 days ago
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?
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)
https://www.privacyguides.org/en/passwords/
Can't have software bugs if you just write your passwords down on paper. /jk
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
What supply-chain attack do you suspect pwsafe of being at risk of?
Nothing in particular. In my head all that needs to happen is some form of update (dependency, core project or the Android version on my phone) and sneaks in something that reads the unencrypted file and sends it over the internet somewhere.
I wish android and windows had flat seal, as far as I can remember that can prevent all network access for a given app.
> 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.
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.
2 replies →