05 mar. 2010

webvcs - vérification de l'identité en ligne sans transfert du mot de passe

De nombreux systèmes - qu'ils soient des sites web ou des programmes se connectant à internet - ont besoin de vérifier l'identité de l'utilisateur. Souvent, cette identité est stockée dans une base de donnée qu'il faut alors interroger. Le problème est que pour interroger cette base de donnée, il faut au moins deux information : l'identifiant de connexion et le mot de passe qui lui est associé. Il est courant de voir des implémentations qui font transiter ce mot de passe en clair sur internet - avec tous les risques de sécurité que cette transmission d'information pose.

Cet article présente une méthode simple d'implémentation ne nécessitant pas le transfert en clair ou crypté du mot de passe, permettant ainsi l'authentification d'un utilisateur de manière plus sécurisée. Cette méthode est implémentée dans le logiciel en cours de développement webvcs, mais il peut aisément être porté vers une architecture de type client léger.

Implémentation

L'identification s'effectue en deux passes :

  • dans la première passe, le client interroge le serveur pour obtenir un identifiant lié à la connexion. Cet identifiant est lié à la certaines informations en provenance de la machine cliente (par exemple, son adresse IP).
  • dans la seconde passe, le client envoie le login de l'utilisateur ainsi qu'une clef de hashage créée à partir de l'identifiant de connexion et du mot de passe de l'utilisateur. Le serveur recalcule l'identifiant de connexion, récupère le mot de passe lié au login, et compare la clef de hashage reçue avec la clef de hashage qu'il calcule lui-même. En fonction du résultat de cette comparaison le client reçoit soit une erreur d'authentification, soit un cookie contenant un token d'authentification réussie - qui sera utilisé pour toutes les transactions suivantes entre le client et le serveur.

Dans webvcs, j'ai choisi d'utiliser l'algorithme de hashage SHA1 - pour sa simplicité, et parce que cette algorithme est implémenté dans de nombreux langages, y compris javascript, PHP (supporté de manière native), C et C++.

Considérations de sécurité

  • A aucun moment le client n'envoie le mot de passe en clair. De fait, il n'est pas possible d'intercepter ce mot de passe.
  • La longueur du mot de passe n'a pas d'influence sur la longueur de la clef de hashage. En choisissant un mot de passe suffisamment long, on peut éliminer les problèmes que peuvent soulever une attaque de type force brute.
  • Même si un attaquant intercepte le token d'authentification, il ne peut pas s'en servir puisque celui-ci est lié à la machine cliente. Par contre, si il est situé sur une machine qui partage ses informations de connexion avec la machine cliente (par exemple si il est situé derrière le même routeur NAT), il peut obtenir les mêmes droits que l'utilisateur connecté.

SHA1 et MD5 (les deux fonctions de hashage les plus utilisées) sont sujets à des collisions (voir cet article de X.Wang et H.Yu). Pour plus de sécurité, on peut leur préférer des évolutions plus récentes telle que SHA-256. En PHP, la fonction hash() vous permet de choisir l'agorithme de hashage parmi les algorithmes disponibles.

Conclusion

Cette authentification n'est pas une authentification complètement sécurisée et de fait, webvcs qui implémente cette technologie ne doit pas être utilisé dans un contexte où la sécurité est primordiale.

Elle est toutefois plus fiable qu'une authentification qui ferait passer le mot de passe en clair sur le réseau, ce qui, ramené aux intentions originelle du projet webvcs, est suffisant dans un premier temps. Le seul moyen d'obtenir une connexion sécurisée entre un client et un serveur reste le cryptage complet des échanges de données.

Notes sur l'implémentation sur un client léger

Pour une implémentation dans un client léger, il suffit d'un bon browser web supportant javascript et la librairie javascript présentée ci-dessus. Le même système peut être implémenté sur une unique page web car :

  • la première passe est automatique, les informations d'identification de la machine client pouvant être récupérée lors de la génération de la page de login ;
  • la seconde passe est effectuée par l'envoi de la requête de test lorsque l'utilisateur se connecte.

Comme dans le cas client riche/serveur, le token d'authentification est renvoyé au client léger sous la forme d'un cookie.

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

Fil des commentaires de ce billet