Starbucks admits "your security is incredibly important", updates password-spilling app

library
crime | hacking | security

Starbucks got into and out of privacy trouble over the past week.

The brouhaha started when a US researcher named Daniel Wood went public on the Full Disclosure security mailing list, reporting a rather serious data leakage problem in the Starbucks iOS mobile app.

We’ve written (and spoken) about the shortcomings of mobile apps before.

Even organisations that take security seriously when you interact with them in your browser, such as financial institutions, have been found wanting when it comes to their mobile apps.

Starbucks, it seems, fell into the same trap.

Wood didn’t say in his Full Disclosure posting, but one news report suggested he went public to push Starbucks to act after getting the run-around for a couple of months from Starbuck’s customer service.

The main part of Wood’s complaint was that Starbucks was sloppy with the data it wrote into its log files, dumping usernames and passwords in plaintext.

Of course, app logs can be very handy, notably if something goes wrong with your software.

Mobile apps are on-line most of the time, so you can easily and efficiently collect logfiles after a crash.

Logfiles are really useful when you are debugging software that is used by millions of people in a myriad of different configurations on thousands of different networks.

Indeed, it looks as though the main purpose of the Starbucks logfile was to help the company’s developers, because the logs are created by a third-party software component called, amusingly, Crashlytics.

As Wood found out, even if you protected the Starbucks app with a PIN (thus inhibiting someone who snatched your phone from firing up the app and paying for their own coffee at a click), the logfiles were unencrypted and accessible to attackers who got hold of your device.

Of course, the most effective crash-busting logs are those that include useful information leading up to the crash, rather than merely what could be extracted from the app’s memory image after it has imploded.

In other words, even if an app doesn’t crash, it may be quietly squirreling away a hoard of information, including, in the case of Starbucks, your username and password.

But usernames and passwords constitute PII (personally identifiable information) and ought not to be stored unencrypted, not least in this case because anyone who acquires them can freely spend your money at Starbucks.

→ Starbucks offers an “auto-reload” feature that will grab money from your payment card to replenish your Starbucks account if it runs low, so that you will never be caught short at the checkout with a steaming Grande in your hand. If you have that feature turned on, your financial risk from a security blunder in the mobile app is, obviously, much greater.

Starbucks, it seems, has published an update to the app, and no longer logs the offending information.

Sadly, the company didn’t manage to avoid the now-traditional cliches, leading with the words, “Your security is incredibly important to us,” and claiming that the software update was produced “out of an abundance of caution.”

We’ll disagree with both of those statements, because they don’t explain why anyone thought it was appropriate to store the user’s raw password in cleartext the first place, for any purpose.

Here’s our advice:

If your app must store actual passwords, for example so that users don’t have to type them in every time they grab a cup of coffee, use a secure storage mechanism such as the Apple Keychain (as the updated Starbucks app now apparently does).
Never allow decrypted passwords to be written to disk, even to temporary files, or sent across the network except over a secure connection such as SSL/TLS.
Never store the passwords for an online service on the server, even encrypted. You simply don’t need to. Use a salt-hash-stretch technique instead, and store one-way hashes that will validate passwords, but can’t be reversed to recover the actual password.