Citer un message

En vous enregistrant en tant que membre, vous vous assurez d'avoir votre propre pseudonyme réservé, tout en n'ayant plus à saisir de code de sécurité ni de pseudo. En postant un message, vous déclarez accepter nos conditions générales d'utilisation.

Captcha : Combient font 1 + 1 ? Veuillez ne surtout PAS REPONDRE à la question posée ci-dessus. Ce test vise à nous protéger des robots spammeurs.
Pseudo : Saisissez votre pseudonyme.
Adresse email : N'est pas obligatoire. Ne sera pas affichée. Permet juste d'afficher votre Gravatar si vous en avez un.	Enregistrer mon pseudo et email.
Message : Saisissez le contenu de votre message.	Prévisualisation automatique [quote=Kysic]Il est toujours utile de rappeler ce genre de chose. Juste quelques remarques : - Il faudrait remplacer crypter, crypté et cryptage par chiffrer, chiffré et chiffrement. - L'exemple "_NA" comme grain de sel statique n'est vraiment pas le meilleur puisque l'article le dit lui même, plus il sera compliqué moins il y aura de chance de le trouver dans un dictionnaire. Autant donc prendre comme exemple "0*%mT$AZ.$.?2#h09ml" (puisqu'en plus personne n'aura besoin de mémorisé cette chaîne contrairement à un password). - Il serait possible d'aborder également la longueur du mot de passe. Donner un exemple pour retenir un mot de passe compliqué en le construisant à partir d'une phrase. exemple : Les cinq fruits sont mûrs. => "Ls5Frt$S0ntMûr$." Certains utilisent une base de mot de passe similaire avec une variante en fonction du site, c'est pas forcément super sécu mais c'est facile à se rappeler. Il pourrait expliquer qu'a défaut d'avoir un mot de passe pour chaque site, on peut a minima en avoir certains pour les sites sérieux et de confiance (si tant est que ça existe) et des mots de passe pourris pour les autres sur lesquels se faire pirater son compte n'aurait pas d'importance. - Je rejoins la remarque pnprog, on ne stocke jamais un mot de passe ou son hash dans un cookie, c'est une faille de sécurité majeure, on utilise un id de session que l'on renouvelle à chaque session. Car cela veut dire : le hash du mdp est stocké sur le PC, s'il est volé ou si l'utilisateur est sur un PC publique, celui qui a récupéré le cookie pourra se connecter n'importe quand sur le compte de l'utilisateur. Cela veut également dire que dans chaque requête http vers le site, le hash sera envoyé dans la requête http de l'utilisateur et transitera sur le réseau (alors qu'il ne l'aurait été que lors de la connexion autrement). Enfin si un attaquant arrive a récupérer la liste des hash dans la bd un jour, il pourra se connecter sur n'importe quel compte quand il le souhaite même tant que chaque utilisateur n'aura pas changer de mot de passe en créant un cookie adapté. Idéalement on pourrait même générer un token que l'on met tel quel dans le cookie et dont on stocke le hash dans la bd comme ça si un pirate accède à toute la bd (sans la modifier ni modifier le code su site), il ne pourra pas pour autant utiliser les hash des tokens pour se connecter sur les comptes utilisateurs avec un faux cookie. - Expliquer que choisir le hashage et un grain de sel le meilleur possible est important dès la création du site, une fois les mots de passe des premiers inscrits enregistrés, on ne peut plus changer à moins d'alourdir le code et les vérifications (plusieurs hash successifs). - Et serait également sympathique de parler de la sécurité des procédures de changement de mot de passe, adresse mail, et bien sur de la gestion des mots de passe perdus pour laquelle il y a des choses à ne pas faire. - L'article parle de tunnel ssh pour éviter que le mot de passe circule en clair lors de l'inscription sur un site. Cette information me semble fausse. On n'aura pas un accès ssh sur les serveurs du site (le tunnel ssh est utile dans le cas que j'aborde dans le point suivant) donc le mot de passe circulera en clair quelque part. Pour un site web la meilleure méthode est d'utiliser ssl (https) , ainsi le mot de passe ne passera pas en clair sur le réseau et permettra en plus à l'utilisateur de s'assurer qu'il est bien sur le bon site et ne subit pas une attaque type man in the middle. - Dire qu'il faut faire d'autant plus attention si l'on utilise un réseau wifi publique de ne pas se logguer sur un compte sur un site non https (ou alors en passant par un tunnel ssh vers un PC sous notre contrôle qui à un acces internet sûr, j'entends par là direct avec le FAI avec donc de très faible chance d'avoir un tiers capable d'intercepter et/ou modifier les échanges avec le site).[/quote]