SASL est un framework pour l'authentification dans les protocoles orientés connexion. Actuellement, PostgreSQL implémente seulement le mécanisme d'authentification SASL, SCRAM-SHA-256 et SCRAM-SHA-256-PLUS, mais d'autres pourraient être ajoutées dans le futur. Les étapes suivantes illustrent comment l'authentification SASL est réalisée en général, alors que la sous-section suivant donne plus de détails sur SCRAM-SHA-256 et SCRAM-SHA-256-PLUS.
Flux de message d'authentification SASL
Pour commencer un échange d'authentification SASL, le serveur envoie un message AuthenticationSASL. Il inclut une liste de mécanismes d'authentification SASL que le serveur accepte, dans l'ordre de préférence du serveur.
Le client sélectionne un des mécanismes supportés dans la liste, et envoie un message SASLInitialResponse au serveur. Le message inclut le nom du mécanisme sélectionné, et un message Initial Client Response optionnel, si le mécanisme sélection l'utilise.
Un ou plusieurs messages question-serveur et réponse-client suivent. Chaque question du serveur est envoyée dans un message AuthenticationSASLContinue, suivie d'une réponse du client dans un message SASLResponse. Les particularités des messages sont spécifiques au mécanisme.
Enfin, quand l'échange d'authentification se termine avec succès, le serveur envoie un message AuthenticationSASLFinal, suivi immédiatement d'un message AuthenticationOk. Le message AuthenticationSASLFinal contient des données supplémentaires du serveur pour le client, dont le contenu est spécifique au mécanisme d'authentification sélectionné. Si le mécanisme d'authentification n'utilise pas de données supplémentaires en fin d'authentification, le message AuthenticationSASLFinal n'est pas envoyé.
En cas d'erreur, le serveur peut annuler l'authentification à tout moment, et peut envoyer un message ErrorMessage.
Les mécanismes SASL implémentés pour le moment sont
SCRAM-SHA-256 et sa variante avec le channel
binding SCRAM-SHA-256-PLUS. Ils sont décrits
en détail dans les RFC 7677
et RFC 5802.
Quand SCRAM-SHA-256 est utilisé dans PostgreSQL, le serveur ignorera le nom
d'utilisateur que le client envoie dans le premier-message-
client. Le nom d'utilisateur déjà envoyé dans le message de
démarrage est utilisé à la place. PostgreSQL
supporte plusieurs encodages de caractères alors que SCRAM requiert
l'utilisation d'UTF-8 pour le nom de l'utilisateur.
La spécification SCRAM requiert que le mot de passe soit aussi en UTF-8, et est traité avec l'algorithme SASLprep. Néanmoins, PostgreSQL ne requiert pas que UTF-8 soit utilisé pour le mot de passe. Lors de la configuration du mot de passe d'un utilisateur, ce mot de passe est traité avec SASLprep comme s'il était en UTF-8, quelque soit l'encodage réellement utilisé. Néanmoins, s'il ne s'agit pas d'une séquence UTF-8 légale d'octets ou s'il contient des séquences d'octets UTF-8 interdites par l'algorithme SASLprep, le mot de passe brut sera utilisé sans traitement par SASLprep, plutôt que de renvoyer une erreur. Ceci permet la normalisation du mot de passe quand ce dernier est en UTF-8 mais autorise aussi l'utilisation d'un mot de passe qui n'est pas en UTF-8 et ne nécessite pas que le système connaisse l'encodage utilisé par le mot de passe.
La liaison de canal sécurisé (Channel binding) est
prise en charge lorsque PostgreSQL est construit
avec prise en charge SSL/TLS.
Le nom du mécanisme SASL pour SCRAM avec liaison de canal est
SCRAM-SHA-256-PLUS. Le type de liaison de canal utilisé
par PostgreSQL est tls-server-end-point.
Quand SCRAM est utilisé sans liaison de canal sécurisé
(SSL/TLS), le serveur choisit un nombre aléatoire qui est
transmis au client pour être mélangé avec le mot de passe fourni par
l'utilisateur dans le hachage du mot de passe transmis. Bien que cela empêche
que le mot de passe haché puisse être retransmis avec succès dans une session
ultérieure, cela n'empêche pas un faux serveur entre le serveur réel et le
client de passer par la valeur aléatoire du serveur et de s'authentifier avec
succès (attaque de l'homme du milieu (HDM)).
L'utilisation de SCRAM avec liaison de canaux sécurisé
empêche de telles attaques de l'homme du milieu (HDM) en mélangeant la
signature du certificat du serveur dans le hachage du mot de passe transmis.
Bien qu'un faux serveur puisse retransmettre le certificat du serveur réel,
n'ayant pas d'accès à la clé privée correspondante au certificat, il ne
pourra pas donc pas prouver qu'il en est le propriétaire provoquant ainsi
l'échec de la connexion SSL/TLS.
Exemple
Le serveur envoie un message AuthenticationSASL. Il inclut une liste de
mécanismes d'authentification SASL que le serveur peut accepter.
Cette liste contient SCRAM-SHA-256-PLUS et
SCRAM-SHA-256 si le serveur est construit avec le support du
SSL ou juste SCRAM-SHA-256 dans le cas contraire.
Le client répond en envoyant un message SASLInitialResponse indiquant le
mécanisme choisi, SCRAM-SHA-256 ou
SCRAM-SHA-256-PLUS. (Un client est libre de choisir l'un
ou l'autre mécanisme, mais pour une meilleure sécurité, il devrait choisir
la variante channel-binding s'il le supporte.). Dans le
champ de réponse Initial Client, le message contient le
client-first-message (premier-message-client) SCRAM.
Le client-first-message contient également le
type de channel-binding choisi par le client.
Le serveur envoie un message AuthenticationSASLContinue, avec un
server-first message SCRAM comme contenu.
Le client envoie un message SASLResponse, avec
client-final-message SCRAM comme contenu.
Le serveur envoie un message AuthenticationSASLFinal, avec
server-final-message SCRAM, immédiatement
suivi d'un message AuthenticationOk.
