diff --git a/slip-0016.md b/slip-0016.md index 6c5cb25e3..5a98ec54e 100644 --- a/slip-0016.md +++ b/slip-0016.md @@ -156,3 +156,42 @@ true) // askOnDecrypt? we want this becuase otherwise somebody could rob us! 2. Other steps are the same as in entry encryption, we just symetrically decrypt values of `password` and `safe_note` via `AES-256-GCM` algorithm. Size of IV and authTag for AES is the same as in encryption. Beware on cipher Key data type - it must be hex. Output is in JSON. Check example of password reader implementation in python [pwdreader.py](slip-0016/pwdreader.py) there is an example code for decryption. + + +### V2.0.0 format - discussion/suggestions + +The following proposed changes will make the password manager usable in `offline mode` (for accessing non-online services like credit card's PIN or a safebox's combination) and sync the passwords with different services such as FTP, owncloud,... + +Imagine that we agreed on allowing `"offline access"` to the passwords (you could store the file in the SD card slot of TREZOR v2 or the storage on a mobile device), it comes with a problem on how to sync the entries, you could made some changes offline and when you try to sync, discover that the remote has changed too. In this case, we could offer the user some solutions: +1. Ask the user which file to use, and which to discard (completely). Pros: easiest to the user. Cons: We might lose data. +2. `Merge` the files, going entry by entry, if username+item match ask the user which entry to keep +3. `Merge` the files, going entry by entry, if username+item match, decrypt both password and check them too, ask the user which entry to keep. + +For 2 and 3 we do not match the title, as it might be different (github vs github.com) but item and username should be equal. For solution 1, we should add a `mod_date` (timestamp of last modification) field to the file's configuration. For 2 and 3, we should add it to each entry. I think the better solution for the user is 2, complete enough without being too annoying. User will be presented a choice "Those two entries looks similar [Entry A - date 1] and [Entry B - date 2], what would you like to do? Keep them both - Keep A - Keep B". + +Another suggestion is to add the `services` field to the main file, or maybe inside `config`. The purpose of this field is to hold information of servers and services that will allow the user to store their data. Dropbox or drive do not require that kind of field, but someone may be interested in syncing their data with their own FTP server, an owncloud server or even store it as a draft on a mail server. Not every application should or would be compatible with every `service`. Chrome extension may be only allow dropbox integration, but more advanced users who want to set up some other services could use other applications. User could set up one or more services at the same time, and be able to sync with them at wish. Services should contain at least a `title` to identify them (ie: "Personal FTP", "OwnCloud server",...)and a `type` (ie: "ftp", "owncloud", ...) among other fields that are "type-specific" (server, port, username,...) and also encrypt some information if needed (password). We could use the message: `'Sync data with ' + title + '?'` for encryption/decryption purposes. + +Application specific configuration should be also be under their own section under `config`, or maybe under `config.apps`. For example: + ``` + ... + config: { + chrome-extension: { + copy_clipboard:disabled, + ... + }, + mobile: { + offline: false, + autologin: true, + ... + }, + desktop: { + fullscreen: true, + ... + }, + } + ... + ``` + +Lastly, we need to made some changes, as right now the `title` is being used as `item`, and `note` as `title`, we should add a new field to entry's format `item` or `URI`, which will be the URI for the online service (ie: http://www.github.com), `title` would be the title of the site (ie: Github) and note would be a short text (ie: Do not deploy code on Friday's afternoon). While I'm not sure how many people will use the `note` field since there's already a `safe_note` one, it might be useful in some cases to specify more information about the entry without decrypting it. + +To upgrade, the application will detect an old format file and ask the user to upgrade to a new one (explaining the risks maybe?). It will decrypt the file, re-arrange the fields (title, item, note) and save it, no need to decrypt each entry in this change. Old file could be saved too under a different name (xxxxx.pswd_bck ??) in case something went wrong. \ No newline at end of file