Personal Data Encryption (PDE)
Zenario supports the encryption of personal data at rest, while that data is stored in Zenario's database.
Password Encryption
All versions of Zenario support one-way encryption (also known as hashing) for passwords, for both User Accounts and Administrator Accounts.
Both kinds of passwords are hashed using an SHA256 algorithm and salted using a different randomly generated "salt" for each user account. The salt is stored in the database.
There is no way to decrypt a password field. When a user or administrator comes to log in to Zenario, the password they enter is encrypted and compared with the stored string.
If a user or administrator loses their password, Zenario cannot remind them of the stored password. It can only generate a link and send it to them by email, so that they can create a new password.
Personal Data Encryption
Personal data such as users' email addresses, names, addresses and other text-type fields can be encrypted using a two-way encryption method.
Zenario uses an implementation of the Defuse php-encryption library. This system is currently only make available to Tribal-hosted customers.
The encryption method used is AES256-CTR.
This can be used to encrypt the values of columns when they are saved to the database, and decrypt the values of columns on the fly when they are read from the database. We often refer to this as "two-way encryption" to distinguish this from the one-way encryption/hashing used for passwords.
When two-way encryption is enabled for a column, the decrypted value is never stored in the database. Both the encryption and the decryption of the column requires the values of two encryption keys, and the values of these keys are stored in the filesystem and not in the database.
Limitations
The two-way encryption system has a deliberate limitation in that the encrypted strings have a many-to-one relationship with the original string. In other words, for any given original string, many encrypted strings are possible. This makes it hard to run a search in the database for rows matching some input.
So for example, if you have a users table storing first names in encrypted form, it is hard to run a search for a user with a given name.
To get around this, in many database designs, where there is a column with a two-way encrypted form, it's also helpful to have a one-way encrypted form as well (i.e. hashed, like passwords). Then when a search is run, the entered string can be hashed, and the matching rows found from the hashed value rather than the two-way encrypted value.
This makes searching on encrypted columns possible, although it does require the entire string to be matched (such as an entire first name), and it's not possible to run a "starts with" or "includes" text search. In the first name example, a search for "Kath" would only return records which exactly match "Kath", and not "Kat" or "Katherine".
Keys
Zenario's encryption system relies on two keys: there is a server-wide key, and a second key for the client site. Only with a combination of the two keys can data be encrypted or decrypted.
It is preferred that the MySQL database of a Zenario site that uses PDE is on a different server from the web server. In this way, an intruder gaining access to the database (either by breaking in to the database server, or by getting hold of a database backup) would not automatically have access to the keys.
Practicalities
Zenario's core technology allows for any text field in the database to be encrypted. We typically use it for the users table (which stores data on extranet users and contacts), and on the consents table (which stores a log of people giving their consent to have their data stored).
However, use of PDE can be much wider, and any Zenario modules or its plugins can use encryption. Thus a custom application could be made to use encryption, even if it's not strictly personal data.
The system only currently works on textual columns, and not columns that contain foreign keys, i.e. IDs of rows in other tables that are joined.
