Is there a hashing algorithm that allows me to specify output character length?

Question

My security officer is looking for a hashing algorithm that will take a string of up to 20 characters, and then output a unique, 12-character alphanumeric hash. The 20-character string is generally just going to be numbers (okay, I'll tell you, it's credit card numbers) so it seems compressible to me.

Probably he'd have more of a comfort level if it's something that's publicly available and tested, but my research thus far suggests that popular hashing algorithms have generally fixed length outputs (or variable outputs, but to specific predetermined lengths).

Answer 1

Watch out when you handle credit card numbers!

Just adhere to the standards and laws that apply in your area, or are given by your security officer. If you really need to do this then make sure that you reconsider your design, you really don't want to pass a credit card number around your code or have credit card numbers collide because of hashing.

That's asking for trouble sooner or later...

A credit card number should have a very short time to live in your code, use it for the payment and no more than that. At best you can store a trimmed version of it, for display purposes only. But don't use it in cases were its hashes would collide or in a way that the original can be retrieved, and if you somehow really need to do so make sure you have a good hashing and/or security system, that no collisions are possible and you are able to contact all customers when your database / software security has been breached.

Answer 2

There shouldn't be any reason for a merchant to store a full credit card number, hashed or not.

I think you really need to evaluate why you need to do this.

If you're storing credit card numbers, the number space may be small enough that brute-forcing the hash is plausible, making storing even this hash dangerous and probably in violation of PCI.

There's almost certainly a better solution that's going to allow you to solve the real problem you're facing.

Answer 3

If your input is a 20-digit number, then there are 10²⁰ possible inputs.
If your output is a 12 character alphanumeric string, then there are 62¹² possible outputs.

Inputs:

100000000000000000000

Outputs:

3226266762397899821056

If we look closely, we see the bottom number is longer.
Which means there are more possible outputs than inputs.
Which means the hashing is pointless as every possible output can be mapped directly to one input. So that means it would be incredibly easy to break and get the actual numbers back.

So, we'll just use a shorter hash!

What's the point? Just use an integer, a random one if you have to.

---

Let's take passwords as an example.
You never store a password. You only store the hash. That makes it easy to check a given input against that hash (to see if the provided password is correct) without ever storing the actual password.

This works because:

1. our hashing algorithms don't produce the same hash for two inputs easily (collisions unlikely)
2. it is unreasonable to assume that someone could figure out the original input for a given hash

And why is that? Well, the password I used could be 1,000,000 characters long. How are you gonna figure that out from a short hash? You can't. You can only try to calculate as many hashes as you can, compare them to the one you have and hope for a match. In this case it usually isn't even relevant to find the actual, original input as any input that produces the same hash will work.

So, if I'm an attacker and I got a hold of the database with the hashes, I could compare the hashes to a set I previously computed to find a valid input for that hash. This is usually countered by salting your hashes.

So an attacker would be forced to brute-force so long until he found a valid input for a matching hash (which would take forever, because there's an insane amount of possible hashes).

But what if the passwords were limited to a certain length and they could only contain numbers?
This drastically reduces the possible inputs and, thus, the time it would take to brute-force a matching hash.
And that's basically what you're doing when hashing credit card numbers. But it's worse because if the attacker got a match, then it's not just going to be an arbitrary string but, most likely, a valid credit card number!

Answer 4

Ignoring all of the questions above, there's a really, really, blindingly simple solution.

In pseudocode:

function my_hash(string data, int length){
    string t = md5sum(data);
    return t.substring(0,length)
}

Or sha512 sum or whatever strikes your fancy. Personally I recommend multiple rounds of blowfish. If someone grabs the database, and knows how you've created this hash, they can simple run through the space of all CC numbers as well and compare data to reverse it. This is bad.

However, beware. Read all of the other answers, they all have very valid points.