Hashing Basics

I am catching some heat over the Encryption Basics post from some of my more ardent detractors that have called me on the carpet over making security and PCI “too simple” or “dumbed down.”  As I said in that post, it was in no way meant to be a full dissertation on the topic.  This post, as with the previous post, is not a complete dissertation either.  I just want to clarify some things so that people have a reasonable foundation on the topic of hashing.

Hashing comes up in requirement 3.4 which says:

“Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches: one-way hashes based on strong cryptography (hash must be of the entire PAN), truncation (hashing cannot be used to replace the truncated segment of PAN), index tokens and pads (pads must be securely stored), strong cryptography with associated key-management processes and procedures.”

Before we get into hashing algorithms, I need to make sure everyone is clear that hashing is a one-way operation.  Unlike encryption, you cannot reverse data that has been hashed.  So if you are considering using hashing, you need to make sure that you will never need the original information such as a PAN.

Probably the most common one-way hash algorithm is SHA-1.  Unfortunately, it has been proved that SHA-1 has some issues that make it not as secure as its later iteration, SHA-2.  As such, those of you using SHA-1 should be migrating to SHA-2 or another hashing algorithm.  Those of you considering a solution that relies on SHA-1 should be asking the vendor if SHA-2 or another secure algorithm can be used.

The other most common one-way hashing algorithm is RSA’s Message Digest 5 (MD5) algorithm.  Like SHA-1, MD5 has also been deemed no longer acceptable due to a number of issues that make it no longer secure.  As a result, users of MD5 are recommended to migrate to RSA’s MD6, SHA-2 or another hashing algorithm.  And just so you are not confused, MD5 is still commonly used as a way to generate a checksum for confirming the validity of a download which is an entirely different purpose than what I am discussing here.

And to show you that things do not stand still in the cryptographic hashing world, the United States National Institute of Standards and Technology (NIST) is in the process of selecting the winner of their SHA-3 competition.  That winner will be announced sometime in late 2012.

While you can use a hash function “as is,” security professionals typical recommend the addition of a “salt” to complicate the result of the resulting hashed value.  A salt is two or more characters, usually non-displayable binary values, appended to the original value, in our example the PAN.  The salt adds a level of complexity to the resulting hashed value thus making the use of rainbow tables to break hashed values more difficult, if not impossible, to use.

One useful thing you can accomplish with a hashed value is that you can still use it for research as long as you are not using a rotating salt.  That means that the hashed PAN should have the same hashed value every time the same PAN is hashed.  This can be very important for fraud investigators and anyone else that needs the ability to research transactions conducted with the same PAN.  If these people do need the actual PAN, they will have to go to a different system that stores the PAN encrypted or go to their card processor for the PAN.

The PCI DSS issues a warning about using hashing and truncation together.  There is a note in requirement 3.4 that states:

“It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN.  Where hashed and truncated versions of the same PAN are present in an entity’s environment, additional controls should be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.”

This note is more relevant to situations where the truncation is the first six digits AND the last four digits.  However, it brings up a good point regarding all methods of information obscuring including encryption.  Never, ever store the obscured value along with the truncated value.  Always separate the two values and also implement security on the obscured value so that people cannot readily get the obscured value and the truncated value together without oversight and management approval.

Hopefully now we all have a base level knowledge of hashing.


4 Responses to “Hashing Basics”

  1. 1 rosennej
    May 2, 2020 at 3:27 AM

    As far as I know, the weaknesses of SHA-1 are not relevant to hashing the card number or other CHD. They are all about appending or prepending some data, and are not relevant to foxed length, fixed structure data. Please correct me if I am wrong.

    • May 2, 2020 at 7:05 AM

      The problem is entropy of the hash. Remember, you are working with at most 16 to 19 digits of which the first one to three digits are known. SHA-1 with all of its issues does nothing worthwhile to protect anything with so little entropy. That is why you want to use an algorithm that is stronger.

  2. 3 pkfavantedge
    January 26, 2017 at 9:46 AM

    Hi Guru – just had another session with our QSA and they are now insisting that our application needs to have a key encryption key with a checksum to ensure that it isnt tampered. They request our application to run this checksum everytime the KEK is used.

    I question them why do we need this…if the KEK is invalid or unauthenticated (both reasons for checksum), then it cannot be used. There is no statement in PCI that requires key checksum. Is there any directive from PCISSC on this? Why are we required to use key checksums on our KEK? They can’t answer and its simply the case of, “Because we say so” which is total BS.

    • January 28, 2017 at 8:47 AM

      Agreed. You are only required to securely store the KEK away from the data it is used to encrypt. I would get your bank to mediate your problem if you cannot get your QSA to see the light.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

January 2012

%d bloggers like this: