Earlier this week, security researcher Daniel Wood disclosed his findings on Starbucks' insecure handling of sensitive user information in their iPhone app. The sensitive information discovered includes usernames, passwords, emails, addresses, location data, and OAuth keys. While Wood's findings are valid, the interpretations of his findings have been inaccurate and exaggerated.
The Starbucks iPhone app, like many iOS apps, includes a crash reporting framework: Crashlytics. In addition to crash reports, Crashlytics is also able to provide custom logging and reporting for mobile apps. The issue that Wood uncovered is the Starbucks app is far too liberal in what information gets logged. Developers can choose to have certain events result in corresponding debug information being logged. For instance, if a request made to a server results in an error, the developer could have information pertaining to that error recorded, and then sent back to them in a log by Crashlytics.
In the case of the Starbucks app, the application is logging information that it shouldn't, like users' passwords. When a user signs up for a new account through the Starbucks app, all of the information for creating this account – email address, username, password, birthday, and mailing address – is temporarily logged to a file in the app. Wood also noted that a user's geolocation can get logged if they use the store finding feature of the app. Certainly sensitive information should be stored and transmitted securely by apps, but what is the actual risk to users here?
First of all, because the information is being stored in a temporary log, the window during which users are exposed will vary. It's an important distinction to make that Starbucks is not persistently storing user credentials in cleartext in the app, but instead they are temporarily getting logged after certain events. When I initially checked my logs, my password was nowhere to be found. The only time I was able to get my password to appear was if I signed out of the app and went through signing up with a new account.
Additionally, for users who set a passcode on their device, the risk is lowered. The first time an iOS device is plugged in to a computer, the device has to be unlocked before the computer can read any data from the device's filesystem. This means if you drop your phone on the street, then some stranger finds it, takes it home, and plugs it into their computer, they won't be able to view these logs unless they figure out your passcode, or they jailbreak your device. While not impossible, it's unlikely that a vulnerability like this will result in a rash of iPhone thefts by caffeine-crazed criminals looking to get access to your Starbucks cards.
According to Wood's disclosure, he originally reported the bug to Starbucks last month, but didn't receive a response from them. Computerworld reported that Starbucks executives responded saying the security issues have been addressed, however both Wood and iMore have confirmed that, at least in some circumstances, users' passwords can still be logged in clear text. Although iMore was unable to confirm that a user's password is logged when a user logs in, we did observe that unsuccessful login attempts result in the attempted username and password being logged (which still isn't desirable). Successfully logging in did not appear to result in the username and password showing up in the Crashlytics log.
Contrary to some reports, this bug shows no indication of being the result of convenience trumping security, or developers insecurely saving a user's credentials to automatically log them in when they use the app. The Starbucks app appears to generate an OAuth token on login, which is then securely stored in the device's keychain; following best practices for mobile security. Unfortunately the oversight in logging currently undermines that security. This serves as a reminder to users on the importance of using unique passwords for each service they use, as well as a reminder to developers how a single bug or oversight can undermine an otherwise sound implementation.
When reached for comment, Starbucks was unable to give any specifics about the bug or any potential response to it, but did have this to say:
Starbucks has taken additional steps to safeguard customer information based on the findings raised by the report. [...] we are currently looking to see if there are additional steps we should take to add an additional layer of protection to our mobile app."
Update: Starbucks's CIO has issued the following statement:
Dear Customer,
Your security is incredibly important to us. This week a research report identified theoretical vulnerabilities associated with the Starbucks Mobile App for iOS in the event a customer’s iPhone were to be physically stolen and hacked.
We’d like to be clear: there is no indication that any customer has been impacted by this or that any information has been compromised. Regardless, we take these types of concerns seriously and have added several safeguards to protect the information you share with us. To protect the integrity of these added measures, we are unable to share technical details but can assure you that they sufficiently address the concerns raised in the research report.
Out of an abundance of caution, we are also working to accelerate the deployment of an update for the app that will add extra layers of protection. We expect this update to be ready soon and will share our progress here. While we are working on the update, we would like to emphasize that your information is protected and that you should continue to feel confident about the integrity of our iOS app.
We appreciate your business and believe it is our job to earn your trust as a customer. We also know that constant vigilance is the best way to protect you and the information you share with us. If you think your information may have been compromised for any reason, please contact our Customer Care team at 1-800-23-LATTE or at www.starbucks.com/customer.
Sincerely,
Curt Garner
Starbucks chief information officer
Update: Starbucks has released an update that addresses the issue.
