D'un point de vue théorique, il y a essentiellement 3 moyens d'attaquer un/plusieurs mots de passe hashés.
La première est de "casser" la fonction de hash elle-même. En prenant une bonne fonction de hash (genre sha512 ou whirlpool), tu peux raisonnablement ignorer ce vecteur d'attaque puisqu'il sera bien plus simple pour un attaquant de trouver et exploiter une faille ailleurs dans ton système.
Deuxièmement, tu as les rainbow tables. L'idée étant de prémâcher la tâche de brute-force : tu te retrouves avec la possibilité d'inverser ta fonction de hash pour un nombre conséquent de sortie possible. Avec un sel dynamique (chaque utilisateur à un sel différent) aléatoire et assez grand, une attaque par rainbow table ne donnera probablement rien. À noter qu'avec un sel statique (le même pour tout le monde), il est toujours possible de générer une rainbow table pour tous tes utilisateurs, ce qui peux être rentable suivant le nombre d'utilisateur.
Finalement, tu as le risque d'attaque par brute force ou dictionnaire. Mettons que 10% de tes utilisateurs ont eu la brillante idée de choisir un mot de passe parmi les 1000 mots de passes les plus courants. Il faudra alors en moyenne 100010temps de hash à ton attaquant pour trouver un mot de passe en moyenne. Si tu veux gêner ton attaquant, la solution la plus simple est d'augmenter le temps de hash. L'idée est souvent d'appliquer ta fonction de hash x
fois, ce qui multiplie par x
ton temps de hash. Par contre, c'est une mauvaise idée de faire ça aussi simplement parce que ça réduit potentiellement la sécurité de ta fonction de hash. En revanche password_hash
a une option pour gérer le coût de hash. À toi de voir combien tu veux dépenser de puissance de calcul pour protéger tes utilisateurs contre des attaques par brute force ou dictionnaire.