Proposal: add mpsites file

[stesix]

Saving some key information about how the password is generated would help a lot. In my daily use, I'm never sure (and I don't want to remember) what's the counter I used for a password, what's the template I used the first time to generate the password, etc.

In mpw, I can simply execute once

mpw -tx mysample.com
# provide the pass

and from now on I'll just need to type mpw mysample.com to get the right password.
If I need to update my password, I'll change the counter by executing:
mpw -c 150 mysample.com. Again as before, since all the data is stored in the ~/.mpw.d/${MPW_FULLNAME}.mpsites.json, I don't need to get nuts in remembering what were the specifics for mysample.com

Another reason for doing this is to keep the back compatibility with mpw.

The new mpsites file (which IMO should be called mpxsites) shouldn't be a simple flat file containing all the data used but a zipped and encrypted db as it happens in keepassx.

[Cretezy]

I had lots of request for something like this.

My issue is one of the design choices for MasterPassX is that it is fully stateless. There's no syncing ever required except the initial setup. This made it much simpler overall design-wise, but made is so site options must be remembered.

This might be controversial but I am currently working on a secondary version of MasterPassX ("Pro") which is not fully "stateless", but has a back-end where it stores salts of sites, and stores options. This will probably be a paid (but cheap) service.

However, I am not opposed to having an open source version of the Pro that stores options like this (and salts), where people can self-host, and have a paid fully managed one (the "pro" version).

[stesix]

I don't want to be "that guy" but IMHO if you want to see MasterPassX growing, it should cover all the functionalities offered by MasterPassword and add some new ones. Consider that most users would come first from the old version of MasterPassword (and then it might spread around by word).

IMO the new functionalities should be "paranoid friendly" like: 2FA, encrypted mpsites, new encrypting algorithms, the possibility to choose my very own special hashing algorithm. In the end most of the users interested in this kind of product are generally paranoid (otherwise they'd use lastpass and be done with it).

[Cretezy]

1. MasterPassword doesn't provide store site options on the web version. I agree that storing site options is important but hassle-free syncing also is important.
2. 2FA isn't really possible since it's all client-side, there's not much ways to auth using say a TOTP since there's nothing that can be derived from it to generate the master key. I'd love to find a way to implement this. This is where the "Pro"/stateful version will shine, because it allows things like email/2FA auth and encrypted syncing. The problem with having a third-party syncing service is the paranoia, even though everything can be synced, it'll still be stored somewhere. The solution would be to allow users to run their own syncing servers.

What do you think about this:

Having a free tier for the Pro version (probably will have a name change from "Pro" though), that syncs encrypted data. This would be a free service with email/2FA and all those goodies.

I would have a paid tier to support the service with some addition features, but that are fully optional and not related to the core version. I've yet to think of anything for this, although password sharing might be a good idea (for instance having a "family" plan where they can share passwords for Netflix). There would also be a enterprise plan for companies looking to have bulk plans and support, but companies will also be able to self-host using the free self-hosted version (see below), but can also have support plans to support the main service.

Anyone will be able to self-host too. I'm basing this around the GitLab approach, where it's free for users but they can pay for a "premium version" with some addition features but are optional to the core product. Anyone can host, but companies can use the fully-managed one or self-host for free or with support plan.

And I would have a "classic" edition which would be the current MasterPassX, which is fully stateless, trustless, and client-side.

I think this model would make every happy. The goal is not to make money but simply to support the project as a whole with users that are willing to pay.

[stesix]

Yep, clearly the 2FA was a very poor example :). I should have thought better about it while I was writing.

When writing these proposals, I should always specify that I'm referring to CLI since rarely I ever used the web version on mpw and mpx. Specifically adding the mpsites will benefit CLI, desktop, ios/android versions of mpx. For obvious reasons it makes very little sense to store these info for the web edition.

About the paid service... TBH I started developing a similar project (with a similar approach you're proposing) before getting here, then I simply decided to tag along and see where it was going.

[Cretezy]

I'm not very familiar with the CLI of mpw. Do they have mpsites?

This new service would be a fully rebrand and would be incombatible with the MasterPassword algorithm but would be better in general for the users in my opinion.

If the CLI of mpw does have mpsites, is their any syncing? Or is that assumed to be managed by the user? I'm aware that MasterPassword does encrypt something... I just don't know what. If they do use mpsites, I think it would make senses to add config option to allow the use of mpsites, and make it compatible with the original MasterPassword mpsites. The user would need to activate it manually though when setting up the user with a flag like -use-sites/-u, which would set the "useSitesFile" in the config with either true or a path to it (which would be prompted).

[stesix]

they've got the mpsites and they're not syncing (this was the main reason of my little project). My concern with mpsites is that it's clear. Even if I there are no hints of passwords, it's pretty clear that it's only needed the right master password to actually gain the whole db. It's quite a scary thought.

IMO mpx should give the possibility to import the current mpsites but it should be able to also encrypt it's own site file (maybe mpxsite?). I'd push for a solution similar to keepassx: the master password decrypt (in memory) the mpxsite file and allow the usage of it's content to generate the new passwords.