La cryptographie et le Web : hachage, salage et autres recettes
Par Lyle Mullican
L’un des outils de sécurité les plus puissants à disposition des développeurs web est la cryptographie, une opération consistant à transformer des informations porteuses de sens en bruit aléatoire, illisible sauf là où elles ont besoin d’être lues. Nombre de gouvernements ont strictement réglementé les logiciels de cryptographie jusqu’à une période relativement récente. Mais la cryptographie étant simplement des mathématiques appliquées, elle s’est avérée impossible à éliminer. Un développeur web qui travaille dans son garage sur son petit netbook a aujourd’hui accès à des cryptosystèmes majeurs dont les gouvernements rêvaient seulement il y a encore quelques décennies.
Il est tentant de croire qu’une simple application web n’a pas besoin d’une sécurité de niveau industriel parce qu’elle n’est pas censée contenir d’informations qui vaillent la peine d’être dérobées, telles que des numéros de carte de crédit. Malheureusement, les gens ont tendance à réutiliser les mêmes mots de passe sur les différents systèmes qu’ils emploient. Si le plus vulnérable de ces systèmes est compromis, l’accès aux autres sera généralement possible. En 2009, un pirate a ainsi fait parler de lui en réussissant à pénétrer dans plusieurs systèmes internes à Twitter après avoir piraté le compte e-mail d’un seul assistant administratif.
Tout artisan doit connaître ses outils et les matériaux pour atteindre l’excellence. Les développeurs web doivent quant à eux savoir quel type de cryptographie convient à quel contexte, même s’ils ne comprennent pas les opérations mathématiques utilisées dans leur moindre détail. Des méthodes de cryptographie mal appliquées n’apportent aucun avantage et peuvent même s’avérer dangereuses en procurant un faux sentiment de sécurité.
Il existe de nombreux types de cryptosystèmes, mais trois grandes catégories concernent habituellement les applications web.
Fonctions à sens unique
Il est impossible de partir d’une saucisse pour produire les ingrédients de base qui la composent. De même, une fonction de hachage cryptographique est conçue pour prendre des données et les mélanger afin que le résultat à l’autre bout soit irréversiblement méconnaissable. Décrite ainsi, cette opération ne semble pas particulièrement difficile ni utile. Mais les fonctions de hachage bien conçues présentent deux propriétés qui les rendent à la fois complexes et utiles.
Primo, une légère modification des données en entrée doit entraîner un changement drastique des données en sortie. Autrement dit, modifier un caractère des données hachées changera bien plus qu’un simple caractère en sortie. En règle générale, le hachage produit une empreinte de longueur définie (et relativement faible), quelle que soit la taille des données en entrée. Cela signifie qu’en théorie, plusieurs entrées peuvent donner le même résultat. Un pirate qui ne posséderait que l’empreinte cryptographique n’aurait donc pas la possibilité de remonter jusqu’aux données d’origine.
Secundo, une fonction de hachage produira toujours la même empreinte à partir de données identiques en entrée. L’application la plus évidente du hachage est le stockage des mots de passe. Une application web n’a pas besoin de réellement « connaitre » le mot de passe d’un utilisateur ; il lui suffit de vérifier que la personne demandant l’accès le connait. Si la même méthode de hachage est utilisée au moment de la création du mot de passe et au moment de l’identification, il suffit de stocker et de comparer uniquement le résultat des opérations de hachage pour savoir que les mots de passe originaux sont identiques. Ainsi, même si un pirate parvient à accéder à une base de données utilisateur, il n’obtient aucune information vraiment utile. En tout cas, c’est l’opinion la plus répandue.
Ce n’est pas si simple en réalité. Tout d’abord, tous les algorithmes de hachage ne naissent pas égaux. L’algorithme MD5 par exemple a connu son heure de gloire, mais est réputé aujourd’hui pour son manque de fiabilité général sur le plan cryptographique (bien qu’il puisse toujours être utilisé pour les mots de passe). Ensuite, nous savons que de nombreuses personnes choisissent les mêmes mots de passe courants. Un pirate qui connaîtrait la valeur de l’empreinte pour « 123456 » produite par quelques algorithmes couramment utilisés n’aurait aucun mal à la retrouver dans une base de données. Des listes d’empreintes précalculées, appelées tables arc-en-ciel (rainbow tables) par les professionnels de la sécurité, sont disponibles très facilement.
Afin de pallier ce point faible, une fonction de hachage peut être « salée ». Étant données les deux propriétés des bons algorithmes de hachage décrits précédemment, il suffit d’ajouter au mot de passe quelques données à notre sauce et de stocker l’empreinte de cette combinaison de textes plutôt que celle du mot de passe seul. Cette opération génère un résultat complètement différent, mais toujours facile à vérifier.
Comparez les deux exemples suivants :
sha1('mot_de_passe')
=> 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8
sha1('x5T1mot_de_passe')
=> e1f9530af9bde38db0eef386c4d22ec2ba10d2feIci, ajouter quatre caractères aléatoires au début du mot change 95 % de l’empreinte.
Parmi les fonctions de hachage disponibles dans la plupart des langages de programmation, l’algorithme SHA-1, développé par la NSA [1], est à ce jour le plus efficace.
Chiffrement symétrique
Bien entendu, les fonctions à sens unique trouvent un usage assez restreint. La plupart du temps, les informations sont cryptées uniquement pour s’assurer qu’elles ne puissent pas être lues hors de leur contexte. Mais dans un contexte donné (une console d’administration, par exemple), le cryptage doit être réversible.
Toutefois, un développeur d’applications devrait toujours commencer par se poser la même question : « Ai-je vraiment besoin de recueillir et de stocker ces informations ? » Maintenir la collecte des données à un strict minimum simplifie le développement et contribue généralement à améliorer l’expérience utilisateur et bien entendu la sécurité. Après tout, les données qui n’existent pas ne peuvent être ni volées ni exploitées.
Mais si ces informations sensibles sont absolument indispensables à la fonctionnalité d’une application, il faut réfléchir à comment les manipuler en toute sécurité. Le cryptage réversible se divise en deux catégories. Dans la première, une seule « clé » secrète est utilisée pour chiffrer et déchiffrer les données. Les clés constituent une sorte de mot de passe, mais puisqu’elles sont utilisées plutôt par des programmes que par des humains, elles peuvent (et doivent) être plus longues et complètement aléatoires.
Avec les algorithmes modernes, le cryptage symétrique a l’avantage d’être extrêmement rapide. Le puissant algorithme AES (ou Rijndael) a été spécialement conçu pour être rapide et compatible, avec des implémentations à la fois dans les serveurs de bases de données et dans les frameworks applicatifs. Par exemple, crypter et décrypter des données dans MySQL est un jeu d’enfant :
INSERT INTO gens (nom_animal)
VALUES (AES_ENCRYPT('Snoopy','ma-cle-secrete'));
SELECT AES_DECRYPT(nom_animal, 'ma-cle-secrete') AS nom_animal
FROM gens;Cette méthode n’empêche pas les informations d’être exposées si un utilisateur mal intentionné accède à l’application web, car elle sait comment décrypter les données. Cependant, elle empêche de divulguer accidentellement les données dans d’autres contextes, comme des fichiers de sauvegarde ou une attaque sur la base de données même.
Le cryptage symétrique fonctionne bien lorsque l’on accède toujours aux informations depuis le même contexte. Toutefois, sa force réside toute entière dans la clé secrète. Cela devient un problème lorsque les données ont besoin d’être transférées. La clé n’est plus secrète dès lors qu’elle est partagée, surtout avec plusieurs destinataires.
Chiffrement asymétrique
Pour répondre à ce besoin, les algorithmes asymétriques se basent sur une paire de clés générées avec certaines propriétés spécifiques. Lorsqu’un message est crypté avec une clé, seule l’autre clé correspondante peut le déchiffrer. Ce type de chiffrement est également appelé « cryptographie à clé publique », car il arrive souvent (mais pas toujours) que l’une des clés soit rendue publique et l’autre tenue secrète.
Il est intéressant de connaître les opérations mathématiques à la base de cette méthode, mais les développeurs web ont surtout besoin de comprendre quand utiliser ce type de chiffrement et la protection qu’il offre. Cette technologie est le plus fréquemment utilisée pour les connexions SSL (appelées TLS aujourd’hui). Le serveur web envoie sa clé publique au navigateur, qui l’utilise pour chiffrer les données que seul le serveur est capable de déchiffrer. Elle peut également servir à envoyer des e-mails chiffrés.
Comparées aux fonctions symétriques, les fonctions asymétriques sont lentes et nécessitent des clés beaucoup plus longues pour être efficaces. Dans le cadre de connexions TLS, le navigateur et le serveur utilisent simplement un système cryptographique à clé publique pour établir une clé symétrique temporaire afin de chiffrer les communications ultérieures.
Ces fonctions remplissent toutefois un rôle crucial dans la navigation web moderne. Elles nous permettent en effet de protéger les données qui transitent entre une application et les utilisateurs. La forte présence des réseaux Wi-Fi ouverts est une réelle source de préoccupation à ce sujet. Sur ces réseaux, les utilisateurs diffusent tout ce qu’ils font dans un rayon de 360° et sur une distance considérable. Non chiffrées, ces données peuvent être consultées facilement par n’importe qui équipé d’un ordinateur portable. En 2010, deux incidents très médiatisés ont mis ce risque en lumière. Tout d’abord, Google s’est trouvé aux prises avec les autorités chargées de la protection de la vie privée après avoir stocké accidentellement le trafic de réseaux Wi-Fi non chiffré capté par ses véhicules Street View. Ce que Google a fait accidentellement, d’autres peuvent le faire volontairement. Quelques mois plus tard, le plug-in Firesheep a fait les gros titres en montrant à quel point il est simple (et dangereux) d’espionner un réseau ouvert.
Les applications web devraient exiger au minimum des connexions TLS pour la transmission des informations d’identification. Il est encore mieux de les utiliser pour l’ensemble du trafic.
Comprendre le risque
Étant donnée l’utilisation que nous faisons des ordinateurs aujourd’hui, il est certain que toutes ces technologies seront de plus en plus importantes pour les développeurs web. Les événements de ces dernières années ont montré que ce risque n’était pas que théorique. Se dire que son application n’est pas assez réputée pour être ciblée ne suffit pas. Les attaques sont souvent automatisées, pas ciblées. Dans le même temps, nous devons comprendre et informer les gens des risques spécifiques qui existent et sur la manière d’utiliser la technologie pour les contrer. Sans cette démarche éducative, les clients peuvent considérer qu’un site ou une application est « sûre » tout simplement parce qu’elle accepte les connexions HTTPS. Sans comprendre pourquoi il est impossible de leur envoyer un mot de passe en clair dans un e-mail.
La sécurité n’est jamais absolue. Mais utilisée correctement, la cryptographie moderne nous fournit des outils pour éliminer les principales menaces. À nous de les mettre à profit.
[1] National Security Agency, agence de sécurité nationale américaine
http://www.alistapart.com/articles/web-cryptography-salted-hash-and-other-tasty-dishes/