505
edits
Labs/Weave/Sync Client Security Review: Difference between revisions
Labs/Weave/Sync Client Security Review (view source)
Revision as of 18:26, 18 March 2010
, 18 March 2010→Review comments
| Line 116: | Line 116: | ||
* Think of ways we can detect a hijack (someone could write a malicious add-on that starts directing users to their servers). | * 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. | * '''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? | |||