Authentification + Salt ?

Bonjour à tous,

J'essaie de comprendre le principe de l'application d'un "salt" comme mesure supplémentaire de protection lors de l'authentification.

J'ai lu des explications sur ce site : http://www.opensecuritylab.org/stori...ng-salt-in-php

Mais je ne comprend toujours pas en quoi ce système sécuritaire.

Suppossons une table

Utilisateur
MotDePasse
Salt


Mon utilisateur écrit le mot de passe : ABCDE

Je lui applique après un salt disons : '123456789987654321';

Ce qui me donne comme chaîne : ABCDE123456789987654321

Ce qui donne bien entendu, un hashing différent de ABCDE, mais dans ma validation qui valide si l'utilisateur / mot de passe est bien le bon, je vais quand même recevoir le mot de passe ABCDE, lui appliquer le Salt sauvegarder en mémoire pour comparer les hash non ?

Donc si un script essaie avec un dictionnaire, la chaine ABCDE. Ma validation, va considèrer comme correct le mot de passe.... Non ?

Merci d'éclairer ma lanterne, car je voudrais bien améliorer la sécurité de mes usagers mais je ne comprends bien cette méthode....

Je suis pas sûr d'avoir compris ce que tu demandes, mais si effectivement quelqu'un fournit le mot de passe correct, l'authentification va marcher...
L'intérêt du rajout de "sel" réside dans le fait que si un attaquant récupère le hash du mot de passe (via par exemple une SQLi), il aura beaucoup plus de peine à retrouver le mot de passe : les tables qu'on peut trouver sur le net permettent souvent de retrouver un mot de passe "simple" à partir d'un hash, mais là tu complexifie la tâche puisque ton mot de passe n'est plus si simple.

Une protection supplémentaire souvent utilisée je crois, est de composer deux hachages successifs avec du sel.
$hashed_passwd = sha1($salt.sha1($salt.$passwd));

en espérant avoir pu aider

Sauf que je ne comprend toujours pas à quoi ça sert.

Si le pirate voit le hash du mot de passe. C'est qu'il a réussit à lire ma B.D.

Donc, c'est pour évider que, si l'utilisateur utiliser le même mot de passe ailleur, que le pirate puisse lui voler ses informations sur les autres sites ?

Ça n'empêche donc pas les attaques par dictionnaire via le login form ?

C'est ça.

Citation:

---

Envoyé par JonathanMQ

Ça n'empêche donc pas les attaques par dictionnaire via le login form ?

---

Non effectivement le salt rend le piratage plus difficile à beaucoup de niveaux, mais pas à celui-ci. La protection contre une soumission massive de mots de passe à ton formulaire relève d'autres pratiques.

Certains prétendent que les mots de passe doivent être protégés à tous les coups : même dans le pire cas (c'est-à-dire que le pirate a accès à tout ton code et à toute ta base de données), il ne peut pas pouvoir les retrouver (sauf utilisation de rainbow table, de force brute, etc.). C'est à ça que servent les grains de sel : les mots hashés sont beaucoup plus long, on trouvera plus difficilement leurs équivalents en rainbow table, ça prendra plus de temps pour lancer une procédure de force brute (vu qu'on sera sûr d'une borne minimale sur le nombre de caractères : le nombre de caractères minimal imposé sur le mot de passe plus le nombre de caractères du sel, soit une belle progression pour un hash de trois caractères pris dans l'ASCII sept bits, 127^3 fois plus de mots à essayer).

Maintenant, si tu utilises une fonction cryptographique qui est devenue très faible au fil du temps à cause de la cryptanalyse, pour lesquelles on peut utiliser d'autres techniques, plus efficaces, que la force brute, utiliser un sel ne sert plus à grand-chose, vu qu'un pirate bien équipé arrivera sans grand problème à retrouver les mots de passe ; seule solution : ne pas utiliser ce genre de fonctions cryptographiques. Exemples : MD5, SHA1. Pour trouver cette information, Wikipedia est en général une bonne source.

Pour l'application de plusieurs couches de fonctions de hashage sur un même mot, ça semble une bonne piste selon Wikipedia : http://en.wikipedia.org/wiki/Hash_chain. Il me semble que cette technique est également utilisée par OpenXML, le format de fichier d'Office 2007 et suivants.

Pour se protéger des attaques par dictionnaire, je ne vois pas mieux que les protections plus générales contre la force brute : une pause d'une seconde ou une demie seconde avant de tester s'il y a correspondance des mots de passe, ça évitera d'avoir des milliards d'essai par seconde (une fois que le pirate a remarqué ça, il peut passer en parallèle, il suffit alors de bloquer le nombre de connexions possibles en simultané depuis une IP... mais c'est plus dur à implémenter). Une solution très utilisée est de mettre en mémoire toutes les tentatives infructueuses : tu en autorises cinq, par exemple, toutes les heures. Ou bien tu mets un temps d'attente avant validation du mot de passe côté PHP qui augmente avec le nombre d'essais (selon une loi exponentielle, de préférence), comme c'est parfois utilisé pour les codes des autoradios.

Bonjour,

Cela fait plusieurs mois que j’essaie de cherche l'etat de l'art en sécurité notamment pour le cryptage des mots de passes.

Voila les problèmes de sécurités pour les mots de passes :

-Le mot de passe ne doit pas être décryptable. La raison est que souvent les utilisateurs utilisent leur même mot de passe pour plusieurs sites. Il faut éviter que si un hacker décrypte le mot de passe utilisé sur un petit site puisse utiliser le même mot de passe pour se connecter au compte en banque de ce même utilisateur. Pour cela, il faut utiliser une fonction de hash.

-Si un hacker récupère la liste des mots de passe, il peut utiliser un table qui lui donne pour chaque hash le mot de passe correspondant. Ces tables se base sur un salt particulier. Pour contourner ce système, il faut saler le mot de passe en utilisant un salage différent pour chaque utilisateur. Le salage n'a pas besoin d'être secret. Il peut être stocké en claire dans la base de donnée. Il n'est pas nécessaire de régénérer le salage si l'utilisateur change de mot de passe. Avec cette technique, cela oblige l'attaquant à soit attaquer par force brute, soit tester par dictionnaire.

-Pour éviter les problèmes d'attaque par dictionnaire, il faut mettre des règles sur les mots de passe, du style "minimum 3 lettres et 9 chiffres", ou "pas le mot admin, ni le même mot de passe que le login".

-Ensuite, pour contrer la force brute, il reste à utiliser une méthode de hachage. Quel est la meilleur méthode de hachage ? Certains disent que c'est SHA256 ou SHA512. J'ai découvert grâce au magasine que c'est PBKDF2. Il est utiliser par WPA, et par les iphone. C'est une méthode de hachage par itération. Il prend un algorithme de hachage, disons SHA1, et il rehache plusieurs fois. Le but c'est de ralentir le cryptage. Par exemple WPA fait 4096 itérations. Iphone fait 10.000 itérations. Le nombre d’itération dépends du temps de calcul de la machine pour calculer la fonction de hachage pour le processus d'identification. J'ai fait un essai pour comparer sha512 et PBKDF2 avec 4096 itérations. sha512 met 1 millisecondes, et PBKDF2 50 millisecondes. Autrement dit, un hacker mettra moins de temps pour calculer une table de hachage avec SHA512 que PBKDF2. (En 2010, le FBI n'a pas réussi a décrypter un disque dur qui utilisait ce type de cryptage).

Après, il y a comment sécuriser l'envoie du mot de passe du navigateur jusqu'au serveur (même cryptage que la base de donnée, cryptage asymétrique, SSL, ...), comment stocker une clef privé de façon sécurisée pour décrypter le mot de passe de la base de donnée.

Je ne comprends pas pourquoi il n'y a pas un endroit sur internet qui explique une fois pour toute ses règles, et d'autres que je ne connait pas.

Le problème de PBKDF2 est expliqué sur Wikipedia : http://en.wikipedia.org/wiki/PBKDF2#...ives_to_PBKDF2. On peut l'implémenter sur des circuits programmables (CPLD, FPGA, ASIC, selon les moyens) ou sur GPU et avoir quand même d'excellentes performances. D'où scrypt http://www.tarsnap.com/scrypt.html. Bon, maintenant, ça fait franchement cher en temps de calcul pour l'utilisateur lambda, il faut relativiser avec les données à protéger (soit deux tours de SHA512 avec grain[s] de sel, ça procure déjà une sécurité bien plus grande que la majorité des sites codés par des amateurs) : pour un petit site avec quelques dizaines d'utilisateurs, je ne pense pas qu'il soit utile d'y aller franchement, ça ne fait pas beaucoup de mots de passe récupérables ; pour une banque, un grand site, là, c'est différent (et les moyens disponibles pour l'implémentation seront largement supérieurs, ce qui permet plus de folies).

Sinon, tu parles de crypter... Le principe de base est justement de ne jamais crypter un mot de passe : on ne veut pas le récupérer, d'aucune manière que ce soit. On veut juste le hasher, en obtenir une information que l'on peut comparer, qui contient toute l'information du mot de passe mais sans moyen direct de le retrouver.

Citation:

---

Envoyé par tulipebleu

Après, il y a comment sécuriser l'envoie du mot de passe du navigateur jusqu'au serveur

---

Et c'est le plus important. Pirater une base de donnée nécessite soit une grosse faille de sécurité (le mot de passe d'accès qui traine sur le bureau ou dans un fichier trop facilement accessible dans l'ordinateur ou... un ordi infesté par un keylogger...) ou sinon avoir une complicité niveau serveur pour pirater la bdd. Ce n'est donc pas toujours réalisable.

Par contre ce qui est beaucoup plus facile est de sniffer les tuyaux du web. La première des sécurités est donc de ne jamais transmettre les mots de passe en clair sur le web.

La grosse vulnérabilité au sniffage de nos jours, c'est que la plupart des e-mails sont transmis en clair. Y compris ceux de la fonction "j'ai oublié mon pass, générez-en un et envoyez-le moi par mail"...

Bonjour ça serais pour gueuler un peu :)

Hacker == bidouilleur != pirate, okey ?
cryptage ça n'existe pas dans notre langue, d'ailleurs, c'est même pas du chiffrement (qu'il soit symétrique ou asymétrique) c'est du hashage!
On obtient donc une "empreinte" d'une données et en réprésentant de nouveau la donnée on peux la comparer avec l'empreinte pour savoir si l'entré SEMBLE être identique.
Et bien oui, désolé, je casse votre délire, mais c'est la vérité, on n'est pas sur que ça soit le vrai password. Pourquoi ?
En entrée, vous founisez une chaine de caractère de longueur variable entre 1 et l'infini, ce qui nous fait un nombre de possibilité infini, on est d'accord ?
et pourtant vous récuperer quoi à la fin ? une chaine de caractère de longueur FIXE!! Il n'y a pas un truc qui vous gène ? et bien si! toutes les combinaisons (de l'ordre de l'infini :p ) ne PEUVENT PAS avoir chacune une empreinte identique, c'est IMPOSSIBLE!
Cela s'appelle une collision, et les algorythmes qui commence à dater permettent de générer des colisions assez facilement, et http://en.wikipedia.org/wiki/Hash_chain facilite encore plus les choses ! De plus il existe des bdd de reverse hash de md5(md5())

Il faut donc se tourner vers des algo comme sha256 ou wirlpool et utiliser un sel.
Mais savez vous qu'il existe différents types de sel ?
la plupart des gens utilise un sel statique et c'est suffisant, mais si deux utilisateurs ont le meme hash, le cracker sait que la probalité que ce password soit "fort" (cad résistant au brute-force) est faible, et qu'en plus, il auras accès à deux comptes!
donc il serais préférable d'utiliser un sel dynamique, dont la valeur est propre (ou du moins non constant ) à chaque utilisateur comme le timestamp d'inscription.

De plus, limiter le brute-force dans une application en réseau, c'est comment dire... un peu inutile. Vous avez déjà essayer de coder un brute-force en python/c/php ou autre ? Personnelement j'ai déjà fait dans les trois languages, c'est lent (ok, ça reste du CPU, et à l'heure actuelle les crackers utilisent le CPU/GPU qui offre des performances nettement supérieur, sans compter la mise en réseau de la puissante de calcul de plusieurs pc, voir l'utilisation des ressources d'un botnet) mais tout cela reste dépendant d'un facteur : le lag, et oui, une connexion http est beaucoup plus lente qu'un accès disque (je parle meme pas de sdd, ou de ram) mais bien sur, si l'utilisateur as "password" comme mdp, ok, il vas se faire b****

La sécurité informatique me passionant et ayant acquéris quelques connaisances, voilà les conseils pour ceux qui ont peur du piratage des mdp :
-Déjà pensez qu'il y a pire comme faille à corriger avant de pensez à ça.
-Banniser le md5! peu importe le type de hash, il existe des centaines de bdd reverse hash et depuis le temps, elles sont pleines à cracker.
-Calculer la "robustesse" d'un mot avant son entrée dans la bdd (cela as également l'avantage de faire de la prévention sur la sécurité sur internet à vos membres peu regardant sur l'originalité de leur password, il y a meme des books de password si vous voulez que je vous les file) il existe des site qui le font par exemple http://www.howsecureismypassword.net/ (c'est du js mais c'est pour le principe)
-Eviter sha1 pour les memes raisons que md5, mais c'est acceptable avec un bon sel
-Utiliser un sel dynamique
-Préférez les autres variantes de sha ou whirlpool. (avec un sel dynamique bon courage pour trouver un seul mdp
-Se connecter avec le couple email/password (deux inconnues valent mieux qu'une, et si l'email est connu, ça ne retire rien de la sécurité)
-NE METTEZ JAMAIS CECI DANS UN SYSTEME DE CONNEXION : sleep(1) (cela utilise de la mémoire vive, et un pirate peut très facilement geler votre système)
-Limiter les connexion PAR IP et JAMAIS par compte (sinon, un pirate qui tente de se connecter à chaque compte, bloque tous votre site :p )
-Obliger un changement de mdp tous les x mois.
-Pour la fonction "mdp oublié" cela reste un problème... car on considère trop vite qu'elle est seulement accesible à l'utilisateur, alors qu'un pc compromis, c'est openbar, et pour cela je n'ai pas de solution.

Voilà, si vous avez des questions, n'hésitez pas ;)

Je profite de la réactualisation de ce post, pour proposer ce lien qui fourni un exemple complet pour protéger les mdp lors de leur transfert dans les tuyaux du web.

Il s'agit, à l'aide d'un sel dynamique concaténé au mdp puis hashé côté client avant son envoi, de rendre inexploitable le post qu'un pirate pourrait sniffer sur le réseau. On peut aussi augmenter la protection en concaténant également le login au mpd et au sel avant hashage.

C'est pas nouveau mais pas difficile à mettre en place et ça offre une protection intéressante pour ceux qui n'utilisent pas SSL, et pour ceux qui utilisent SSL cela peut servir de protection complémentaire au cas où le certificat viendrait à être piraté (ce qui s'est déjà produit).

Je précise pour les débutants qu'en aucun cas cela procure une protection du niveau de SSL, notamment SSL protège votre session, ce qui n'est pas le sujet du script proposé dans le lien qui concerne uniquement la protection du mot de passe.