The Starbucks bug: not as awful as reported

[UPDATE] The iOS app, and only the iOS app, stores user credentials in clear text in a crash log file. Beware rampant misreporting on this issue.
Written by Larry Seltzer, Contributor

On Monday, January 13, researcher Daniel Wood reported on the Full-Disclosure mailing list that the Starbucks iOS app was storing user credentials in clear text on the device.

[UPDATE: Starbucks has released a fixed version of the app.]

Since then, in a display of hysteria all too common in the security business, news reports have jumped to a number of unjustified conclusions. I won't name any names, but you can find them easily on Google News. Stories have given the impression that all online access to Starbucks suffers from this bug; that the app was storing "mobile passwords"; that it was storing this information for retrieval when the user logged in, as with a cookie; and that it was done for convenience of the user and/or developer. None of these are true.

The bug is a real and disturbing bug, but it's not critical. Here's what it is: Starbucks uses a 3rd party software component called Crashlytics, which collects and analyzes crash data from apps. The Starbucks iOS app writes (or wrote; perhaps they have fixed it already) the username and password, along with the OAuth token and OAuth signature for the user's account/device on the Starbucks service, to the Crashlytics session.clslog file, and writes them in clear, unencrypted text.

This is a bad thing: A malicious and sophisticated user who had physical possession of the phone could look at the file and then log in to the Starbucks site as the user from another device or computer. If the user had credit card information stored, the malicious user could buy things at Starbucks. The user can't get the credit card information because he can only see the last 4 digits of the number. So the thief could buy things until the account holder's account was drained; if the account was set to auto-reload, he could buy some more — at Starbucks.

In his F-D post, Wood includes a list of iOS best practices from OWASP, the first of which is "Never store credentials on the phone file system." Starbucks knows this and, as ComputerWorld reported, they knew about this specific issue but had not yet done anything about it. Clearly embarrassing, and you can expect the Starbucks app developers to be drinking a lot of the company's product as they fix the problem ASAP, dropping all other priorities until it's done. In this case, the fix may be simple in that they just to not write the username and password to the log file. Incidentally, here's Starbucks's public letter on the matter.

Wood also later found that Starbucks was storing geolocation data for each time he asked the app to find a store. Computerworld quotes Wood as saying "If you grab someone's phone, you can effectively go through this log and see effectively where this person has been," but it wouldn't be a very complete log of your locations.

Starbucks confirmed for me that only the iOS app was at issue. Wood said he couldn't say more now than was already public, but that more information should be forthcoming soon.

Just to be sure, and out of curiosity, I scoured all the data from the Android app on a couple Android devices (it stores very little) and didn't see any cleartext credentials, nor were there in any of the cookies or other storage for starbucks.com in my web browser. [UPDATE: An earlier version of this story stated that not all Starbucks iOS app users would have a session.clslog file because the app may not have crashed. As we say in our story about the fixed app version, there are other ways that a user might have the file on their system.]

I have received several pitches from security companies and analysts who want to talk to me about this issue, and every one of them exaggerated the threat. This is not uncommon, as the security industry has no interest in noting mitigating factors. It's always better for them if the public thinks things are as bad as possible. That's why you need to take a breath and think about security reports and what they actually say, and not assume anything else.



Editorial standards