Structured, uniform mpsites format.

[lhunath]

Hi Maarten,

There are several implementations of your algorithm now (my self maintaining chrome and firefox addons). Are you interested in discussing a new format for the .mpsites file?

I think it's of high value that the different implementations can exchange configuration. At the same time, I'm looking for a way to save/backup application specific settings without using an extra or incompatible file.

In particular, as the browser plugin matches a size+counter+sitename entry with a url (regexp), I would like to be able to store that regexp. Further there are a couple of global + site specific settings like "auto-submit form (override)", auto insert username etc.

For bonus points, we could maintain a wiki with the definition of each field to avoid aliasing stuff.

json, yaml, xml whatever..

Cheers, Torbjørn

[dkunzler]

@lhunath What do you think about the suggestion of @sscherfke that he made a few months ago?
https://gist.github.com/sscherfke/fe58bb5bcc3e5028b9199902bf895d7e
If I remember correctly he also sent you this.
@ttyridal Please also have a look at this.

But the biggest problems stays, namely the synchronization itself. A file format does not make a synchronization...

[lhunath]

So, I think I'm going to implement something like this format. Feel free to provide any suggestions and feedback.

Note that export files are user-specific. They are not full app-data-dumps.

Dates are in UTC, RFC-3339 format, yyyy'-'MM'-'dd'T'HH':'mm':'ss'Z'.
There are three sections:

• export: metadata on the export file and format.
• user: data on the user for whom an export is made.
• sites: data for each of the user's sites.

Each object has a few standardized properties, they are all described in the format below. Then it permits application-specific extensions. Extensions should always be keyed with the _ext_ prefix. The _ext_mpw key is reserved for the official Master Password apps.

The example below shows a few other potential extensions which are just random ideas and not specific to the format.

If .export.redacted is true, then the file MUST NOT contain any clear-text secrets. For sites with generated passwords, the .sites.password and the .sites.questions.answer keys MUST be null or missing. For sites with stored passwords, the password MUST be BASE64(AES128-CBC(master-key, site-password)).

{
    "export": {
        "format": 1,
        "date": "2017-06-24T18:45:17Z",
        "redacted": false,

        "_ext_signature_gpg": "iQEcBAEBCAAGBQJZTtteAAoJEDwVr2CJHly5bLEIALWCnxVn299i9ogp9uDEmmzO+6u8YAXcSpqUIWd/EnOL8hofiaSvYQh1Vxx7Xxrjhg6sWDzeHrUeQqRi23FX14P7bmBXfRjhqfEDSHH56mMQ9zqCFytxmtRN8VidCFIdHhnYGYssncR24m5VQiCyezMDVG1QrgSOfoZP5StAF3EdqqQnFBZlhPskAEE20WaqyLGuBT+yjADEWpPoZmnRLPvHAKx+BpDNSmXP/+NtCpCfUVD9hi4+F7qxNKq62lrmuN/IzRK8+JFd80q/QXXhNKot5J7h9trI50Yoh6p0xVef4pe/p2yf/nyyeL79qTCh3YvbMGSZqJt2YJPT0RNu9hk==fHAD",
        "_ext_sync_git": {
            "origin": "...",
            "commit": "...",
            "path": "..."
        }
    },

    "user": {
        "avatar": 4,
        "full_name": "Robert Lee Mitchell",
	"last_used": "2017-06-24T18:45:17Z",
        "key_id": "a636f54415916d6a0a3f5dd9c2b9cfe94388616df31509f0d40209846a6d112a",

        "algorithm": 3,
        "default_type": 17,

        "_ext_mpw": {
            "save_key": true,
            "touch_id": true
        }
    },

    "sites": {
        "twitter.com": {
	    "type": 17,
            "counter": 1,
            "algorithm": 3,
            "password": "VemfYuquPosi7,",

            "login_name": "rmitchell",
            "login_generated": false,

            "uses": 7,
            "last_used": "2017-06-24T18:45:17Z",

            "questions": {
                "": {
                    "answer": "veyy jap suxnuya ruh"
                },
                "mother": {
                    "answer": "lin wetwibuja mano"
                }
            },

            "_ext_mpw": {
                "url": "https://twitter.com"
            }
        }
    }
}

[adamczykm]

I thought the whole point of MP not to store passwords. What's about that?

…

On Sat, Jun 24, 2017, 23:57 Maarten Billemont ***@***.***> wrote: So, I think I'm going to implement something like this format. Feel free to provide any suggestions and feedback. Dates are in UTC, RFC-3339 format, yyyy'-'MM'-'dd'T'HH':'mm':'ss'Z'. There are three sections: - export: metadata on the export file and format. - user: data on the user for whom an export is made. - sites: data for each of the user's sites. Each object has a few standardized properties, they are all described in the format below. Then it permits application-specific extensions. Extensions should always be keyed with the _ext_ prefix. The _ext_mpw key is reserved for the official Master Password apps. The example below shows a few other potential extensions which are just random ideas and not specific to the format. If .export.redacted is true, then the file MUST NOT contain any clear-text secrets. For sites with generated passwords, the .sites.password and the .sites.questions.answer keys MUST be null or missing. For sites with stored passwords, the password MUST be BASE64(AES128-CBC(master-key, site-password)). { "export": { "format": 1, "date": "2017-06-24T18:45:17Z", "redacted": false, "_ext_signature_gpg": "iQEcBAEBCAAGBQJZTtteAAoJEDwVr2CJHly5bLEIALWCnxVn299i9ogp9uDEmmzO+6u8YAXcSpqUIWd/EnOL8hofiaSvYQh1Vxx7Xxrjhg6sWDzeHrUeQqRi23FX14P7bmBXfRjhqfEDSHH56mMQ9zqCFytxmtRN8VidCFIdHhnYGYssncR24m5VQiCyezMDVG1QrgSOfoZP5StAF3EdqqQnFBZlhPskAEE20WaqyLGuBT+yjADEWpPoZmnRLPvHAKx+BpDNSmXP/+NtCpCfUVD9hi4+F7qxNKq62lrmuN/IzRK8+JFd80q/QXXhNKot5J7h9trI50Yoh6p0xVef4pe/p2yf/nyyeL79qTCh3YvbMGSZqJt2YJPT0RNu9hk==fHAD", "_ext_sync_git": { "endpoint": "...", "commit": "...", "path": "..." } }, "user": { "avatar": 4, "full_name": "Robert Lee Mitchell", "last_used": "2017-06-24T18:45:17Z", "key_id": "a636f54415916d6a0a3f5dd9c2b9cfe94388616df31509f0d40209846a6d112a", "algorithm": 3, "default_type": 17, "_ext_mpw": { "save_key": true, "touch_id": true } }, "sites": { "twitter.com": { "type": 17, "counter": 1, "algorithm": 3, "password": "VemfYuquPosi7,", "login_name": "rmitchell", "login_generated": false, "uses": 7, "last_used": "2017-06-24T18:45:17Z", "questions": { "": { "answer": "veyy jap suxnuya ruh" }, "mother": { "answer": "lin wetwibuja mano" } }, "_ext_mpw": { "url": "https://twitter.com" } } } } — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#164 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEx_csW1-6oNP1aQvqqccbYOCagZS3B2ks5sHYZQgaJpZM4MlpHp> .

[lhunath]

I'm unsure what you're suggesting. MP's point is indeed not to store passwords. The above does not invalidate that. Can you expand on your question?

[vitiral]

@lhunath MP's point is to store passwords... but NOT in plain text. Your solution seems to store them in plain text.

From my understanding (which is limited) the file should store:

• validation of the master password using a site like __validate__ -- it will first use the master password you enter to find the password for __validate__ -- if it matches then it knows you didn't fat-finger the master password.
• which sites are being used and what "version" to use

This way you can store the text file on a site like github (or anywhere) and it won't matter if someone finds it -- they will only know which sites you have passwords for -- not what the passwords are!

[lhunath]

Please note that the above is an example of an export which is not redacted. It's the equivalent of today's export pressing the button "Show Passwords". The idea is that it should be easy for people to make a file that contains all of their passwords in a readable format. That way, the file can be used for a hard-storage, backup, that's independent of MP or to migrate away from MP should they so desire.

The STANDARD way of making an export is by doing so with the redacted format (equivalent to today's "Safe Export" button), in this format, as I already explained in my file format post above, the file does not contain any passwords and acts only as a document describing the metadata necessary to generate the user's site passwords.

MP doesn't store generated passwords, it never will. Export files are not storage. They are exports. The intent being to take things OUT of MP (ergo, export).

Per your "validate" site proposal, this function is already provided by the user's key_id property.

[adamczykm]

I see now. So the passwords are generated during export. Thanks for exhaustive answer.

…

On Sun, Jun 25, 2017, 22:32 Maarten Billemont ***@***.***> wrote: Please note that the above is an example of an export which is not redacted. It's the equivalent of today's export pressing the button "Show Passwords". The idea is that it should be easy for people to make a file that contains all of their passwords in a readable format. That way, the file can be used for a hard-storage, backup, that's independent of MP or to migrate away from MP should they so desire. The STANDARD way of making an export is by doing so with the redacted format (equivalent to today's "Safe Export" button), in this format, as I already explained in my file format post above, the file does not contain any passwords and acts only as a document describing the metadata necessary to generate the user's site passwords. MP doesn't store generated passwords, it never will. Export files are not storage. They are exports. The intent being to take things OUT of MP (ergo, export). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#164 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEx_crjfvnU_Ao3jVYjmS7vJNDTeBHJYks5sHsPCgaJpZM4MlpHp> .

[lhunath]

That is correct. And only if the user chooses to create a non-redacted export with the explicit intent of exposing them.

[adamczykm]

That's perfect.

…

On Mon, Jun 26, 2017, 00:27 Maarten Billemont ***@***.***> wrote: That is correct. And only if the user chooses to create a non-redacted export with the explicit intent of exposing them. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#164 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEx_cv4mCRAe9cqYmpPWBzEjd2DDGvkZks5sHt7NgaJpZM4MlpHp> .

[lhunath]

Done.

[ttyridal]

In this scheme, what do we do when encountering an unknown ext field on import? Ignore it? store it for later export?

F.ex If the user is trying to keep multiple implementations in sync by exporting the latest version to some central repository.

[lhunath]

https://github.com/Lyndir/MasterPassword/wiki/File-Format

[lhunath]

@ttyridal extension data should always be preserved, regardless of whether your application knows how to handle it or not, to avoid data loss. Does that answer your question?

[ttyridal]

indeed..