@mindgrep/prisma-deterministic-search-field-encryption v0.0.4

Installation

$ yarn add @mindgrep/prisma-deterministic-search-field-encryption
# or
$ npm i @mindgrep/prisma-deterministic-search-field-encryption

Note: this requires Prisma 3.8.0 or higher.

Usage

1. Add the middleware to your Prisma client

import { PrismaClient } from '@prisma/client'
import { fieldEncryptionMiddleware } from '@mindgrep/prisma-deterministic-search-field-encryption'

export const client = new PrismaClient()

// This is a function, don't forget to call it:
client.$use(fieldEncryptionMiddleware())

Tip: place the middleware as low as you need cleartext data.

Any middleware registered after field encryption will receive encrypted data for the selected fields.

2. Setup your configuration

You can use your own encrypt/decript functions and logic:

2.1. Using your own encrypt/decript functions

You must define your encryp/decrypt functions and pass then directly in the middleware config.

The following example shows using the native nodejs crypto module to perform encryption and decryption:

import crypto from 'crypto'

function cipher(decrypted: unknown): string {
  const cipher = crypto.createCipheriv(
    'aes-256-gcm',
    process.env.CRYPTO_SALT,
    process.env.CRYPTO_IV
  )
  return cipher.update(decrypted, 'utf-8', 'hex')
}

function decipher(encrypted: string): unknown {
  const decipher = crypto.createDecipheriv(
    'aes-256-gcm',
    process.env.CRYPTO_SALT,
    process.env.CRYPTO_IV
  )
  return decipher.update(encrypted, 'hex', 'utf-8')
}

client.$use(
  fieldEncryptionMiddleware({
    encryptFn: (decrypted: unknown) => cipher(decrypted),
    decryptFn: (encrypted: string) => decipher(encrypted)
  })
)

Note: a valid encrypt function must always receive a value(it can be any valid DB data) and return a encrypted string. The opposite is valid for the decryption function.

3. Annotate your schema

In your Prisma schema, add /// @encrypted to the fields you want to encrypt:

model Post {
  id        Int     @id @default(autoincrement())
  title     String
  content   String? /// @encrypted <- annotate fields to encrypt
  published Boolean @default(false)
  author    User?   @relation(fields: [authorId], references: [id], onDelete: Cascade, onUpdate: Cascade)
  authorId  Int?
}

model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String? /// @encrypted <- can be optional
  posts Post[]
}

Tip: make sure you use a triple-slash. Double slash comments won't work.

4. Regenerate your client

Make sure you have a generator for the Prisma client:

generator client {
  provider = "prisma-client-js"
}

Then generate it using the prisma CLI:

$ prisma generate

You're done!

Custom Prisma Client Location

If you are generating your Prisma client to a custom location, you'll need to tell the middleware where to look for the DMMF (the internal AST generated by Prisma that we use to read those triple-slash comments):

import { Prisma } from '../my/prisma/client'
prismaClient.$use(
  fieldEncryptionMiddleware({
    dmmf: Prisma.dmmf
  })
)

Caveats & Limitations

You can only encrypt String fields.

Raw database access operations are not supported.

Adding encryption adds overhead, both in storage space and in time to run queries, though its impact hasn't been measured yet.

How Does This Work ?

The middleware reads the Prisma AST (DMMF) to find annotations (only triple-slash comments make it there) and build a list of encrypted Model.field pairs.

When a query is received, if there's input data to encrypt (write operations), the relevant fields are encrypted. Then the encrypted data is sent to the database.

Data returned from the database is scanned for encrypted fields, and those are attempted to be decrypted. Errors will be logged and any unencrypted data will be passed through, allowing seamless setup.

The generated data migrations files iterate over models that contain encrypted fields, record by record, using the interactiveTransaction preview feature to ensure that a record is not overwritten by other concurrent updates.

Because of the transparent encryption provided by the middleware, iterating over records looks like a no-op (reading then updating with the same data), but this will take care of:

• Encrypting fields newly /// @encrypted
• Rotating the encryption key when it changed
• Decrypting fields where encryption is being disabled with /// @encrypted?readonly. Once that migration has run, you can remove the annotation on those fields.

Do I Need This ?

Some data is sensitive, and it's easy to give read access to the database to a contractor or have backups end up somewhere they shouldn't be.

For those cases, encrypting the data per-field can make sense.

An example use-case is Two Factor authentication TOTP secrets: your app needs them to authenticate your users, but nobody else should have access to them.

Cryptography

Cipher used: AES-GCM with 256 bit keys.

Obligatory Disclaimer About Passwords

🚨 DO NOT USE THIS TO ENCRYPT PASSWORDS WITHOUT ADDITIONAL SECURITY MEASURES 🚨

Passwords should be hashed & salted using a slow, constant-time one-way function. However, this library could be used to encrypt the salted and hashed password as a pepper to provide an additional layer of security. It is recommended that the encryption key be stored in a Hardware Security Module on the server.

For hashing passwords, don't reinvent the wheel: use Argon2id if you can, otherwise scrypt.

License

MIT - Made with ❤️ by François Best

Using this package at work ? Sponsor me to help with support and maintenance.