47ng/prisma-field-encryption

Feature request: HMAC Support for Hashing

Closed this issue · 5 comments

ilim0t commented

Upon reviewing the hashing portion of the current code, I noticed that it does not include support for HMAC.

const hash = crypto.createHash(config.algorithm)

To fortify the security capabilities of the library, I propose the addition of an option to use HMAC.
(Perhaps use: crypto.createHmac)

Benefits:

  1. Implementing HMAC support enhances security. HMAC is notably known for its strengths in terms of security for data integrity and authentication.
  2. It increases versatility for users in terms of their choice of hashing methods.

If there's a demand for this feature, I would be more than happy to create a pull request to implement it.

Please share your thoughts and feedback regarding this proposal.

Edit: sorry, I misread HMAC as HKDF, please disregard my previous comment about KDFs.

The only valid reason I can think of for using HMAC here is its keyed property. This would allow separating values across rows by specifying domain-separation keys. A dedicated keyed hash algorithm would be more suitable, but I don't think the crypto.createHashmethod supports providing a key, even if the underlying algorithm would support it.

Using a keyed hash could be interesting for multi-tenant applications, to guarantee isolation of identical values across tenants. For example: an email of foo.bar@example.com on two tenant instances would result in different hashes if keyed with different tenant-specific keys.

This raises the problem of "how to specify the key", as the hash operation is currently independent from the data it's applied to.

ilim0t commented

As you pointed out, the use of HMAC is indeed greatly beneficial for multi-tenant applications. However, I believe that its implementation can also enhance security even in a single-tenant environment.

By using a single key to generate the HMAC, it becomes highly effective in enhancing security, such as preventing unauthorized tampering.

In light of these considerations, how about initially implementing an option to generate HMAC using a single key?

By using a single key to generate the HMAC, it becomes highly effective in enhancing security, such as preventing unauthorized tampering.

I'm not sure I follow your reasoning here. Could you describe your threat model please?

Anyway, I'll happily review a PR if you want to have a go at implementing it.

ilim0t commented

Thank you for your reply.

I think the proposal for HMAC can address the threat model outlined below:

Consider a scenario where a large number of hash values from the database are leaked.
With the use of a conventional hash function, adversaries could conduct offline brute force attacks, or utilize rainbow tables to retrieve the plaintext.

However, when utilizing HMAC, unless the secret key is leaked, conducting these attacks becomes significantly challenging for attackers. As long as the secret key remains secure, the safety of the data is further enhanced.

If salting the hash is what you're after, this is already supported by the library, see the documentation.