Labs/Weave/Sync Client Security Review

From MozillaWiki
< Labs‎ | Weave
Jump to: navigation, search

Overview

Synchronize your bookmarks, history, tabs and passwords wherever you go. Whether you use Firefox on your phone, laptop, or desktop, securely access all your data.

Background links

Security and Privacy

  • Is this feature a security feature? If it is, what security issues is it intended to resolve?
    • Securely sync data across browser profiles by encrypting and storing data on Weave servers
  • What potential security issues in your feature have you already considered and addressed?
    • Encrypting data that requires a passphrase that only the user knows to unlock
  • Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
  • Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
    • Data/actions are generated on the client but stored on the server, so how the server responds with what can change the behavior (e.g., missing data)
  • How are transitions in/out of Private Browsing mode handled?
    • Sync is disabled during private browsing and reschedules on exit

Exported APIs

  • Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
    • JSMs: there's a number of modules that get imported into the service/UI
      • Service: main entry point to connect and control sync behavior
      • Engines: tracks active engines registered with Weave and provides an abstract base class to implement engines
      • Storage: wrapper around Firefox's implementation of various data storage
      • Tracker: hooks into various notifications for detecting data change
      • Resource/Auth/Identity: handles network communications
      • Log4Moz: provides logging for each object with various logging levels
      • Records: WBO/crypto convert/encrypt JS objects into records to read/write for the server
    • Firefox status bar: allows triggering sync and connect
    • Firefox pref pane: configure what data to sync to which account
    • Firefox tabs view: view and open tabs from other profiles in a menu
    • Fennec pref pane: connect and sync
    • Fennec tabs view: view and open tabs from content space
  • Does it interoperate with a web service? How will it do so?
  • Explain the significant file formats, names, syntax, and semantics.
    • JSON: local temporary storage (changes, to fetch)
  • Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
  • Does it change any existing interfaces?
    • Extra data is stored using existing annotation interfaces

Module interactions

  • What other modules are used (REQUIRES in the makefile, interfaces)?
    • NSS: WeaveCrypto
    • Places: Bookmarks/History
    • LoginManager: Passwords
    • FormHistory: autofill data
    • Browser/Sessionstore: Open tabs
    • Prefs: some preferences synced

Data

  • What data is read or parsed by this feature?
    • Records from the server are stored as WBO (weave basic object) with encrypted JSON payloads that are specific to the particular data synced
  • What is the output of this feature?
    • Profile data recreated on another profile, e.g., bookmarks and history
  • What storage formats are used?
    • JSON for talking to the server as well as local caching
    • Prefs with simple values (int/bool/string) for basic local storage

Reliability

  • What failure modes or decision points are presented to the user?
    • Account creation: username check, password/passphrase strength, captcha
    • Login: username/password/passphrase failures
    • Sync direction: choose to merge/wipe data locally/wipe all other machines
    • Sync: notifications are shown based on the type of failure to do nothing (auto-retry) or present actions (e.g., upgrade add-on)
  • Can its files be corrupted by failures? Does it clean up any locks/files after crashes?
    • Potentially some data might get lost if it was in the process of being downloaded, but it'll refetch at a later time when the data updates
    • Data to be uploaded are cached by GUID on disk to persist across crash/restarts

Configuration

  • Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?
    • Pref pane controls what data gets synced and which account is logged in
    • about:config contains other prefs that the service uses for data storage like logging levels, when to sync, server urls, prefs to sync
    • Password/passphrase are stored with the password manager
  • Are there build options for developers? [#ifdefs, ac_add_options, etc.]
    • Packaging for dev/amo channels (sets update url)
    • Rebuilding crypto library
  • What ranges for the tunable are appropriate? How are they determined?
    • Sync intervals depend on the makeup of clients connected (desktop? mobile? how many?)
  • What are its on-going maintenance requirements (e.g. Web links, perishable data files)?
    • Update urls/updated landing page

Relationships to other projects

Are there related projects in the community?

  • If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?
  • Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?
    • various data providers, e.g., Places, have updated their interfaces to better support Weave with better notifications and annotations/guids

Review comments

  • In account creation, should we protect against an SSL hijack?
  • Can we show special UI for users that do not use password manager (have turned it off?)
  • Passwords are unsalted MD5, should be MD-256 or SHA-256.
  • Some questions about what the captcha can do.
  • We don't have any official agreements with recaptcha - should we have one in case we become ultra popular?
  • Action:We should do a security audit for the client, hasn't been done yet.
  • What happens if we get bad certs? We silently eat them and get a generic error.
  • Is the user warned that you are storing password/passphrase in password manager?
  • Action: Have a blacklist of prefs, things we would never sync even if the user asks us to. Also, should we not sync Weave prefs?
  • Recommend users that have their own
  • Action: Password is Basic inside SSL. Should be Digest.
  • Is there a privacy problem - a network listener can figure out when you are syncing?
  • Action: For form data, we use the hash as the GUID since Places doesn't use GUIDs for form data.
  • Action: Can the captcha being loaded in a browser element do something to the rest of the browser?
  • Enumerating user names is trivial. Was designed to enable discovery - can we make this more secure without compromising UX?
  • Action: Don't differentiate between user name is wrong and user name doesn't exist.
  • Action: We should not sync the passphrase.
  • Action: We should have the user fill out or pick a client name. User doesn't realize that they are sharing this information to us. Also affects the Privacy Policy. If this information is actually not useful to us, then we should encrypt it.
  • Action: IV should be stored along side the record and should be changed every time the record is changed.
  • Action: Document the Weave crypto stuff really well and have a hacker challenge to see if people can break it.
  • Action: We need to have exponential backoff for authentication failures.
  • Action: When downloading keys from the server, the client should generate the public key from the private instead of using what it just got.
  • Action: NIST is encouraging people get away from 2k keys by the end of 2010. -- Not an issue.
  • Think of ways we can detect a hijack (someone could write a malicious add-on that starts directing users to their servers).
  • Action: Make sure the code where we generate entropy is clearly marked off.


Notes from iPhone client review meeting

  • Main difference from Firefox client: iPhone client is just a data viewer (at least in its current version)
  • What happens if there is a security issue with Webkit? Are you going to post updates every time there is a Webkit vulnerability? - Revisit this later.
  • The passphrase is not kept on disk.
  • The private key is in an OS controlled directory.
  • What happens when you pull a backup from iTunes? - backup is not encrypted by default. the sqlite db is stored in the same db.
  • Can we store the weave password in the keychain? This way it is not stored in plain text and is consistent with how other apps handle password storage. May need a workaround.
  • The decrypt private key method has a lot of byte offset stuff there. Should probably be rewritten.
  • What happens when there is corruption in the key?
  • AI: We need code review on the security code of the iPhone client - bwarner would be able to help with this.
  • The crypto libraries are not NSS.
  • We may use a couple of external libraries for some of our crypto whose sources are unknown. PBKDF2 (anant?) CCCrypt, JSON
  • AI: We may need a BSD license credit for the JSON library.
  • Are all connections to the Weave server only over https?
  • What happens with cert error? If the cert's expired, it should not get any data but behave properly.
  • AI: Use crypto change API to see if key has changed.
  • Do we dynamically link to the webkit library - yes.
  • What is our communication/messaging strategy for vulnerability/disclosure processing?
  • There is a mailing list (webkit security list) that does provide confidential information.
  • AI: get security@mozilla.org on that list.
  • AI: Should we implement a firefox style blacklist for disabling functionality if there are webkit bugs?
  • AI: In the severe case, can we shutdown the app for those people?
  • AI: What happens if you get a 401 on access?
  • AI: What's our fail safe?
Retrieved from "https://wiki.mozilla.org/index.php?title=Labs/Weave/Sync_Client_Security_Review&oldid=383639"