Seven years ago I created a password manager. And a few days ago I pushed out the last release for it, notifying users that nothing else will come now. Yes, with the previous release being from 2019, this might have been obvious. Now it’s official however, PfP: Pain-free Passwords is no longer being developed.
I certainly learned a lot from this adventure, and I really like the product which came out of this. Unfortunately, a password manager is a rather time-consuming hobby, and my focus has been elsewhere for a while already.
This doesn’t mean that PfP is going away. In fact, it will probably work well for quite a while until a browser change or something like that makes it unusable. Sync functionality in particular depends on third parties however, and this one already started falling apart.
Contents
Lessons learned
Back when I started this project, originally called EasyPasswords, I was still a cryptography newbie. So it’s not surprising that I made a bunch of questionable choices.
The first mistake was the choice of key derivation algorithm. PBKDF2 had the advantage of being supported natively by the browsers via the Web Crypto API, but otherwise it’s not a recommended choice.
The second mistake was focusing on password generation as protection mechanism and neglecting encryption. Encryption would only be used for the occasional stored password, while all the metadata stayed unencrypted.
As I said, I was new to cryptography. Not that there aren’t “industry leaders” who made the exact same mistakes.
By 2018 I’ve addressed both issues with PfP 2.0 however. Encrypting all the data allowed implementing secure sync functionality without relying on trusted storage. No, this isn’t merely uploading an encrypted blob to some cloud storage, PfP sync is rather capable of merging concurrent changes from different PfP instances. Solving this was quite challenging, given that passwords can be locked during sync, in which case PfP won’t be able to decrypt its data.
At the current point I am still aware of two issues with the PfP design. One is the scrypt key derivation parameters being not quite optimal. The reason here is that I wanted for it to be usable on mobile devices, even though a mobile version of PfP never materialized.
As I pointed out myself not too long ago, you compensate suboptimal key derivation by choosing a stronger password. PfP doesn’t offer sufficient guidance here however, and that’s the second issue. There is a password strength indicator based on zxcvbn-ts, but it won’t necessarily flag weak passwords.
The crux with password generators
PfP has been conceived as a password generator, a choice that looked very clever to me back in the day but seems rather questionable today. Yes, if passwords are being generated deterministically from website and user name, storing the password in the database is no longer necessary. But what difference does it make if all data is encrypted anyway?
In the end, the advantage of password generators is mostly password recovery. PfP allows creating secure paper backups which can be used to recover any password trivially as long as you still remember your master password. But even without the paper, remembering the generation parameters of a password (website and user name, optionally also a revision number and character sets used) is usually possible.
This advantage melted away partially when I designed a (somewhat less convenient) way for paper backups of stored passwords. And a paper backup for hundreds of passwords turned out simply impractical. In the end, what you need is a backup for a few most important passwords. And the rest of them will hopefully be recoverable via sync.
For the meager advantages, password generators have very clear disadvantages. The obvious one is complexity. While storing a password in the database is an intuitively understandable concept, setting up password generation parameters requires some explaining. And you cannot go away with stored passwords completely, so there will always be this “which one to choose?”
More importantly however, there is an attack scenario affecting only password generators but not conventional password managers. If you register at a website which is later compromised, your password for that website could be used to try guessing your master password. In case of success, this attack would compromise your passwords for other websites.
I’ve recognized this threat early on and mitigated it with a slow key derivation algorithm. Yet mitigating this attack scenario will always be worse than not having it at all.
The reason for giving up
None of the issues are unsurmountable, and the security concerns don’t even matter for a small niche solution like PfP. They are not the reason I am giving up on the project.
In fact, I had plenty of ideas for it. I created an almost complete command-line version of PfP, written in Rust. The idea was that in future this well-tested library would be compiled into WebAssembly and used in the browser extensions as well.
There were also well thought-out ideas for user interface improvements, an Android app, password sharing. I merely lacked the time and the focus to finish any of it.
And thinking about it, I had to admit that things won’t change any more. As much as I like this product, I wouldn’t be able to maintain it any more. There is always something that’s more important.
Where to go from here
Obviously, anyone is free to continue using PfP as they like. The fact that the extension isn’t being developed doesn’t mean that it won’t work. It already did pretty well without any changes in the past three years.
Unless Chrome decides to enforce Manifest V3 at some point. They’ve moved the deadline for that a few times already, and I can see why: the move from background pages to background workers was a very non-trivial one, and there are still critical implementation issues. But at some point Manifest V3 will likely become mandatory for extensions.
Well, I’ve done the work migrating PfP to Manifest V3. It lives on a branch, and I decided against releasing it at this point given the sad state of Chrome’s implementation. Hopefully, I’ll find time to release it once Chrome developers have done their homework. This should make sure that everyone can continue using PfP for quite some time.
For anyone looking to migrate to a different password manager, I’ve added a way to save passwords as a generic CSV file. It should be possible to import this file into any password manager.
Personally, I will try to make KeePassXC work for me. While it does not meet some of my design goals for PfP, its open nature should make it possible to add whatever functionality I need. Maybe some of it can make it into the KeePassXC product, but external tools can work with the passwords database just as well.
Comments
Excuse my partial off-topic: while we're at your software, what happened to Google Search Link Fix? I actually found this website trying to find some sort of announcement concerning it, but it looks like there hasn't been any.
It has been discontinued a few years ago already. No, I don’t think there was an announcement.
As one of the people who'd been using EP/PfP for multiple years: Thank you for this project!
EP was my first password manager, from there I made the switch to PfP. And then I did switch to Bitwarden two years ago, for various reasons.
UX-wise, PfP was quite a bit ahead of Bitwarden in many ways. The whole workflow of "I am creating a new account and I need a password manager entry to be created along with it" is so much easier in PfP. Generating the entry and the password in a single step is pretty much unbeatable. With Bitwarden, I forget clicking the final Save button every so often and lose the in-progress entry.
Then Bitwarden has a whole host of additional complexity ... some of which is appreciated, much of which I barely use. PfP also was a great intro to password managers because so many of its details were so well thought-out, e.g. URL matching. Bitwarden gives the full power of regexes there, but with PfP, I never much needed that. The default settings were so good that most rationally-built websites worked out-of-the-box.
Getting to see the encrypted, synced, JSON file in Dropbox (or with the export feature) was also cool, given how most managers (except Keepass derivatives) hate to give you the passwords file in an easy-to-backup way.
So, a belated thank-you for the project!