Encrypting Form Submissions #Episerver.Forms

GDPR encourage you to secure personal data, with encryption where it is appropriate, Episerver Forms provides that, but what way to go? This is my evaluation.

icon of user profile

Published 1st December 2017
Episerver Forms version > 4.6

I wanted to evaluate the different alternatives when wanting to encrypt submission data from Episerver Forms. So I tried out the default implementation suggested from Episerver, which is officially documented here.

Out of the box solution – Alt 1

Briefly explained, the official out of the box solution takes all form data field and encrypt each field to the database. Then by roles permission, restrict the “submission” view. Still even if the view is restricted, the submissions are encrypted in the view, and the only way to decrypt the data is selecting the export format “Decrypt csv”.

The submission view is encrypted even if same user can export the data, probably because of time-consuming operations when decrypting.

It is using Azure Key Vault to securely store the crypt key, here is my step by step guide how to configure a secret string in Azure Key Vault. Maybe a good thing if you´re already in the Azure Cloud, and have the Azure Cloud infrastructure in place. But not necessary, you can implement your own encryption engine with your own key storage.

This solutions have some drawbacks

  1. Is it only on or off, for all forms on your site(s).
  2. You can not choose to only encrypt some fields, on some forms
  3. Fieldtype like Number, can not be encrypted
  4. Why isn’t the submission view decrypted, since it is restricted
  5. As a WebAdmin, you can easily obtain forms role and export the decrypted data

Alternative solution – Alt 2

This is my favorite and recommendation, EMVP Daniel Ovaska blogged about his solution on Episerver World. Thanks to Episerver following SOLID principles, almost every service/engine is replaceable with your own (where it is implemented right, not always the case). This opens up for some easy customization.

Briefly explained, you override the input fields of choice and decorate them with an EncryptedForms attribute, these fields then get en-/decrypted when used in form of choice. Same as Alt 1, you can restrict access to submission view with roles, explained here (bottom page).

I like this better since the form editor is in charge to decide what fields/forms to be encrypted.

In my implementation I implemented three Element blocks, email, textbox, textarea, and that’s enough since we want to protect any personal data, where data can be coupled with a user.

Conclusion

Pros ALT 1 and 2

  • You can implement your crypto engine of choice
  • Configurable which role can administer submissions

Pros ALT 1

  • Strong encryption by default (with a 32bit key)

Pros ALT 2

  • Configurable on website level what kind of fields that are Encrypted or not
  • Forms editor decides which fields and forms should be encrypted
  • Data is decrypted in submission view and can be exported in all formats

Consider decoupling the submission data to an other database

It can be a good architectual point to separate the user submission data from the Episerver database. So it is not copied to other environments when synchronising to staging/dev.

Read about how here: http://world.episerver.com/documentation/developer-guides/forms/creating-new-data-storage-mechanism/

RESOURCES

SEO TERMS

  • Encrypting submitted data
  • How to encrypt submissions