Se connecter
Se connecter

ou
Créer un compte

ou

Sujet Important : Sécurité, mot de passe, etc.

  • 34 réponses
  • 13 participants
  • 3 206 vues
  • 15 followers
Sujet de la discussion Important : 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) :

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 ]

Afficher le sujet de la discussion
21
Si le mdp de 10 caractères c'est ton pseudo de 10 caractères.... redface2
22
23
Citation de : nero
  • Environ 4% des membres ont le même mot de passe qu'au moins deux autres membres
Environ 10% des membres ont le même mot de passe qu'au moins un autre membre

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 ]

24
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
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.
26
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 .
27
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.

28
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 ?

:?:

« 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)

29
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).

[ Dernière édition du message le 24/06/2010 à 22:16:16 ]

30
Je sors ma casquette de sécurité informatique (qui est mon métier) et je plussoie mille fois Zerosquare.