Static vs. Dynamic Credential Salting Explained | by Dennis Chow

Many applications, operating systems, and other authentication mechanisms that take in credentials utilize a known defense against cyber-attackers known as "salting." For the non-IT or InfoSec professionals, whenever you create an account for any service, you more than likely created a password. Even though this is a known defense, it's got different methods of implementation. The problem is, depending on this method of implementation, modern computing power makes it still a very low barrier to entry in "cracking" your passwords if the service you're using is ever compromised. After a debate with another Information Security colleague and with a developer asking me what would be a "better practice" of implementing credential salts, I've decided to make this article and demonstration.

Hashing

Many developers of applications and systems have taken your password that you have entered and sent it through a mathematical function that turns your password into an encoded output. The idea is that even though it's easy to turn your password into this new output, it's theoretically impossible to reverse the output to your original password. Commonly known hash types include, but are not limited to, MD5 and SHA-1. How these functions work are beyond the scope of this article. Just know whatever password entered, such as "foobar", is sent through something like MD5 and then it spits out something that looks like this: "3858f62230ac3c915f300c664312c63f" This is the result of you using the password "foobar" and the MD5 one-way hashing function.

 Salting Credentials

A salt is a "random" generated set of additional characters to be inserted along with your password so it makes the MD5 hash different on output, even with your same password. This makes it harder for cyber-attackers to essentially pre-compute and guess your password based on hashing.

No-salting examples:

foobar = 3858f62230ac3c915f300c664312c63f
password = 5f4dcc3b5aa765d61d8327deb882cf99
thesearebadpasswords = 96b803bad93743620ed3b18912a148f1

Attackers can easily pre-compute values for the passwords above because of several factors including: lack of complexity, small character sets, and the use of dictionary words or phrases. Let's add a "salt" which then statically adds "123" prior to computation.

Static salted examples:

foobar123 = ae2d699aca20886f6bed96a0425c6168
password123 = 482c811da5d5b4bc6d497ffa98491e38
thesearebadpasswords123 = 549e1e8f4fc229265e24f8f9da679d22

Now the values are different. Unfortunately, with static hashing, cyber-attackers can easily just utilize additional "guessing" of your static hash and just "add it" to their hash calculating tools relatively easily.

Dynamically Salting Credentials

It's imperative that the attackers never find out what your salt is to be able to "crack" any password hashes they may retrieve if they should compromise your account or service. But what is a developer to do when you don't want to use the same salt everywhere? Or what about the issues of storing unique salts per user account in a separate database that may also be compromised? Create your own dynamic salts based on various aspects of user record metadata and other attributes.

Example, if a typical user table looks something like this:

UserName, First, Last, Creation Date, PasswordHash, User Active? (Y/N)
VictimUser, Bonnie, Clyde, 01/01/1970, 3858f62230ac3c915f300c664312c63f, Y

couldn't you use aspects from the various fields to make that your salt? Since each user usually is "unique", then anything you use as an additional input is a new salt value. Obviously, you'll want to make this complex enough where attackers can't simply "guess" your salting function easily. So if you create a salting function that says use the string: "Username" + "Account Creation Date" + "Length of Original Entered Password (foobar = 6)" then the salt really turns into something like this: VictimUser01/01/19706

Now let's combine the salt with our original password, “foobar” and here we go for our new salted credentials:

foobarVictimUser01/01/19706 = ac3b9718b592734058659efd3f46ec2a

This would obviously change even if we had everything the same and the only thing different was that we had a 2nd user named VictimUser2. All other items are equal and so we get a new unique salted credential:

foobarVictimUser201/01/19706 = 63a3de523e031237c9e959fb246b90a2

Completely different credential hashes and now you've made the cyber-attacker at the very minimum have to figure out your salting mechanism and creation a function based on that. All of these hashes are based off the MD5 hashing mechanism.

Users/Learners: If you would like to see a coding example of how this is all demonstrated in practice, please visit https://github.com/dc401/Dynamic-Salting-Example and download and run DynamicSalting.exe.

Developers: If you would like to see the source code, the solution file is also there as it was made in VB .NET.

This article was originally published on LinkedIn. You can find it here: LinkedIn

Dennis Chow is an IT Security Practitioner that has over 10 years in various positions in the Information Technology with 6 years in IT Security specific roles. He is currently a Senior Security Engineer at the world’s largest medical center. Dennis also performs part-time consulting and trains new security analysts in the field. Currently, Dennis focuses much of his time performing penetration testing and other security operations. Dennis currently holds several industry recognized certifications including: GCFA, GCIH, GCIA, GPPA, C|EH, E|CSA, L|PT, and the CISSP.