Les données corrompues

En informatique, on est souvent amené à traiter les données. compression avec pertes, compression sans perte, chiffrement (en cryptogtraphie)

Lors de la transmission d'une grande quantité de données, on peut être amené à vouloir vérifier qu'il n'y a pas eu de dommages lors du transfert ou du stockage sur un support physique.

  • L'une des méthode les plus basique est l'ajout d'un bit de parité, mis à 1 lorsque le nombre de bits présent dans les données à transmettre est impair. Très facile à implémenter, il peut s'avérer insuffisant si trop de données sont corrompues.
  • On utilisera alors des algorithmes plus complexes, tel que le crc qui peux détecter de manière plus fiable si des données sont corrompues. On le voit généralement lors de l'utilisation de CD-ROM rayés ou endommagés.
  • Il est même possible de pouvoir corriger des erreurs éventuelles avec les codes correcteurs dans le cas où une faible partie des données seraient corrompues. On les trouve non seulement sur les CD-ROM mais aussi sur usenet (fichiers Parchive) ou dans les systèmes RAID qui incluent cette redondance capable de récupérer les données corrompues.

=> Je vous conseille vivement l'utilisation de RapidCRC pour vérifier par exemple après gravure/stockage que les fichiers n'ont pas été corrompus en ayant préalablement mis le CRC dans le nom du fichier.


Les données corrompues intentionnellement

Un autre aspect est le problème des dommages intentionnel qui peuvent apparaitre sur les données. Une personne mal intentionnée serait alors capable de modifier les données sans que le système qui détecte la corruption ne s'en rende comptes.

  • On utilisera alors des algorithmes plus évolués qui rendront très difficile la modification intentionnelle, au cout de calculs supplémentaires et d'une augmentation de la taille de la "signature".
  • Il existe plusieurs algorithmes plus ou moins fiables, les plus connus étant md5 et sha128.

=> Si vous distribuez des fichiers sur votre site web par exemple, vous pouvez donner les signatures md5 correspondantes. (on pourra voir par exemple le fichier md5sums de bigbuckbunny.org qui avec le logiciel rapidCRC permet de vérifier que les autres fichiers ne sont pas corrompus, intentionnellement ou pas.)


La protection des mots de passe

Ces algorithmes ont permis d'améliorer la sécurité dans le stockage des mots de passe : En effet, la "signature" permet de vérifier que les données transmises n'ont pas été modifiées, mais ne permettent pas de les connaitre. On pourra donc utiliser la signature du mot de passe d'un utilisateur, et la comparer à la signature du mot de passe fourni lors de son authentification pour vérifier que les mots de passe sont identique, sans pouvoir les connaitre.

On pourrait alors penser à utiliser la "signature" md5 d'un mot de passe, mais un gros inconvénient apparait : l'attaque par table arc-en-ciel qui consiste à chercher dans une liste pré-calculée et optimisée d'une grande taille (prévu pour tenir sur un DVD généralement) de signatures si un mot de passe corresponds. Une parade est alors d'inclure une donnée supplémentaire qui sera mixée avec et stockée en supplément : un sel.

Cette contre-mesure empêche donc l'attaque par table rainbow, mais il reste un problème : md5 et sha128 sont prévu pour pouvoir facilement vérifier la signature de fichiers, qui peuvent atteindre plusieurs centaines de Mo. Mais ils peuvent, à l'aide des processeurs actuels et les processeurs de carte graphiques adaptés calculer la signature de plein de mots de passe potentiels par force brute en l'espace de quelques jours et avec les technologies de type CUDA, c'est encore plus rapide!

On passe alors à de nouveaux algorithmes dont le but est de demander plus de calculs afin de ralentir l'attaque par force brute, au point qu'une attaque par force brute ne prendrais pas quelques jours mais quelques centaines de siècles, et qui se paient même le luxe de pouvoir définir manuellement le niveau de complexités pour s'adapter à la montée en puissance incessante de nos ordinateurs. Grosso modo, on aurait par exemple, md5 qui calcule la signature d'un film en quelques dizaines de secondes, et des mots de passe en quelques microsecondes, et crypt qui calcul un mot de passe en dixièmes de secondes (vous pouvez donc vérifier le mot de passe d'un utilisateur qui s’authentifie en quelques dixièmes de secondes, où une attaque par force brute serait alors inefficace).

=> Pour protéger les mots de passe de vos utilisateurs, utilisez des fonctions prévues pour.

Edit:

Suite à une discussion avec Axel et aux problèmes de compatibilité entre différents systèmes, je vous rappelle que la fonction crypt génère des hash contenant un identifiant d’algorithme utilisé et qu'il est donc possible avec un autre logiciel de pouvoir utiliser la même authentification alors que les mots de passe hashés avec un algorithme perso ne le permettent pas. 

Enfin, vu le succès et les défauts d'OpenID ainsi que les autres méthodes d'authentification, il reste encore beaucoup de travail dans la gestion de l'authentification des utilisateurs.