Sujet Important : Sécurité, mot de passe, etc.
- 34 réponses
- 13 participants
- 3 206 vues
- 15 followers
Will Zégal
74673
Will Zégal
Membre depuis 22 ans
Sujet de la discussion Posté le 03/06/2010 à 17:21:05Important : Sécurité, mot de passe, etc.
Un membre s'est fait suspendre son compte parce qu'on a détecté qu'il utilisait le même ordinateur qu'un troll qu'on a viré.
Suite à quoi nous avons eu quelques échanges. Voici un de ses derniers messages (la mise en gras est de moi) :
Plusieurs remarques par rapport à ça :
Suite à quoi nous avons eu quelques échanges. Voici un de ses derniers messages (la mise en gras est de moi) :
Citation :
Salut Will
Merci de prendre la peine d'écouter
autant avouer ma connerie tout de suite : ce mec m'a énervé et donc, j'ai essayé de me connecter sur son compte pour le supprimer de l'interieur. et comme ce mec a le mot de passe le plus con du monde, ca a marché du premier coup. Voilà toute l'histoire.
C'était très con, de fait, vu qu'il fallait une confirmation par mail (j'aurais pas été jusque là, comme meme) et que de plus, j'ai partagé la même adresse IP du coup, preuve en est ici. Tu verras d'ailleurs que la conection n'a duré que quelques minutes, que rien n'a été posté, juste "supprimer ce compte".
[...]
Voilà, désolé pour le dérangement en tout cas, la prochaine fois j'éviterais de faire le malin.
Plusieurs remarques par rapport à ça :
- choisissez un mot de passe sécurisé. Ce n'est pas la première fois qu'on a une affaire d'un membre se connectant avec le compte d'un autre membre parce que "le mot de passe était tout con". Mettre votre pseudo ou "audiofanzine" comme mot de passe est tout sauf sécurisé. Rappelez-vous au passage que vous êtes responsable de l'utilisation qui est faite de votre compte, y compris s'il était utilisé pour des choses illégales.
- pirater le compte de quelqu'un, c'est pas très malin. On a vu ici que ça pouvait vous retomber sur le nez (le gars s'en sort parce qu'il n'y avait jamais eu le moindre soucis avec lui auparavant). Par ailleurs, on arrive ici à un gag concernant un troll qui a de toutes façons été viré du site. Mais ce genre de manoeuvre s'apparente carrément à un piratage tout à fait illégal et ceux qui jouent à ça pourraient bien tomber sur un acharné qui les poursuivrait en justice et serait en droit de le faire. Un gag qui peut donc tourner autrement plus sérieusement.
[ Dernière édition du message le 28/07/2011 à 13:28:49 ]
nero
4470
Administrateur·trice du site
Membre depuis 21 ans
21 Posté le 11/06/2010 à 15:58:26
Si le mdp de 10 caractères c'est ton pseudo de 10 caractères....
Sibmol
10751
Drogué·e à l’AFéine
Membre depuis 20 ans
22 Posté le 11/06/2010 à 16:34:36
Zerosquare
4852
Squatteur·euse d’AF
Membre depuis 14 ans
23 Posté le 20/06/2010 à 04:37:46
Citation de : nero
Désolé de remonter un peu le topic, mais ça m'a interpellé.
Je ne vois que deux possibilités pour que tu ai pu faire ce que tu as fait :
- les mots de passes n'utilisent pas de "salt", ce qui est assez moyen AMHA
- quelque chose m'échappe (ce qui est fort possible, surtout vu l'heure)
Environ 10% des membres ont le même mot de passe qu'au moins un autre membre
- Environ 4% des membres ont le même mot de passe qu'au moins deux autres membres
Notez que ni moi ni aucun admin n'a accès aux mots de passe des membres car ils sont encodés. Je me suis débrouillé pour faire ces statistiques à partir des versions encodées.
Désolé de remonter un peu le topic, mais ça m'a interpellé.
Je ne vois que deux possibilités pour que tu ai pu faire ce que tu as fait :
- les mots de passes n'utilisent pas de "salt", ce qui est assez moyen AMHA
- quelque chose m'échappe (ce qui est fort possible, surtout vu l'heure)
[ Dernière édition du message le 20/06/2010 à 04:39:11 ]
Anonyme
24 Posté le 20/06/2010 à 08:08:22
Il est probable que la clé de codage est la même pour tous les mots de passe du forum, donc si l'encodage de deux mots de passe est identique, alors les deux mots de passe en clair sont identiques aussi
Zerosquare
4852
Squatteur·euse d’AF
Membre depuis 14 ans
25 Posté le 20/06/2010 à 08:11:25
Justement, en théorie on utilise un "salt" (une valeur différente pour chaque utilisateur, qui est combinée au mot de passe) pour éviter ça.
Anonyme
26 Posté le 20/06/2010 à 08:16:34
Ce que tu appelles "salt" je l'appellerais " clé privée" et alors il faudrait que chaque utilisateur conserve sa clé privée pour pouvoir se connecter , ce qui est impossible sur un forum grand public .
Zerosquare
4852
Squatteur·euse d’AF
Membre depuis 14 ans
27 Posté le 20/06/2010 à 08:30:44
Non, ce n'est pas la même chose.
Un salt c'est une valeur aléatoire qui est créée en même temps que le compte, stockée dans la base de données (l'utilisateur n'a pas besoin de la connaître), et qui est combinée au mot de passe fourni (par exemple en la rajoutant à la fin).
Ça évite au moins deux problèmes :
- même si deux utilisateurs ont le même mot de passe en clair, le hash (la version "cryptée" si tu veux, mais le terme n'est pas exact, parce que ce n'est pas censé être réversible) ne sera pas le même. Du coup, même en ayant accès à la base de données et ayant compromis un compte, on ne peut pas obtenir d'information sur les autres.
- ça rend les tables de correspondance précalculées (rainbow tables) inutilisables en pratique. Autrement dit, on ne peut plus retrouver simplement un mot de passe en clair à partir du hash.
Un salt c'est une valeur aléatoire qui est créée en même temps que le compte, stockée dans la base de données (l'utilisateur n'a pas besoin de la connaître), et qui est combinée au mot de passe fourni (par exemple en la rajoutant à la fin).
Ça évite au moins deux problèmes :
- même si deux utilisateurs ont le même mot de passe en clair, le hash (la version "cryptée" si tu veux, mais le terme n'est pas exact, parce que ce n'est pas censé être réversible) ne sera pas le même. Du coup, même en ayant accès à la base de données et ayant compromis un compte, on ne peut pas obtenir d'information sur les autres.
- ça rend les tables de correspondance précalculées (rainbow tables) inutilisables en pratique. Autrement dit, on ne peut plus retrouver simplement un mot de passe en clair à partir du hash.
.: Odon Quelconque :.
11001
Drogué·e à l’AFéine
Membre depuis 22 ans
28 Posté le 24/06/2010 à 18:22:34
Je découvre tardivement le concept, mais il me semble que si le salt est stocké dans la base, en cas d'accès non autorisé à celle-ci la sécurité n'est pas tellement meilleure qu'avec le hash du mot de passe seul, non ?
Et quand bien même, un algorithme côté serveur ne prémunirait pas beaucoup plus contre les attaques de type man in the middle (les outils de tampering ne manquant pas), ou bien ?
Et quand bien même, un algorithme côté serveur ne prémunirait pas beaucoup plus contre les attaques de type man in the middle (les outils de tampering ne manquant pas), ou bien ?
« What is full of redundancy or formula is predictably boring. What is free of all structure or discipline is randomly boring. In between lies art. » (Wendy Carlos)
Zerosquare
4852
Squatteur·euse d’AF
Membre depuis 14 ans
29 Posté le 24/06/2010 à 22:10:32
Si quelqu'un a un accès complet à la base de données, évidemment c'est foutu pour la sécurité du site en question : le gars a même pas besoin d'aller s'embêter avec les mots de passe, puisqu'il peut faire directement les modifs qu'il veut dedans. En suivant cette logique, on pourrait même penser que ça ne sert à rien de crypter/hasher les mots de passe, puisque si quelqu'un peut les voir, c'est qu'il est déjà trop tard.
Le hashage du mot de passe sert à résoudre un autre problème : énormément de gens utilisent le même mot de passe (ou peut-être seulement 2 ou 3 différents en tout) pour tous les sites qu'ils utilisent ; ça fait évidemment partie des trucs à ne pas faire, mais en pratique c'est aussi courant que le post-it sur l'écran avec le mot de passe marqué dessus... Du coup, si tu laisses les mots de passe en clair et que quelqu'un hacke ta base de données, il a potentiellement accès aux comptes de tes utilisateurs sur plein d'autres sites.
En théorie, la fonction de hashage est à sens unique, donc il n'est pas possible de retrouver le mot de passe d'origine à partir du hash, à part en essayant tous les mots de passe possibles un à un jusqu'à tomber sur un qui a le même hash. Normalement on choisit la fonction de telle sorte que cette attaque prenne trop de temps pour être raisonnablement faisable.
Mais ces dernières années, des moyens de contourner ce problème ont été trouvés, en particulier les rainbow tables. En gros ce sont de grosses tables précalculées qui accélèrent énormément la recherche.
Pour éviter ça, on rajoute un salt au mot de passe tapé par l'utilisateur, différent pour chaque utilisateur. Du coup, une seule table précalculée ne suffit plus : si tu utilises la méthode précédente, tu vas tomber sur une chaîne qui a le hash de mot de passe+salt, et qui n'aura rien à voir avec le mot de passe d'origine. En fait, il faudrait recréer une table pour chaque valeur de salt. Si tu prends des salts suffisamment longs, c'est un obstacle suffisant pour que ce ne soit pas faisable (pour le moment).
Le hashage du mot de passe sert à résoudre un autre problème : énormément de gens utilisent le même mot de passe (ou peut-être seulement 2 ou 3 différents en tout) pour tous les sites qu'ils utilisent ; ça fait évidemment partie des trucs à ne pas faire, mais en pratique c'est aussi courant que le post-it sur l'écran avec le mot de passe marqué dessus... Du coup, si tu laisses les mots de passe en clair et que quelqu'un hacke ta base de données, il a potentiellement accès aux comptes de tes utilisateurs sur plein d'autres sites.
En théorie, la fonction de hashage est à sens unique, donc il n'est pas possible de retrouver le mot de passe d'origine à partir du hash, à part en essayant tous les mots de passe possibles un à un jusqu'à tomber sur un qui a le même hash. Normalement on choisit la fonction de telle sorte que cette attaque prenne trop de temps pour être raisonnablement faisable.
Mais ces dernières années, des moyens de contourner ce problème ont été trouvés, en particulier les rainbow tables. En gros ce sont de grosses tables précalculées qui accélèrent énormément la recherche.
Pour éviter ça, on rajoute un salt au mot de passe tapé par l'utilisateur, différent pour chaque utilisateur. Du coup, une seule table précalculée ne suffit plus : si tu utilises la méthode précédente, tu vas tomber sur une chaîne qui a le hash de mot de passe+salt, et qui n'aura rien à voir avec le mot de passe d'origine. En fait, il faudrait recréer une table pour chaque valeur de salt. Si tu prends des salts suffisamment longs, c'est un obstacle suffisant pour que ce ne soit pas faisable (pour le moment).
[ Dernière édition du message le 24/06/2010 à 22:16:16 ]
aris
1276
AFicionado·a
Membre depuis 17 ans
30 Posté le 24/06/2010 à 22:47:22
Je sors ma casquette de sécurité informatique (qui est mon métier) et je plussoie mille fois Zerosquare.
- < Liste des sujets
- Charte