Sécuriser son API HTTP (2) (Basic | Digest) Authentication

Leave a Comment

Après avoir posé les fondamentaux dans le précédent article nous allons dans celui-ci nous intéresser à deux méthodes d’authentification à savoir l’authentification basique (HTTP Basic Authentication) et l’authentification “Digest” qui sont assez simples à mettre en oeuvre.

L’authentification basique

L’authentification basique est similaire à ce que font la plupart des sites web lorsqu’ils permettent à leurs utilisateurs de s’authentifier via un formulaire qui récupèrent le couple login/mot de passe. La différence est que dans le cas de l’authentification basique les crédentials sont renseignés dans l’en-tête de la requête HTTP qui est envoyée au serveur donc à votre API. L’en-tête de la requête est formaté de la façon suivante :

Authorization: Basic Base64Encode(login:password)
Pour le couple johndoe:jane doe cela donne :
Authorization: Basic am9obmRvZTpqYW5lIGRvZQ==

En général vous n’avez pas besoin d’encoder à la main l’en-tête de la requête car c’est pris en charge par le client HTPP. Dans l’exemple suivant curl construit le bon en-tête :

curl -i -u johndoe:jane https://api.example.com 

L’encodage en base 64 n’offre aucune sécurité en soi car il suffit de faire l’opération inverse (Base64Decode) pour retrouver les infos en clair. En outre les credentials de l’utilisateur sont envoyés dans chaque requête avec l’authentification basique. Cela accroît le risque d’interception de ces informations sensibles.

Comment améliorer la sécurité de l’authentification basique ? Utiliser HTTPs, veiller à la sécurité du stockage des mots de passe et à la façon dont ils sont récupérés lors de l’authentification. Hacher les mots de passe avant de les stocker permet de faire en sorte qu’ils ne soient connus que des utilisateurs et les protège lorsqu’un attaquant accède au stockage car il ne verra que les haches et non les mots de passe en clair. Cependant pour que tout cela soit efficace vous devez choisir un algorithme de hachage qui ne permette pas de retrouver la donnée initiale à partir du hache. Le hachage des mots de passe est un vaste sujet qui vaut bien un article à lui tout seul.

L’authentification “digest”

L’authentification “digest” a été mise en place pour pallier les limitations de l’authentification basique. Elle n’envoie pas le mot de passe en clair dans la requête mais procède à l’authentification par un échange de challenge/réponse.

Le challenge est envoyé par le serveur en réponse à l’initiation de l’échange par le client. Il contient notamment un “nonce” unique à chaque processus d’authentification Digest et un code qui porte le petit d’”opaque” et doit être retourné au serveur dans la réponse au challenge. Dans sa réponse l’utilisateur spécifie son identité (le paramètre username) et la réponse au challenge posé par le serveur. Cette réponse contient un certain nombre d’informations dont un hache calculé avec l'algorithme MD5 come : Hache = MD5(username:password:realm) Ce hache et le login (username) permettent au serveur d’authentifier l’utilisateur. Cela nécessite cependant que le serveur stocke le hache MD5(username:password:realm) ! Cette page wiki donne plus de détails sur les échanges entre le serveur et le client. Vous pouvez initier une authentification digest avec curl comme suit :

curl -k –-digest –u username:password -v https://api.example.com

Pour la route

L’authentification basique est simple à mettre oeuvre mais présente toutefois l’inconvénient de transférer les mots de passe en clair. Il est sage de n’utiliser qu’avec TLS (a.k.a HTTPs) qui ajoute la confidentielle au niveau transport. En revanche l’authentification digest est un peu plus complexe à implémenter mais a le mérite de ne pas transférer les mots de passe en clair. Disposant de ces infos et de vos contraintes propres (deadline, sensibilité de votre API etc.) vous êtes suffisamment armé pour choisir entre ces deux schémas d'authentification.

© Nouhoum TRAORE.. Fourni par Blogger.