Return to Answer

You could simply use an HMAC: HMACs have two inputs, a message and an encryption key, and produce a message authentication code, which is basically a hash (e.g. you can't turn the MAC back into the message, or the key, or both). So in your case you'd have:

token = hmac(account_num, key)

HMAC is constructed in a special way to protect against attacks that might reveal the key. It's a well-understood cryptographic primitive.

Without knowing the key, a brute force attack on the token to get the account number isn't practical. OTOH, for you, knowing the key, it's trivial to turn an account number into a token.

Of course, now the security of your account numbers rests with the security of the key; so if you lose the key and the list of tokens to an attacker, you've opened your account numbers to brute force attacks. But your idea number 4 suffers from the same problem.

You could simply use an HMAC: HMACs have two inputs, a message and an encryption key, and produce a message authentication code, which is basically a hash (e.g. you can't turn the MAC back into the message, or the key, or both). So in your case you'd have:

token = hmac(account_num, key)

HMAC is constructed in a special way to protect against attacks that might reveal the key. It's a well-understood cryptographic primitive.

Without knowing the key, a brute force attack on the token to get the account number isn't practical. OTOH, for you, knowing the key, it's trivial to turn an account number into a token.

Of course, now the security of your account numbers rests with the security of the key; so if you lose the key and the list of tokens to an attacker, you've opened your account numbers to brute force attacks. But your idea number 4 suffers from the same problem.

It might be a good idea to think about key management, so you can easily change a key if one becomes compromised.

You could simply use an HMAC: HMACs have two inputs, a message and an encryption key, and produce a message authentication code, which is basically a hash (e.g. you can't turn the MAC back into the message, or the key, or both). So in your case you'd have:

token = hmac(account_num, key)

HMAC is constructed in a special way to protect against attacks that might reveal the key. It's a well-understood cryptographic primitive.

Without knowing the key, a brute force attack on the token to get the account number isn't possible. OTOH, for you, knowing the key, it's trivial to turn an account number into a token.

Of course, now the security of your account numbers rests with the security of the key; so if you lose the key to an attacker, you've opened your account numbers to brute force attacks. But your idea number 4 suffers from the same problem.

You could simply use an HMAC: HMACs have two inputs, a message and an encryption key, and produce a message authentication code, which is basically a hash (e.g. you can't turn the MAC back into the message, or the key, or both). So in your case you'd have:

token = hmac(account_num, key)

HMAC is constructed in a special way to protect against attacks that might reveal the key. It's a well-understood cryptographic primitive.

Without knowing the key, a brute force attack on the token to get the account number isn't practical. OTOH, for you, knowing the key, it's trivial to turn an account number into a token.

Of course, now the security of your account numbers rests with the security of the key; so if you lose the key and the list of tokens to an attacker, you've opened your account numbers to brute force attacks. But your idea number 4 suffers from the same problem.

Maybe you could adjust your idea number 2:

hash(salt + account_num)

What if for every account number you generated a fixed-length string of random bytes, salt, and generated hash(salt || account_num) || encrypt(salt)? (|| meaning concatenation)

Now the hash can't be brute-forced to yield account_num because salt isn't available except for those who know the encryption key.

If you need to select by account number, you use your encryption key to decrypt the salt, then hash the account number with the decrypted salt to get the token.

Now instead of using some half-baked scheme like what I just described, whose security properties aren't clearly known, you could simply use an hmac: HMACs have two inputs, a message and an encryption key, and produce a message authentication code, which is basically a hash (e.g. you can't turn the MAC back into the message, or the key, or both). So in your case you'd have:

token = hmac(account_num, key)

HMAC is constructed in a special way to protect against attacks that might reveal the key, so I'd suggest using well-studied HMAC instead of rolling a scheme like the one I presented above.

Again, without knowing the key, a brute force attack on the token to get the account number isn't possible. OTOH, for you, knowing the key, it's trivial to turn an account number into a token.

Of course, now the security of your account numbers rests with the security of the key; so if you lose the key, you've opened your account numbers to brute force attacks. But your idea number 4 suffers from the same problem.

You could simply use an HMAC: HMACs have two inputs, a message and an encryption key, and produce a message authentication code, which is basically a hash (e.g. you can't turn the MAC back into the message, or the key, or both). So in your case you'd have:

token = hmac(account_num, key)

HMAC is constructed in a special way to protect against attacks that might reveal the key. It's a well-understood cryptographic primitive.

Without knowing the key, a brute force attack on the token to get the account number isn't possible. OTOH, for you, knowing the key, it's trivial to turn an account number into a token.

Of course, now the security of your account numbers rests with the security of the key; so if you lose the key to an attacker, you've opened your account numbers to brute force attacks. But your idea number 4 suffers from the same problem.