Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow syncing passwords metadata across browsers/devices #24

Closed
palant opened this issue Jun 30, 2016 · 2 comments
Closed

Allow syncing passwords metadata across browsers/devices #24

palant opened this issue Jun 30, 2016 · 2 comments

Comments

@palant
Copy link
Owner

palant commented Jun 30, 2016

Currently, the only way to sync two devices is exporting the passwords metadata to a file, moving that file to the other device and importing it there. This isn't a very convenient way of doing it.

The same thing can be automated using some file sharing service, e.g. Dropbox. Only password metadata will be synced, meaning that no sensitive data gets uploaded and sync only works if master password is identical for both devices. When the user sets up sync they will have to authorize Easy Passwords with their Dropbox account (limited permissions, app-specific folder only). Easy Passwords can then check the data in its Dropbox folder regularly, e.g. once per hour - downloading remote changes and uploading local ones.

Security considerations here:

  • Token flow can be used to avoid having client secret in the open. This method requires a redirect URI however, and data: URIs won't work. So it seems that we need to construct some kind of an invalid HTTP URL, maybe http://0.0.0.0/ which should definitely not result in an actual HTTP request.
  • OAuth2 access token has to be stored unencrypted in order for the sync to work without entering the master password. There are no data loss issues here as it only grants access to the same metadata which is already available locally. However, losing OAuth2 access token will allow an attacker to perform a denial-of-service attack on devices that haven't been breached, either by removing all passwords or by modifying passwords data so that generated passwords no longer match up. Given that a compromised device can generally push changes to all other devices this issue seems to be inherent to any syncing functionality.

Conflict resolution:

  • A sync consists of three operations: reading remote data, merging data locally, uploading modified remote data. A conflict occurs if another device syncs at the same time and the remote data is replaced after the current device reads it but before it can upload its modifications.
  • Dropbox's file versioning solves the problem nicely. So when the remote data is retrieved x-dropbox-metadata header can be evaluated in order to find the revision of the data. When the modified version is uploaded, parent_rev parameter should be specified to ensure that only that revision can be replaced (also autorename=false).
  • If the file cannot be replaced we will receive 409 response code, we should retry the sync then. A random back-off interval is probably a good measure here, not really required however.

Merging changes should work as following:

  • If remote data doesn't have a password that exists locally: was the password added locally after the last sync?
    • If yes: add the password in remote data.
    • If no: remove the password locally.
  • If remote data has a password but local data doesn't: was the password removed locally after last sync?
    • If yes: modify remote data to mark that password as removed.
    • If no: add the password locally.
  • If both remote data and local data have a password but parameters differ: was the password added locally after the last sync?
    • If yes: replace the password in remote data, use local data.
    • If no: replace the password in local data, use remote data.

The only additional data structure needed locally here should be passwords touched since last sync, including passwords that got removed - passwords that were touched win over remote changes, the ones that weren't get remote changes applied. Note: when the sync is set up initially all passwords need to be marked as touched, otherwise they might be removed on sync.

palant pushed a commit that referenced this issue Oct 15, 2016
@palant palant mentioned this issue Mar 13, 2017
palant added a commit that referenced this issue Feb 19, 2018
palant added a commit that referenced this issue Feb 20, 2018
palant added a commit that referenced this issue Feb 20, 2018
palant added a commit that referenced this issue Feb 20, 2018
palant added a commit that referenced this issue Feb 20, 2018
@palant
Copy link
Owner Author

palant commented Feb 22, 2018

The bulk of the functionality has been implemented. What's still left now:

  • Rekeying on first sync with another device's storage still needs to be implemented.
  • Sync errors need to be shown to the user.
  • Error handling has to be tested properly.
  • Retrying when colliding with another client definitely doesn't work, needs to be adjusted and tested in the unit tests.
  • Web client needs a way to get the Dropbox access token.
  • No sync attempts when offline.
  • Need to write a detailed article on the sync functionality and link to it.
  • Add Google Drive as another storage provider.

palant added a commit that referenced this issue Feb 22, 2018
palant added a commit that referenced this issue Feb 22, 2018
palant added a commit that referenced this issue Feb 22, 2018
…er won't allow access to response headers on Chrome
palant added a commit that referenced this issue Feb 22, 2018
palant added a commit that referenced this issue Feb 27, 2018
@palant
Copy link
Owner Author

palant commented Feb 27, 2018

This issue can be resolved as fixed at this point. I will open new issues on adding Google Drive as another storage provider and enabling sync in the web client.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant