Background Image
TECHNOLOGIE

Comprendre l'authentification SCRAM SHA-256 dans MongoDB

Norman Jordan
Développeur de personnel

December 6, 2023 | 6 Lecture minute

La prise en charge par MongoDB de différents mécanismes d'authentification vous permet de choisir celui qui convient le mieux à votre application. SCRAM SHA-256 est un excellent choix, mais il peut être un peu difficile à comprendre, c'est pourquoi nous allons voir ce qui se passe sous le capot. Considérons une application qui agit à la fois comme un serveur MongoDB et de serveur. L'un des défis intéressants auxquels j'ai été confronté lors de la création de cette application est ce qui se passe lorsque les utilisateurs sont authentifiés. L'application doit à la fois authentifier les clients qui se connectent à elle et s'authentifier auprès des serveurs MongoDB.

L'utilisation de mécanismes sécurisés pour authentifier les utilisateurs est très importante car les bases de données MongoDB peuvent contenir des informations sensibles. MongoDB prend en charge une variété de mécanismes d'authentification, dont l'un est appelé SCRAM SHA-256. SCRAM SHA-256 est le mécanisme par défaut de MongoDB. Il s'agit d'un mécanisme d'authentification puissant, doté de fonctionnalités permettant de prévenir les types d'attaques les plus courants. Le client et le serveur sont en mesure de prouver qu'ils connaissent le mot de passe de l'utilisateur sans l'exposer l'un à l'autre. Il permet également de prévenir les attaques par rejeu.

Ce guide vous donnera un aperçu du fonctionnement de l'authentification SCRAM SHA-256 dans MongoDB. Il couvrira le flux de messages entre un client et un serveur. En outre, il expliquera chaque message et ce qui est nécessaire pour les construire.

Le flux d'authentification comprend quatre messages.

Image 1 - Making Sense of SCRAM SHA-256 Authentication in MongoDB 

1. Client first - le client envoie le nom d'utilisateur et une valeur aléatoire au serveur.

2. Serveur d'abord - le serveur envoie le sel, le nombre d'itérations et une valeur aléatoire au client.

3. Finale du client - le client calcule sa preuve du mot de passe et l'envoie au serveur. Si la preuve du client a été acceptée par le serveur, ce dernier considérera le client comme authentifié pour les demandes ultérieures.

4. Finale du serveur - si la preuve du client est valide, le serveur calcule sa preuve du mot de passe et l'envoie au client.

Définitions

  • Nonce du client - un code Base64 de 24 octets aléatoires choisis par le client.

  • Nonce du serveur - une chaîne de 24 octets aléatoires codée en Base64 de 24 octets aléatoires choisis par le serveur.

  • Salt - une chaîne de 24 octets aléatoires codée en Base64 des octets utilisés pour le hachage du mot de passe de l'utilisateur.

  • Itérations - Nombre d'itérations à utiliser pour le hachage du mot de passe de l'utilisateur.

  • Client Proof (Preuve du client) : valeur calculée par le client pour montrer qu'il possède le mot de passe de l'utilisateur.

  • Server Proof - Valeur calculée par le client pour montrer qu'il possède le mot de passe de l'utilisateur (ou un hachage de celui-ci).

  • h(v) - une valeur SHA-256 du tableau d'octets (v)

  • hmac(k, v) - un algorithme HMAC SHA-256 du tableau d'octets (v) en utilisant la clé (k)

Premier message du client

Le premier message du client est utilisé pour indiquer au serveur de lancer le processus d'authentification. Ce message comprendra un message speculativeAuthenticate spéculatif avec une charge utile valeur. L'objet charge utile est du format :

n,,n=<username>,r=<client nonce>

  • username - le nom d'utilisateur de l'utilisateur à authentifier

Le client doit conserver le nonce client pour l'utiliser ultérieurement.

La valeur à utiliser pour la charge utile est l'octet binaire UTF-8 de la chaîne ci-dessus.

Premier message du serveur

Le serveur utilise le premier message du serveur pour envoyer au client des paramètres générés par le serveur. Comme pour le premier message du client, le message comprendra un élément speculativeAuthenticate spéculatif avec une charge utile valeur. L'objet charge utile a le format suivant

r=<client nonce><server nonce>,s=<salt>,i=<iterations>

Le serveur doit conserver ces valeurs pour l'utilisateur par la suite.

La valeur à utiliser pour la charge utile est l'octet binaire UTF-8 de la chaîne ci-dessus.

Message final du client

Le client génère la preuve du mot de passe et l'envoie au serveur. Le message comprendra un charge utile valeur. La valeur charge utile a le format suivant

c=biws,r=<client nonce><server nonce>,p=<client proof>

  • c=biws - biws est l'encodage Base64 de la chaîne "n,,". Cette valeur ne change jamais.

Calcul de la preuve de l'existence d'un client

Cette étape peut être décomposée en plusieurs valeurs différentes qui sont calculées et utilisées pour produire la preuve de l'identité du client. Le message d'authentification est également nécessaire plus tard pour vérifier que le serveur possède le mot de passe de l'utilisateur.

Hachage du mot de passe salé 

1. Créer une clé secrète HMAC SHA-256 à partir des octets UTF-8 du mot de passe de l'utilisateur.

2. Base64 décode la valeur du sel pour obtenir un tableau d'octets

3. Calculer le hachage salé du mot de passe. Nécessité de faire ceci itérations fois.  

iv = salt_bytes + [0, 0, 0, 1]
result = hmac(secret_key, iv)
previous = null
for (i = 1; i < iterations; i++) { 
    if (previous == null) { 
        previous = hmac(secret_key, result) 

    } else { 
        previous = hmac(secret_key, previous) 
    } 
    result = result ^ previous 
} 

4. Encodage Base64 de la valeur du résultat pour obtenir le hachage salé du mot de passe.

Le serveur peut stocker le hachage du mot de passe salé plutôt que le mot de passe brut.

Clé du client 

1. Créer une clé secrète HMAC SHA-256 à partir du hachage du mot de passe salé.

2. Calculer le hachage de la chaîne fixe ("Clé du client") à l'aide de la clé pour obtenir la clé du client

clé_client = hmac(clé_secrète, "Clé_client ".getBytes())

Message d'authentification 

Créez une chaîne de caractères contenant les paramètres d'authentification. C'est ce qu'on appellera le message d'authentification. Cette chaîne tient sur une seule ligne.

n=<username>, 
r=<client nonce>, 
r=<client nonce><server nonce>, 
s=<salt>, 
i=<iterations>, 
c=ibws, 
r=<client nonce><server nonce> 

Clé stockée 

Calculer le hachage SHA-256 de la clé du client. Cette clé sera appelée clé stockée.

clé_stockée = h(clé_client)

Signature du client 

1. Créer une clé secrète HMAC SHA-256 à partir de la clé stockée.

2. Calculer le hachage du message d'authentification pour obtenir la signature du client

signature_du_client = hmac(clé_secrète, message_d'authentification)

Preuve du client 

1. Calculer le OU exclusif de la clé du client et de la signature du client. Les deux tableaux d'octets ont la même taille.

preuve_client = clé_client ^ signature_client

2. Encodez Base64 la preuve du client pour obtenir la valeur à envoyer au serveur.

Message final du serveur

Le serveur vérifie la preuve du client et calcule la preuve du serveur. Le message comprendra une charge utile la valeur. La valeur charge utile est du format :

v=<server proof>

1. Créer une clé secrète HMAC SHA-256 à partir du hachage salé du mot de passe.

2. Calculer le hachage de la chaîne fixe ("Server Key") en utilisant la clé pour obtenir la clé du serveur

server_key = hmac(secret_key, "Server Key ".getBytes())

3. Calculer le hachage du message d'authentification pour obtenir la signature du serveur

signature_serveur = hmac(clé_serveur, message_authentification)

4. Encodage Base64 de la signature du serveur pour obtenir la preuve du serveur

Vous avez maintenant une vue d'ensemble des détails de l'authentification SCRAM SHA-256 dans MongoDB. Vous avez les connaissances nécessaires pour mettre en œuvre l'authentification SCRAM SHA-256 dans vos clients et serveurs compatibles avec MongoDB.

La prise en charge par MongoDB de divers mécanismes d'authentification vous permet de choisir celui qui convient le mieux à votre application. SCRAM SHA-256 est un excellent choix en raison de sa capacité à protéger le mot de passe de l'utilisateur et de sa protection contre les attaques par rejeu de message.

Au fur et à mesure de votre développement, une compréhension plus approfondie de SCRAM SHA-256 peut servir de base utile pour concevoir des mécanismes d'authentification dans vos applications. Bon codage !

Prêt à vous lancer dans le codage avec Improving ? Pour en savoir plus, cliquez ici.

Technologie

Dernières réflexions

Explorez nos articles de blog et laissez-vous inspirer par les leaders d'opinion de nos entreprises.
Asset - Multi-Cloud Strategies for Developers image 2
NUAGE

Exploiter SAP Analytics Cloud grâce à des widgets personnalisés

Exemple SAP de widget personnalisé