13.1 Confidential Fields ¶

To specify that a field should be encrypted, use the %confidential special field. This special field declares a set of fields as confidential, meaning they contain secret data such as passwords or personal information. Its usage is:

%confidential: field1 field2 ... fieldN

The field names are separated by one or more blank characters. There can be several %confidential fields in the same record descriptor, the effective list of confidential fields being the union of all the entries.

Declaring a field as confidential indicates that its contents must not be stored in plain text, but encrypted with a password-based mechanism. When the information is retrieved from the database the confidential fields are unencrypted if the correct password is provided. Likewise, when information is inserted in the database the confidential fields are encrypted with some given password.

For example, consider a database of users of some service. For each user we want to store a name, a login name, an email address and a password. All this information is public with the obvious exception of the password. Thus we declare the Password field as confidential in the corresponding record descriptor:

%rec: Account
%type: Name line
%type: Login line
%type: Email email
%confidential: Password

The rec format does not impose the usage of a specific encryption algorithm, but requires that:

• The algorithm must be password-based.
• The value of any encrypted field shall begin with the string ‘encrypted-’ followed by the encrypted data.
• The encrypted data must be encoded in some ASCII encoding such as base64.

The above rules assure that it is possible to determine whether a given field is encrypted. For example, the following is an excerpt from the account database described above. It contains an entry with the password encrypted and another with the password unencrypted:

Name: Mr. Foo
Login: foo
Email: foo@foo.com
Password: encrypted-AAABBBCCDDDEEEFFF

Name: Mr. Bar
Login: bar
Email: bar@bar.com
Password: secret

Unencrypted confidential fields are a data integrity error, and utilities like recfix will report it. The same utility can be used to “fix” the database by massively encrypting any unencrypted field.

Nothing prevents the usage of several passwords in the same database. This allows the establishment of several level of securities or security profiles. For example, we may want to store different passwords for different online services:

%rec: Account
%confidential: WebPassword ShellPassword

We could then encrypt WebPassword entries using a password shared among all the webmasters, and the ShellPassword entries with a more restricted password available only to the administrator of the machine.

Note that since the utilities only accept to specify one password at a time different passwords cannot be specified at decryption time. This means that in the example above the administrator would need to run recsel twice in order to decrypt all the encrypted data in the recfile.

The GNU recutils fully support encrypted fields. See the documentation for recsel, recins and recfix for details on how to operate on files containing confidential fields.