2011.07.27

Introduce Feature

• if there is no master password then data stored by the browser is vulnerable
• setup a master password automatically without user action to protect the data 
  • if they set on later we change from the automatic password to the user supplied password
• orig planned to use system storage, but this is not accessible in Android & it's not a keychain type system that provides adequate security
  • Prereq: data dir had to be only accessible by our process

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

• to protect user passwords stored in the browser this does not protect other data
• this is meant to be on parity with master password as it is in desktop firefox

What solutions/approaches were considered other than the proposed solution?

• use Android features
  • did not work as needed (see introduction)

Why was this solution chosen?

• there is an add-on that does this today, but we are upstreaming this to the product
• asking users to set a master password does not provide adequate security as most ignore it

Any security threats already considered in the design and why?

• someone takes SD card from device
• someone takes device and hooks it up to USB

Threat Brainstorming

• largest threat is the theft of either the SD card (when app is installed on an SD card) or theft of the device itself
  • some default features of SD card access in Android protect against this attack on another Android device
  • if SD card is attached to a laptop then little can be done against a brute force or known password attack
  • same remains true of theft of device
    • this validates the thinking that setting a master password for the user silently is better then doing nothing
    • In the long run this really is a an issue that needs to be addressed by the underlying OS

Conclusions / Action Items

• nothing new at this point