Checklist 157: Just Add S4LT
On this edition of The Checklist: The DoorDash data breach, Considering risks around AltStore, And the security side of recent Apple updates.
This week on the Checklist, we’ll dig deeper into a data breach and learn how companies (try to) keep their customers’ passwords safe. We’ll check out AltStore, an iOS jailbreak in all but name. And finally, we’ll see what security enhancements came out in Apple’s latest round of updates.
Here’s this week’s Checklist:
- DoorDash data breach
- Considering risks around AltStore
- The security side of recent Apple updates
When extra salt is good for you
Food delivery service DoorDash is the latest company to be hit with a data breach. Last week, the company disclosed news of a breach which had compromised 4.9 million customer, merchant, and delivery driver records. Hackers made off with names, phone numbers, email addresses, and delivery addresses; customer order histories; and hashed and salted passwords. Customers who joined the service after April 5, 2018 were not affected.
Breaking that down a bit, we can see a few causes for concern.
Obviously, any time personally identifiable information goes missing, it’s not a good thing. Other than the obvious privacy issues involved, data that can be used to identify individuals can also be used for fraud and identity theft.
Order history, too, is more serious than one might first imagine. Not because hackers now know that you prefer sushi to Thai, but because your ordering patterns could disclose other sensitive information about you: When you tend to be home, whether or not you have children, if you live alone, etc.
The fact that hashed and salted passwords were stolen is, maybe surprisingly, the least worrying part of this data breach. But to understand why, it’s important to know what these terms mean.
When companies store user passwords in their databases, they aren’t just storing those passwords as plain text (unless they’re being extremely negligent).
Instead, they first “hash” the passwords in question. So what is hashing?
Essentially, it’s a way of using a complex mathematical algorithm to convert an input value of any length into a unique string of fixed length. The algorithm used to do this is called a hashing algorithm. The output string produced is called a “hash” or a “hash value”.
You can see how it works for yourself by playing with an online hash calculator like this one, which uses the SHA-256 hash algorithm.
No matter what input you give it, it will always return a 256-bit string.
For example, if your input data to be hashed is just the letter “a”, you get this:
“a” > ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb
But if your input data is something much longer, say, for example, the first lines of the Declaration of Independence, you still get a 256-bit string:
“When in the course of human events it becomes necessary for one people to dissolve the political bands which have connected them with another and to assume among the powers of the earth, the separate and equal station to which the Laws of Nature and of Nature’s God entitle them, a decent respect to the opinions of mankind requires that they should declare the causes which impel them to the separation.”
The other thing to note about hashing algorithms is that due to the way they work, tiny changes in input values lead to completely different hash value outputs. So for example, if you use the word “example” as your input, you get one hash value as your output; but if you simply change a single letter of that input word, you end up with a completely different hash value:
“example” > 13550350a8681c84c861aac2e5b440161c2b33a3e4f302ac680ca5b686de48de
“examplf” > 5c9b9d9508ea07de2b59e287a2f87d308a0920865a22e2ded350e8c41d11a7d4
Hashing, then, is not really encryption. It’s more accurately described as a kind of mathematical “mapping” of input data to an output value. And unlike encryption, there is no decryption key—hashing is a strictly one-way process. There is no way to “decode” a hash value and figure out what the original input value was.
Securely developed websites store the hash values of user passwords, not the passwords themselves. When a user inputs their password into a site to log in, the same hashing algorithm originally used to store the user’s password as a hash value is run on the password entered and compared to the database. If the two hashes match, the site knows that the user entered the correct password—without knowing the user’s actual password…or having to store the password as vulnerable plain text in a database.
However, there is one catch.
Hashing algorithms rely on extremely sophisticated math. Many of the most commonly used ones were developed by the likes of the National Security Agency. Because of this, most businesses rely on one of a handful of these algorithms—and the algorithms are publically available.
That means that hackers can pre-compile large lists of hash values based on what they guess are the most common password inputs.
In theory, this shouldn’t help them. After all, if the input value can be absolutely anything, then they would have to compute an infinite number of hashes in order to create a list that would cover all possible passwords.
In practice, however, people are pretty bad at creating strong, unique passwords. And so a hacker might compile a big list of common passwords and their variants, computing the hash value for each one. If they then manage to steal hashed passwords from a database, all they have to do is match one of their pre-computed hash values with something they find in the stolen database, and they will know what the user’s actual password is.
For example, a hacker might create a list of hashes for the truly terrible password “password”, and all of its likely variants. Something like this:
If they then find that the user email@example.com has 4b358ed84b7940619235a22328c584c7bc4508d4524e75231d6f450521d16a17 listed as their hashed password, then all they have to do is find that hash in the pre-compiled list…
…and they will know that the actual password for this user is “pa$$w0rd”. And with that, they’re in to the customer’s account (and probably other accounts as well, since people tend to reuse passwords across sites).
For this reason, many sites take the additional step of adding “salt” to passwords before hashing them. Salt is extra data that is added to a password before hashing, to add some randomness to the users’ passwords before they are hashed. Sometimes sites will add the same salt to all passwords, or sometimes they will do this and add some extra, unique salt to each individual password as well.
In this way, it becomes extremely difficult for hackers to create a useful, pre-compiled list of hashes—because even if they know what passwords people are likely to use, they still won’t know what salt or salts the website is adding to those passwords before running the hashing algorithm on them.
This is yet another reason why it’s crucial to create strong, unique passwords: the kind of passwords so long and so unlikely that they will never make it into a pre-compiled list of hashes. Because while it seems DoorDash was using salt on their customers’ passwords, other sites might not be as careful.
A jailbreak by any other name
We’ve talked in the past about the dangers of jailbreaking iPhones. But now there’s AltStore, which promises users the ability to download and run non-App Store apps without jailbreaking their phones.
According to the creator of AltStore, this non-jailbreak jailbreak works by tricking your iPhone into thinking you’re a developer running apps you’ve developed yourself.
You only need a free Apple ID, and the AltStore app will re-sign and reinstall unofficial apps every 7 days, in essence allowing you to keep unapproved apps running on your iOS device indefinitely.
So is this a good idea?
We’d have to say no.
First of all, in terms of simple practicality, there’s every likelihood that Apple is going to shut this down eventually, or that the lone-wolf developer behind AltStore is going to lose interest in his project, leaving anyone who’s bought AltStore apps with non-functional software.
Secondly, and more importantly, there are the security issues. The App Store’s stringent developer requirements and security precautions exist to protect iOS users from the sorts of shoddy and predatory app development that plague the Android platform. AltStore is a clear attempt to circumvent these protections—and while their motivations may be benign, the existence of an alternative app store opens the door to less scrupulous developers to cause some real damage on iOS devices.
Apple has some options in terms of how they deal with AltStore.
First of all, they may choose to go after associated developer accounts or app provisioning profiles one by one. Given Apple’s control of the platform and their vast resources, this option is likely within their reach.
Another possible response would be to change they way they do profile handling. While this would likely be time-consuming and cause problems for legitimate developers, Apple is serious enough about safeguarding users on its platform that they may actually take this step.
Finally, there’s a decidedly low-tech but very effective way for companies the size of Apple to deal with things like AltStore: Sue. With hundreds of billions in cash and an army of lawyers at their disposal, Apple could file lawsuits and seek injunctions against AltStore and then simply wait until they run out of money…or cave under the pressure.
All in all, it’s probably not a good idea to try AltStore (while it lasts). While the creator of AltStore may just be an innovative developer with a penchant for pushing boundaries, there’s no guarantee that other developers on his unofficial platform will be similarly harmless. As Google Play users know, unscrupulous developers with a toehold on a platform will take that opportunity to engage in all manner of nastiness, from tracking and spamming to outright data theft.
A fix for Foundation
Apple recently released iOS 13 and 13.1 updates, as well as an update for older devices in the form of iOS 12.4.2; they also released watchOS 5.3.2 for the Series 1 and Series 2 Apple Watch models.
According to Apple’s release notes, one of the main issues addressed in all of these updates had to do with Foundation, a framework that offers developers basic, core OS functionality that works across all of Apple’s platforms. For example, Foundation provides a common way for the various Apple OSes to handle strings, store data, calculate dates and times, and so forth.
So what was the bug in Foundation? Apple’s notes have this to say:
“Impact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution.
Description: An out-of-bounds read was addressed with improved input validation.”
In programming, an “out-of-bounds read” refers to an instance in which a program reads data that it shouldn’t have access to. This can result in a crash, or, more seriously, a program accessing sensitive data that it shouldn’t be seeing or even running code without permission.
The fact that Apple patched this issue across multiple OSes—even in advance of planned Fall releases of a new watchOS—points to the seriousness of the matter.
As usual, if you haven’t updated your device’s OS in a while, now would be an excellent time to do so.