Labs/Weave/Sync Client Security Review
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
- 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
- JSMs: there's a number of modules that get imported into the service/UI
- Does it interoperate with a web service? How will it do so?
- https://wiki.mozilla.org/Labs/Weave/API storage/user APIs
- 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
- 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
- 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
- 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
- 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
- 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: 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 firstname.lastname@example.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?