Première partie du résumé de la sécurisation de l’échange de mot de passe entre l’utilisateur et Ubiquité.

Après l’amélioration consistant à effectuer les transferts de mot de passe (entre autres) à l’API via le protocole HTTPS, il ne reste plus qu’à sécuriser l’autre moitié de la chaîne, c’est-à-dire les transferts de mot de passe entre l’utilisateur et Ubiquité.

Cela est délicat à mettre en œuvre. En effet, plutôt que d’utiliser HTTPS, j’ai choisi de chiffrer directement le mot de passe dans le navigateur Web de l’utilisateur, avec JavaScript (JS). Il fallait donc employer la cryptographie asymétrique. De là, trois points importants :

  1. utiliser une implémentation valide de l’algorithme de chiffrement ;
  2. générer une clef correcte et robuste ;
  3. rendre le chiffrement le plus léger possible (en terme de charge de travail du processeur de l’utilisateur) ;

La résolution du point n°3 aurait pu conduire à l’utilisation de la cryptographie hybride AES+RSA. Néanmoins, au vu de la taille extrêmement réduite des données à chiffrer (des mots de passe, dont l’immense majorité fait moins d’une vingtaine de caractères), j’ai préféré substituer à une implémentation d’AES (lourde, complexe et pas forcément compatible entre JS et PHP, c’est-à-dire entre navigateur Web et serveur, et donc entre l’utilisateur et Ubiquité) l’usage beaucoup plus simple et rapide (bien que la rapidité d’AES soit tout à fait acceptable) de l’algorithme du masque jetable. Le navigateur Web de l’utilisateur génère donc une chaîne pseudo-aléatoire de la taille de son mot de passe, l’utilise comme masque jetable pour chiffrer le mot de passe, puis chiffre la chaîne pseudo-aléatoire avec RSA et envoit la chaîne et le mot de passe chiffrés à Ubiquité.

Pourquoi ne pas chiffrer directement le mot de passe avec RSA ? Il y a plusieurs raisons, d’ordre cryptographique, et parmi elles :

  • l’usage préalable du masque jetable standardise la taille de l’entrée (et donc celle de la sortie) de RSA, empêchant ainsi d’étudier la taille de la sortie pour en déduire celle du mot de passe ;
  • mon implémentation utilise des clefs de 1024 bits, une taille en principe sûre. Néanmoins, avec une puissance de calcul suffisante, il est toujours envisageable de pouvoir casser un chiffrement RSA. La sécurité du masque jetable, en revanche, ne dépend pas de la taille de clef (seulement de son caractère le plus aléatoire possible).

À l’heure actuelle, j’ai les différentes fonctions ; il s’agit à présent de les relier. Ensuite, il faudra établir le code de déchiffrement du côté serveur.