18.8. Encryption options
PostgreSQL provides several different levels of encryption, and provides high flexibility in protecting data from leaks due to database server theft, unethical administrators, and insecure networks. Encryption may also be required to protect sensitive data such as medical records or financial transactions.
Password encryption
The passwords of database users are all stored in a hash (depending on the password_encryption configuration), so the administrator cannot limit the actual password to the user. If SCRAM or MD5 encryption algorithms are used for client authentication, it is impossible for the unencrypted password to even appear on the server, because the client has already been encrypted before sending the password over the network. SCRAM is recommended because it is an Internet standard and is more secure than the PostgreSQL specific MD5 authentication protocol.
The specified column encryption
pgcrypto module allows encrypted storage of specific domains. This function is only useful for certain sensitive data. The client provides the decryption key, and then the data is decrypted on the server and sent to the client.
When the data is decrypted and transferred between the server and the client, the decrypted data and decryption key will exist on the server for a short period of time. This provides a short period of time to intercept keys and data for those who have full access to the database server, such as system administrators.
Data partition encryption
Storage encryption can be performed at the file system level or at the block level. Linux file system encryption options include eCryptfs and EncFS, while FreeBSD uses PEFS. Fast level or full-disk encryption options include dm-crypt + LUKS on Linux and GEOM modules geli and gbde on FreeBSD. Many other operating systems also support this feature, including Windows.
This mechanism prevents unencrypted data from being read from the drive if the entire computer or drive is stolen. It cannot prevent attacks when the file system is mounted, because after mounting, the operating system provides a decrypted view of the data. However, to mount the file system, you need some way to pass the encryption key to the operating system, and sometimes this key is stored somewhere on the host where the disk is mounted.
Encrypting data across networks The
SSL connection encrypts all data sent across networks: passwords, queries, and returned data. The pg_hba.conf file allows the administrator to specify which hosts can use non-encrypted connections (host), and which hosts need to use SSL encrypted connections (hostssl). Clients can also specify that they only connect to the server via SSL. We can also use Stunnel or SSH to encrypt the transmission.
SSL host authentication
Both the client and the host can provide SSL certificates to each other. This requires some additional configuration on both sides, but this approach provides stronger authentication than just using a password. It avoids a computer pretending to be a server, and the duration is long enough to read the password sent by the client. It also avoids "man-in-the-middle" attacks, in which there is a computer between the client and the server and pretending to be the server to read and transmit all data between the two.
Client-side encryption
If the system administrator of the machine where the server is located is not trusted, then client-side encryption of data is also necessary. In this case, the unencrypted data never appears on the database server. Data is encrypted before being sent to the server, and database results must be decrypted on the client before they can be used.