On Tue, Mar 26, 2013 at 4:03 PM, Kristopher Micinski <[email protected]> wrote: > Right, so I guess I'm still not understanding your question: are you > just trying to ask what the best static analysis technology is to > fight against this. No, I can find the problems in the code during review.
> or something else? Yes. Suppose my application rotates. That means its going to be killed and then restarted. How do I pass that cached password between instances of my program so the user is not prompted to re-authenticate? In general, how do I securely transition between states? I know I can't encrypt the password and put the encryption key in a Keychain or Keystore. That's because once persisted, the temporary encryption key (used across the restart) and the encrypted password (saved to storage) can be recovered. Both "good" bad guys and presumably "bad" bad guys will attempt to recover data. For example, law enforcement will send a device to Google for data recovery [1,2]. For what's its worth, I don't differentiate between "good" bad guys and "bad" bad guys since both are a threat to the data. Jeff [1] http://www.forbes.com/sites/andygreenberg/2013/02/26/heres-what-law-enforcement-can-recover-from-a-seized-iphone/ [2] http://paranoia.dubfire.net/2012/03/fbi-seeks-warrant-to-force-google-to.html > On Tue, Mar 26, 2013 at 3:09 PM, Jeffrey Walton <[email protected]> wrote: >> On Tue, Mar 26, 2013 at 3:02 PM, Kristopher Micinski >> <[email protected]> wrote: >>> ... >>> >>> Personally, I thought that there are many apps that do things like >>> persist auth tokens. (A few apps I've seen even store passwords..) >> Yes, a number of applications persist data they should not. A web >> browser comes to mind, as does a number of hybrid apps I have >> reviewed. >> >> Many folks don't want to accept that browser based applications can't >> handle higher data sensitivity levels. The browser falls short in >> handling both data in transit and data at rest. >> >> Jeff >> >>> On Tue, Mar 26, 2013 at 2:56 PM, Jeffrey Walton <[email protected]> wrote: >>>> On Tue, Mar 26, 2013 at 2:04 PM, Kristopher Micinski >>>> <[email protected]> wrote: >>>>> I'm not sure I really understand your question. >>>>> >>>>> Here's what I think you're saying: Android apps are written to be >>>>> ephemeral, and routinely get killed (after hey have *hopefully* >>>>> serialized their state into memory) and restarted at the appropriate >>>>> points. But you're worried that the programmer will accidentally >>>>> serialize some piece of information that they shouldn't be because it >>>>> is sensitive. (E.g., this happens with tokens for webservices, for >>>>> example..) >>>> Yes. The encrypted secret is the user's password or a session cookie >>>> that's being cached to improve the UI experience. Persisting an >>>> encrypted secret across the restart only works if the encryption key >>>> cannot be recovered; and I can't guarantee that with a Keychain or >>>> Keystore. >>>> >>>> When moving to the background, I recommend wiping secrets if the data >>>> sensitivity level warrants increased vigilance. That means a user will >>>> have to, for example, login again on the next relaunch. Its >>>> inconvenient, but its a necessary evil to comply with some polices. >>>> >>>> However, screen rotation is different since I know the application >>>> will be immediately relaunched. In this case, the "wipe secrets" >>>> strategy does not really work. >>>> ... -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/android-security-discuss?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
