16.7. Options de cryptage

Par défaut, les mots de passe des utilisateurs de la base de données sont stockées suivant des hachages MD5, donc l'administrateur ne peut pas déterminer le mot de passe affecté à l'utilisateur. Si le cryptage MD5 est utilisé pour l'authentification du client, le mot de passe non crypté n'est jamais présent temporairement sur le serveur parce que le client le crypte en MD5 avant de l'envoyer sur le réseau. MD5 est un cryptage à sens unique — il n'existe pas d'algorithme de décryptage.

La bibliothèque de fonctions /contrib pgcrypto autorise le stockage crypté de certains champs. Ceci est utile si seulement certaines données sont sensibles. Le client fournit la clé de décryptage et la donnée est décryptée sur le serveur puis elle est envoyée au client.

La donnée décryptée et la clé de déchiffrement sont présente sur le serveur pendant un bref moment où la donnée est décryptée, puis envoyée entre le client et le serveur. Ceci présente un bref moment où la données et les clés peuvent être interceptées par quelqu'un ayant un accès complet au serveur de bases de données, tel que l'administrateur du système.

Sur Linux, le chiffrement peut se faire au niveau du montage d'un système de fichiers en utilisant un << périphérique loopback >>. Ceci permet à une partition entière du système de fichiers d'être cryptée et décryptée par le système d'exploitation. Sur FreeBSD, la fonctionnalité équivalent est appelé << GEOM Based Disk Encryption >>, ou gbde.

Ce mécanisme empêche la lecture de données non cryptées à partir des disques si ceux-ci ou le serveur sont volés. Ce mécanisme ne protège en rien contre les attaques quand le système de fichiers est monté parce que, dans ce cas, le système d'exploitation fournit une vue non cryptée des données. Néanmoins, pour monter le système de fichiers, vous avez besoin de passer la clé de cryptage au système d'exploitation et, quelque fois, cette clé est stocké quelque part sur l'hôte qui monte le disque.

La méthode d'authentification MD5 crypte deux fois le mot de passe sur le client avant de l'envoyer au serveur. Il le crypte tout d'abord à partir du nom de l'utilisateur puis il le crypte à partir d'un élément du hasard envoyé par le serveur au moment de la connexion. Cette valeur, deux fois cryptée, est envoyée sur le réseau au serveur. Le double cryptage empêche non seulement la découverte du mot de passe, il empêche aussi une autre connexion en rejouant la même valeur de double cryptage dans une connexion future.

Les connexions SSL cryptent toutes les données envoyées sur le réseau : le mot de passe, les requêtes et les données renvoyées. Le fichier pg_hba.conf permet aux administrateurs de spécifier quels hôtes peuvent utiliser des connexions non cryptées (host) et lesquels requièrent des connexions SSL (hostssl). De plus, les clients peuvent spécifier qu'ils se connectent aux serveurs seulement via SSL. Stunnel ou SSH peuvent aussi être utilisés pour crypter les transmissions.

Il est possible que le client et le serveur fournissent des clés SSL ou des certificats à l'autre. Cela demande une configuration supplémentaire de chaque côté mais cela fournit une vérification plus forte de l'identité que la simple utilisation de mots de passe. Cela empêche un ordinateur de se faire passer pour le serveur assez longtemps pour lire le mot de passe envoyé par le client. Cela empêche aussi les attaques du type << man in the middle >> où un ordinateur, entre le client et le serveur, prétend être le serveur, lit et envoie les données entre le client et le serveur.

Si vous n'avez pas confiance en l'administrateur système, il est nécessaire que le client crypte les données ; de cette façon, les données non cryptées n'apparaissent jamais sur le serveur de la base de données. Les données sont cryptées sur le client avant d'être envoyé au serveur, et les résultats de la base de données doivent être décryptés sur le client avant d'être utilisés. Le livre de Peter Wayner, [Translucent Databases], parle de cela de façon très détaillé.