The actual disclosure linked in the article is a little bit different than what the article is implying. http://seclists.org/fulldisclosure/2014/Jan/64 http://

The actual disclosure linked in the article is a little bit different than what the article is implying. http://seclists.org/fulldisclosure/2014/Jan/64 http://seclists.org/fulldisclosure/2014/Jan/64 The file in question is a log generated by the application. They are NSLog'ing stuff to the console, and Crashlytics must be capturing it up and putting it in this file. Along with debug tracing messages like this below, they're logging server interactions and JSON responses that contain personal information (I see my home address, telephone number, etc coming back from the server and being logged). 2539 $ -[CardDetailViewController refreshCardDetails:] line 798 $ 2548 $ -[CardDetailImageViewController viewDidLoad] line 28 $ view did load 2551 $ -[CardDetailImageViewController viewWillAppear:] line 48 $ view will appear 2551 $ -[CardDetailImageViewController viewDidAppear:] line 53 $ view did appear 2588 $ -[CardDetailViewController refreshCardDetails:] line 798 $ 2607 $ -[CardDetailViewController doPageChange:] line 684 $ : 2652 $ -[CardDetailViewController viewDidAppear:] line 301 $ I APPEARED!! 2652 $ -[StarbucksAppDelegate trackView:] line 1084 $ 2014-01-14 18:50:37 +0000 /Card/MyCard 2791 $ -[CardDetailViewController viewDidAppear:] line 301 $ I APPEARED!! So the situation here isn't one of tokens vs passwords vs encryption or otherwise how they're being stored for interacting with the server. The user is going to have to enter a password at some point in the workflow, regardless of whether it's encrypted at rest or exchanged for an OAuth token or whatever. You shouldn't be logging that password back to the console when the user enters it! edit: This also means that all that personal information of mine is presumably on some Crashlytics host as a side effect of all this having been logged and sucked up by Crashlytics.