Mots de passe et salt : explications

[Colmea]

Tu redemandes le mot de passe quand il veut changer sa date de naissance

Sinon merci pour ces explications. Symfony utilise ce système et pourtant je ne m'étais jamais penché dessus (honte à moi ).

[nicodd]

Oui, mais alors un admin ne peut pas modifier les données d'un des utilisateurs du site, ce qui peut être problématique.

Je pense aussi qu'un champ supplémentaire ne pose pas de problèmes particuliers, et chipoter pour contourner ça ne me semble pas être une optimisation très intéressante.

[Viciousity]

Surtout que le hash fait 64 caractères donc ce n'est pas non plus énorme hein
Et oui cela permet de changer indépendamment le mot de passe des autres données du compte.

Maintenant il existe d'autres moyens mais pour la même efficacité, ils sont beaucoup plus lourd en terme de ressources.
Ici, en gros, tu as une fonction et 1 constante unique

[srm]

Au passage concernant la remarque de Argorate, l'espace disque est la chose la moins coûteuse en informatique hein, on va pas pleurer pour peut-être en tout 10mo de données supplémentaire si on a plusieurs centaines de millier de joueur parce que l'on a mis une colonne spécial ou il y a un salt aléatoire par joueur

[Foxglove]

Dans l'explication, il y a une confusion faite entre "hash" et "salt".

Situation : sauvegarde d'un mot de passe dans un fichier texte (comme dans /etc/passwd) :
user=toto/pass=ab45cd
Problème : n'importe qui ayant accès au fichier en lecture peut trouver facilement le mot de passe.
Solution : ne pas sauvegarder le mot de passe en clair, mais un condensé (HASH) du mot de passe.

Situation : sauvegarde d'un HASH dans un fichier texte
user=toto/pass=#gjaz-
Quand "toto" se connecte, il tape "ab45cd". Le système condense ce mot (HASH("ab45cd")="#gjaz-" dans cet exemple) et le compare à ce qui est dans le fichier. S'il y a égalité, le mot de passe est accepté.
Avantage : le mot de passe n'est pas sauvegardé en clair.
Propriété du HASH : les fonctions de HASH sont dites non inversibles, c'est-à-dire qu'il est très dur de retrouver "ab45cd" à partir de "#gjaz-".

Situation : un attaquant possède un dictionnaire de plusieurs passwords condensés.
Solution : Pour éviter ce problème, on ajoute un salt, c'est-à-dire un nombre arbitraire, au mot de passe (avant de le condenser). Le fichier devient :
user=toto/salt=1534/pass=jz453mlo#kj
Quand "toto" se connecte, il tape "ab45cd". Le système y ajoute le salt, ce qui donne "ab45cd1534", puis condense tout ça, ce qui donne "jz456mlo#kj". Le salt complexifie le mot de passe de l'utilisateur, de manière transparente pour l'utilisateur. Par contre, la taille du dictionnaire nécessaire à l'attaquant est beaucoup plus grande, ce qui rend les attaques par force brute beaucoup moins efficace.

[Viciousity]

Dans l'explication, il y a une confusion faite entre "hash" et "salt".

Situation : sauvegarde d'un mot de passe dans un fichier texte (comme dans /etc/passwd) :
user=toto/pass=ab45cd
Problème : n'importe qui ayant accès au fichier en lecture peut trouver facilement le mot de passe.
Solution : ne pas sauvegarder le mot de passe en clair, mais un condensé (HASH) du mot de passe.

Situation : sauvegarde d'un HASH dans un fichier texte
user=toto/pass=#gjaz-
Quand "toto" se connecte, il tape "ab45cd". Le système condense ce mot (HASH("ab45cd")="#gjaz-" dans cet exemple) et le compare à ce qui est dans le fichier. S'il y a égalité, le mot de passe est accepté.
Avantage : le mot de passe n'est pas sauvegardé en clair.
Propriété du HASH : les fonctions de HASH sont dites non inversibles, c'est-à-dire qu'il est très dur de retrouver "ab45cd" à partir de "#gjaz-".

Situation : un attaquant possède un dictionnaire de plusieurs passwords condensés.
Solution : Pour éviter ce problème, on ajoute un salt, c'est-à-dire un nombre arbitraire, au mot de passe (avant de le condenser). Le fichier devient :
user=toto/salt=1534/pass=jz453mlo#kj
Quand "toto" se connecte, il tape "ab45cd". Le système y ajoute le salt, ce qui donne "ab45cd1534", puis condense tout ça, ce qui donne "jz456mlo#kj". Le salt complexifie le mot de passe de l'utilisateur, de manière transparente pour l'utilisateur. Par contre, la taille du dictionnaire nécessaire à l'attaquant est beaucoup plus grande, ce qui rend les attaques par force brute beaucoup moins efficace.

Parfaite explication, puis-je rajouter cela au début de la ressource en te citant ?

[Argorate]

Oui, enfin là vous êtes un peu de mauvaise fois, si on prend l'exemple d'Holy, la date d'inscription est une donnée qui ne change pas.
Il y a aussi la méthode d'un salt stocker dans un fichier, qui est fixe et qui n'apparait jamais en BDD...
Bref, le principe est ok, mais il y a plusieurs dérivé possible a mettre en application, c'est tout se que je voulais souligner

[srm]

Oui sauf que moi je préfère une vrai donnée aléatoire que quelque chose heuristiquement trouvable

[Sephi-Chan]

Oui, enfin là vous êtes un peu de mauvaise fois, si on prend l'exemple d'Holy, la date d'inscription est une donnée qui ne change pas.
Il y a aussi la méthode d'un salt stocker dans un fichier, qui est fixe et qui n'apparait jamais en BDD...
Bref, le principe est ok, mais il y a plusieurs dérivé possible a mettre en application, c'est tout se que je voulais souligner

Comme le dit Oxman, une date n'est pas du tout aléatoire. Il est conseillé d'utiliser des salt aléatoires et longs, une date (surtout dans un intervalle aussi court) ne répond pas à ses critères.

On a vu qu'avoir un salt par personne était de mise. Autant faire simple et limiter la fragmentation inutile des données tant qu'une alternative plus efficace ne sera pas proposée par un expert et acceptée comme une bonne pratique.


Sephi-Chan

[Foxglove]

Parfaite explication, puis-je rajouter cela au début de la ressource en te citant ?

Bien sûr, tu peux rajouter cela au début de la ressource. Il n'est pas nécessaire de me citer, j'ai juste donné une description courte de ce que l'on peut trouver sur wikipedia ou sur des sites du même genre (il s'agit de connaissances générales).