JeuWeb - Crée ton jeu par navigateur
Mots de passe et salt : explications - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Mots de passe et salt : explications (/showthread.php?tid=5184)

Pages : 1 2 3


RE: Mots de passe et salt : explications - Colmea - 20-01-2011

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

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


RE: Mots de passe et salt : explications - nicodd - 20-01-2011

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.


RE: Mots de passe et salt : explications - Viciousity - 20-01-2011

Surtout que le hash fait 64 caractères donc ce n'est pas non plus énorme hein Smile
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 Smile


RE: Mots de passe et salt : explications - srm - 20-01-2011

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 Smile


RE: Mots de passe et salt : explications - Foxglove - 20-01-2011

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.


RE: Mots de passe et salt : explications - Viciousity - 21-01-2011

(20-01-2011, 11:30 PM)Foxglove a écrit : 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 ?


RE: Mots de passe et salt : explications - Argorate - 21-01-2011

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 Wink


RE: Mots de passe et salt : explications - srm - 21-01-2011

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


RE: Mots de passe et salt : explications - Sephi-Chan - 21-01-2011

(21-01-2011, 12:43 AM)Argorate a écrit : 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 Wink

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


RE: Mots de passe et salt : explications - Foxglove - 21-01-2011

(21-01-2011, 12:04 AM)Viciousity a écrit : 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).