Not sure what “memberships” means. In case it is “subscriptions”:
Yeah, this has started one or two years ago; the 1P app (as standalone app then) was in an incomplete state (for years already), essential functionalities were missing; those functionalities had been promised to the customers for years. Finally they arrived, but: only for subscribers of the then new subscription model (it was called “Team“ or something, at that time). Wow, great, guys, you really managed to string me along all the years just to tell me at the end „Here it is, go get a Family Subscription if you want it!”. Pretty significant slap in my face. Thanks.
OK, I’ll stop the Agilebits rant here. They are a gang of merchandising-skilled people, nothing more. I had commented this on my blog.
And, after all, the gained insight that Agilebits is not a trustworthy company has been the major motivation to look elsewhere for something more sincere. And that was a good thing.
Have you commented anywhere in more detail about MacPass vs 1Password for less tech savvy users? Would be great to have your view.
No, I have not commented anything about that anywhere.
What is “less tech savvy users”? You are posting on the KM forum, so maybe I can assume that you are able to build a basic KM macro, and that you understand what you are building. For example a simple GUI macro that checks for a window title and clicks a particular button if that window is on screen.
If you can do that, then no problem at all with MacPass.
Applications like LastPass or 1Password try to integrate the “password entering experience” seamlessly with your browsing experience. And they do a good job there. (At least from a usability perspective.)
MacPass (or similar programs, like KeePassXC) are not focussing on that aspect.
The basic mechanism of MacPass (or KeePassXC) is:
- There is the kdbx database that holds the data (passwords, logins, etc.). It’s you who provide the data to that database (not a web browser or such).
- There is or there is not an association between a record of that database with — for example a web page.
- If things go well, those associations will be created automatically.
If things are ambiguous you’ll have to held a hand, you’ll have to help the program. Sounds like stone age, no?
No. The advantage of that concept is that there is no vulnerable connection between the database and your browser. No Javascript, no Proxies, simple as that.
The main connection between MacPass and the browser (or other apps!) is the so-called Autotype.
The Autotype is a shortcut (by default ⌃⌥M) and basically it is like a little Keyboard Maestro macro: It takes the entries from the database (name and password), checks if there is any window with a corresponding name open, and if Yes, it types the credentials into the fields.
It is obvious that this can fail: Page title does not match, URL is not parsable in a meaningful way, etc. So, with MacPass you must be prepared to lean it a hand:
For example, you notice that a password does not get filled in -> why -> find it out -> maybe the page title is not-unique, or it has changed since the last time, etc., -> but no major problem, since you can adjust all that.
You see, MacPass is not maintenance-free.
But, a side effect of this “very unsophisticated way to transfer data” is that MacPass also works with logins of arbitrary programs, or even System logins. (Outside of any web browser.)
In other words: It can also fill-in credentials in app logins, system logins or other non-web-releted instances. (1Password or LastPass will not do this and they never will.)
Well, I’m using MacPass not as my “only solution”. And I think this is the key to using it satisfactorily:
I dare to say that 95% of my passwords are trivial. They are mostly logins to some web sites, forums, like this one, and whatnot. If one of those passwords is compromised, this is not a problem.
(Of course, as long as you don’t use the same password for each and every site; but that’s the whole point of password managers).
So, what I’m doing is this;
I have all my credentials in my kdbx database. This database is backed-up and synced in multiple ways, it’s the base of all.
But, I have 95% of my credentials also in my iCloud keychain: Forum logins and all the stuff that is not related to my credit card or to other sensitive things. Things that are exclusively in my kdbx database (and not in the iCloud keychain) are my bank access data, logins to shops that have access to my card (Amazon, …), and some other sensitive stuff.
So, you may say, you are not really using MacPass if you’re only using it for 5% of your stuff!
Right, exactly. Using MacPass for each and every forum login would be tedious and overkill. We do have Safari’s excellent Password Management for this.
(That being said, be careful: Apple is putting pretty much effort in security, and also their marketing is emphasizing the same; so I have (some) reasons to trust them. But with other things like Firefox, Opera the story may be a different one. Not to speak about Google Chrome and similar stuff…)
So, let’s say (as “tl;dr”):
- Use Safari for your trivial every-day credentials
- Use MacPass (or any other secure database) for the really sensitive stuff
This way you get both: convenience and security. And both for free, “free” as in “beer”. It requires a bit more of attention than using only LastPass or 1P, but — it’s your data.
A couple other things to think of:
- kdbx (the format MacPass, but also KeePassXC is relying on) is an established database format, with security on first priority, and it will be hard to gag this. (Honestly, I think, companies like Agilebits or LastPass are already gag-ordered for many years; but that’s just my personal opinion)
- With that format you are not bound to a specific platform (macOS, for instance). It exists on Linux and also on Windows for many years.)