If you’ve read any content on the WebDataStudio.com website, you’ll know we mention ‘hashes’ and ‘salts’ a lot. No, we aren’t just very into breakfast (although, we never say no to salted hash-browns to start the day).

In programming, hashes and salts are simply ways to change data into something else. And the reason we use them is to protect the data of our customers and the data of everyone who visits their websites. We alter this data to an extreme level (as we’ll explain below) to ensure data protection and digital privacy.

Changing data into something else that only some can decode isn’t new to tech. It’s been around since at least 1900 BC when Egyptians chiselled non-standard hieroglyphs on tomb walls. Caesar even used encryption for secure communications.

Salts and hashes, defined

  • A hash is a function that scrambles data into a series of numbers and letters. Unlike encryption, it’s a one-way process (meaning it can’t be de-hashed easily, whereas encrypted data is meant to be decrypted at some point). The problem with hashes (by themselves) is that they can be brute-forced and cracked.
  • A salt is a way to make a hash better by making it harder to crack. All a salt does is add pre-defined data to the input, making it harder (almost impossible) to crack.

An example of using salts and hashes

If we convert Luna (a fake visitor to a website that uses our embed script for analytics) into a hash (via a SHA256 hash, for example), it’ll be the same value every time (in WebDataStudio.com’s case, for 24 hours).

Let’s do this. Go to md5hashgenerator.com and type in Luna. It’ll generate a hash for you. That hash will be 818468ddb460c3bd842a28f371bca99e. That looks like we turned personal information (a name) into a jumble of random letters and numbers, right?

But, now copy 818468ddb460c3bd842a28f371bca99e and paste it into crackstation.net. You’ll see that it knows it’s an “md5 hash” and gives you the result of Luna. Meaning, it cracked the hash, and simply hashing data like this isn’t great at protecting it from privacy abuses.

This is why salts come into play. As we said, salts add random data to the input before it’s hashed, making it near-impossible to crack later. For example, let’s say our salt is WebDataStudio.com-rocks:, so we’d add it to our input, making it WebDataStudio.com-rocks:Luna.

Now, go ahead and type WebDataStudio.com-rocks:Luna into md5hashgenerator.com and hash it. You’ll receive a hash of daa506e9f40dda55a14c641d660c5cbe. Now, paste that string into the hash cracker at crackstation.net. This time, it’ll show you a “not found” result, meaning it cannot crack the hash (and also meaning that data of WebDataStudio.com-rocks:Luna is safe and secure).

Because there’s not enough computer power to practically try every possible salt value (because WebDataStudio.com-rocks could be anything), it makes a brute force attack on the hashed data damn-near impossible.

Most companies, if they are salting and hashing data for their customers, use a single non-changing salt or a salt per user account. But, WebDataStudio.com goes much, much further with data protection and creates a unique salt at the site level (i.e. one unique salt per site visited), and we change that salt every 24 hours. So, even if someone were to find out what the salt was that we used for a single site and tried to crack our database, they’d only have 24 hours worth of data to crack because the salt would change. And they’d only have data for a single site because the salt is different for every site (meaning they couldn’t see how a person visited many sites across the web, which is what some analytics software does) without having ALL the salts for ALL the sites using WebDataStudio.com.

So as you can see from the above, salts are now used so that hackers can’t crack hashes without trillions of dollars available to them.

How WebDataStudio.com salts and hashes data

You can read about the full journey that data goes through from website visit to stored on our data journey page. But let’s explain the salting and hashing part here.

We compare hashes to determine if a visitor is unique on a per-site level. Meaning if the same person visits two sites that use WebDataStudio.com, they’re treated as two unique user signature hashes. We also recycle the salt every day at midnight, meaning the “uniques” on our dashboard are daily uniques, and if the same person visits a site 3 days later, for example, they’re a new unique.

We also create a hash for each page visit. Meaning, each time a visitor views a page, we hash the page’s user signature and pathname and then tally these up on our dashboard. That way we can show our customers that, for example, “287 people visited /about on Thursday”.

The benefit of all this salting and hashing is that even if someone somehow broke into our database and grabbed our hashes and salt keys, they’d need trillions of dollars to crack the data.

Conclusion

So there you have it. We hope you now better understand what salts and hashes are, even if you’re not a programmer. And more importantly, why WebDataStudio.com uses (many and changing) salts and hashes to protect all the data we store for analytics purposes, and how it keeps that data much more private.