Se connecter
Se connecter

ou
Créer un compte

ou

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

  • 34 réponses
  • 13 participants
  • 3 208 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
31
Ok évidement pour ne pas laisser les mots de passe en clair dans la base, afin qu'un simple accès en lecture si elle est dans la partie accessible par HTTP du site ne compromette pas tous les comptes.

Mais comment est généré le salt unique et pérenne pour chaque utilisateur, où est-il stocké si ce n'est dans la base et surtout comment ce salt - sinon les informations qui permettent de le calculer - est-il transmis avec le mot de passe par le client lors de l'authentification ? J'imagine bien qu'avec un carte à puce ou un lecteur d'empreintes, transmettre des informations supplémentaires garantissant la légitimité de l'utilisateur est possible, mais avec un simple couple identifiant/mdp ?

Ceci dit, j'imagine que nero ne va pas détailler la politique et les algorithmes d'authentification d'AF sur le forum.
1898130.gif

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

32
Le salt est stocké dans la base de donnée au même endroit que le hash. En gros, au lieu d'avoir que le hash(mdp) on stocke "salt.hash(salt.mdp)" où salt est visible. Regardes ici pour plus d'infos et d'exemples
33
Citation de .: Otto von Zine :. :
Mais comment est généré le salt unique et pérenne pour chaque utilisateur, où est-il stocké si ce n'est dans la base et surtout comment ce salt - sinon les informations qui permettent de le calculer - est-il transmis avec le mot de passe par le client lors de l'authentification ?
Le salt n'est pas vraiment confidentiel, en fait. Ce qui est important, c'est qu'il soit différent pour chaque utilisateur : une valeur aléatoire choisie à la création du compte convient parfaitement. Tu peux tout-à-fait le stocker dans ta base de données avec le hash du mot de passe. Et tu n'as pas besoin de le transmettre à l'utilisateur, le calcul peut se faire sur le serveur.

Rajouter un salt, c'est grosso-modo équivalent à passer d'une fonction de hashage unique pour tout le monde (donc analysable d'avance) à n fonctions différentes, n étant le nombre de salts différents possibles. Et connaître le salt est équivalent à savoir laquelle de ces n fonctions a été utilisée, c'est tout : ça n'aide pas à casser le mot de passe.

Citation de .: Otto von Zine :. :
Ceci dit, j'imagine que nero ne va pas détailler la politique et les algorithmes d'authentification d'AF sur le forum.
Je ne sais pas, Nero fait ce qu'il veut

Ceci dit, l'une des règles essentielles de la sécurité informatique, c'est que celle-ci doit reposer sur la sûreté des algorithmes (c'est le boulot des chercheurs en cryptographie d'évaluer ça) et non sur le fait qu'il soient secrets. Les méthodes publiques ont été étudiées et testées "grandeur nature", donc leurs avantages et inconvénients sont connus. Alors que si tu bricoles un truc secret dans ton coin, il n'y a personne pour vérifier qu'il n'y a pas de faille (même des petites modifications en apparence mineures peuvent avoir de grosse répercussions en matière de sécurité). Et rien ne dit que ta méthode secrète ne sera pas découverte : tu penseras alors être en sécurité alors que ce n'est pas vrai...
34
Les gars, vos discussions techniques sont passionnantes, mais je dois siffler la fin de la récré et vous inviter à aller continuer ailleurs votre hors-sujet.

Le propos de ce sujet est d'inviter les membres à faire un peu plus gaffe à leur choix de mot de passe, pas de discourir de la sécurité des bases de données ;-)
35

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