UPDATE–Cryptographic algorithms and hash functions are designed to be resistant to a variety of attacks, but one of the things that they can’t defend against is time. Time and the inevitable advancement of technology have turned out to be the greatest enemies of cryptography, and a quick research project done by a graduate student at Stanford on the security of hashed MAC addresses in retail analytics software has shown that to be true once again.

One of the things that has raised the hackles of privacy advocates in recent years is the rise of passive tracking of consumers’ mobile devices as they move through stores, coffee shops, malls and other locations. Retailers can use software that detects the network announcements that cell phones with WiFi and Bluetooth enabled make periodically in order to track a given person’s device. This allows retail analytics firms to build databases that include the various locations that a device has been tracked in over a period of time.

This presents some rather obvious privacy issues, because most consumers have no idea that their devices are sending out these signals, let alone that retailers are gathering the information and building massive databases with the results. In October, a code of conduct surrounding retail analytics was released, and one of the provisions is for firms to hash the MAC addresses of users’ devices after they’re collected as a way to preserve users’ privacy. Jonathan Mayer, a PhD student at Stanford University, decided to take a look at how difficult it would be to reverse the hash of a given device’s MAC address, something that is meant to be quite difficult.

Hash functions take an input, in this case a device’s MAC address, and produce a random series of letters and numbers as the output, the hash value. Attackers should not be able to take the hash value and reverse it to get the MAC address. But Mayer found that this was not only possible but quite cheap and quick to do. Using a rented Amazon AWS server with a fast graphics card, Mayer used the hash-checking program oclHashcat and was able to reverse the hash of his own cell phone’s MAC address in about 12 minutes.

“Some back of the envelope math suggested the task was doable. There are 6 bytes in a MAC address; the first 3 bytes are allocated to the network device vendor, and the last 3 bytes are chosen by the vendor. In total, then, there are 248 possible MAC addresses. Since only 19,130 vendor prefixes have been actually allocated for use, however, there are at most 238.22 validly assigned MAC addresses. That number might sound big, but modern consumer hardware can calculate roughly 230 hashes per second. In other words, it should be possible to check every validly assigned MAC address in just a few minutes,” Mayer wrote.

Mayer was using the SHA-1 algorithm during his test, but said that the same approach would work using other algorithms. His research shows that an attacker who was able to access a database of hash values would have the ability to reverse those values and get the MAC addresses associated with the hashes. The attacker still would need to connect those MAC addresses to individual devices and their owners somehow, but Mayer said that can be done.

“Some businesses and network operators keep a mapping between MAC addresses and individuals. A government agency could subpoena the device vendor for the purchaser’s identity. At any rate, the MLA Code of Conduct seems to concede a MAC address is identifiable; it suggests a MAC has to be hashed to be ‘de-personalized’,” Mayer said via email.

Unless every organization that is recording MAC information is hashing them, then an attacker could be able to link a MAC address

“Hashing is not a silver bullet for electronic privacy. As we have seen, it is possible to test retail analytics data against every possible device. If data is associated with a particular device, it is always linkable back to an individual,” he said.

Most hash functions were produced in a time when the average person had no legitimate access to the kind of computing power it would take to reverse them. Indeed, only a handful of government agencies likely possessed that kind of power until very recently. But the rapid improvement in hardware and the concurrent rise of commodity cloud computing platforms such as AWS have made high-level compute power available to the masses at low prices. Reversing a hash value produced by an older algorithm such as SHA-1 is now within reach for just about any attacker.

“The specific hash function doesn’t matter much, though. All three of the problems I wrote about arise from any hash function. One caveat with respect to reversing hashes: Key stretching would make brute force attacks more difficult. It runs up against practical constraints, though, because retail analytics services have to be able to calculate hashes live in production,” Mayer said.

This story was updated on March 20 to add comments from Mayer.

Image from Flickr photos of Jerry Seaman

Categories: Uncategorized

Comments (4)

  1. Sam Bowne

    This is easily solved by repeating the hash process many times, the same way it’s done for password hashes. 5000 rounds of SHA-512 are effectively unbreakable.

    • Allan Jude

      sha512crypt is not just sha512 done 5000 times. It uses a salt of 16 random characters (base64). So when you hash a password with sha512crypt, it basically makes the password 16 characters longer, to thwart attacks like Rainbow tables.

      However, to compare a hash, you need to know which salt was used. Normally this is solved in a crypt() based password file by having username:$6$salt$hash records

      So when $username attempts to login with $password, the corresponding record is looked up, and a second hash is calculated, crypt($password, $salt). If the output matches, the user entered the correct password. If it does not, then the login was invalid.

      This doesn’t work in the case of just hashing an email address or MAC address, to be able to correlate visits or posts without disclosing the original address, since there is no other key to use to look up the random salt that would be used.

      The general idea of this is that, say you make a service for doing fraud detection on orders (like the one MaxMind offers), rather than them asking you to send them the email address of every one of your customers, you send them just the sha1 hash of the email address. This allows them to correlate orders from the same email address between different ecommerce sites, without ever actually knowing the email address of the customer.

  2. zilch

    Note to self… find an android app that spoofs and spams random MAC addresses before going shopping.

  3. Fabio Rosa

    I know that Apple is about to release random mac addresses at beaconing to avoid retail analytics on IOS8. There is any information of Android or Windows Phone doing the same?

Comments are closed.