Sympa

Je pense que ce devrait être : 'puis vous montrerai'
Mais je ne suis pas un spécialiste.

Corrigés, merci

Il ne faut normalement pas enregistrer le mot de passe dans le cookie (ni nulle part ailleurs en fin de compte), ni même son hash.
L'idée, c'est qu'au moment de la connexion, on compose aléatoirement chaine de caratères (un jeton ou "token" que l'on stocke dans la base de donnée (à la ligne correspondant à l'utilisateur) et dans le cookie.
Lors de la connexion automatique, on compare le jeton du cookie à celui de la base de donnée pour autoriser ou non la connexion automatique.
Toute nouvelle connexion crée un nouveau jeton et périme donc automatiquement l'ancien. De la sorte, un jeton dans un cookie reste valide jusqu'à ce que l'ont se connecte depuis un autre poste.

Et ne serait-il pas mieux d'avoir un protocole de cryptage unique pour chaque site ? C'est sûrement quelque chose d'extrêmement complexe, mais des sites comme PayPal ou des e-boutiques n'utilisent-elles pas leur propre système de cryptage de données ?

Oui, pas mal comme système ! Pas pensé à l'évoquer dans l'article, mais il ne se veut pas exhaustif



En théorie, ça serait l'idéal. Mais :

1/ Je n'imagine pas chaque webmestre mettre au point son propre système de cryptage !
2/ Car, si on utilise encore les algorithmes que j'ai cités, c'est avant tout car ils ont été construits par des experts et qu'ils font bien mieux qu'une fonction codée par le "webmestre du coin" qui n'est pas spécialiste en cryptologie.

Les grains de sel permettent de faire un peu ce que tu proposes, mais de manière bien moins poussée.

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

[ Ce message a été modifié pour la dernière fois le 13 mars 2011, à 12:06 ]

Bonjour !

J'ai pris beaucoup plaisir à lire cet article (d'autant qu'il est précis). Alors merci.

Il y a des choses que je n'ai pas comprises. Pouvez me les expliquer ?

1) J'ai compris le principe du mot de passe. (on stocke la valeur hachée initiale du mot de passe, qui sera comparée à la valeur hachée nouvellement calculée lorsque l'on rentre le mot de passe.)

Mon problème se situe au niveau du salage. Les grains vont ajouter des chaines de caractères, et donc, modifier le hash. La valeur stockée sur l'ordinateur sera, par exemple, H(BoGossazerty_NA) avec H la fonction de hachage.
Mais, moi, quand je rentre mon mot de passe, azerty : le hash est calculé : H(azerty).
Or, H(azerty) n'est pas égal à (BoGossazerty_NA). Donc je ne peux pas m'authentifier, non ?

2) Vous avez écrit que le grain statique est commun à tous les utilisateurs d'une base de données. (_NA). Il permet d'augmenter la sécurité.
Dans la partie "intérêt", vous dîtes que si un pirate réussi à passer le problème du hachage (par attaque brute ou dictionnaire), il obtiendra le mots de passe et le grain statique, sans savoir "qui est qui".
Ma question est : comme ce grain est commun, il suffit qu'il obtienne un mot de passe et le grain statique d'un autre utilisateur (qwerty_NA). Il voit alors que le grain est _NA.
Donc il faut mieux utiliser un grain dynamique qui est spécifique à l'utilisateur.

Merci de vos réponses

Si vous voulez que je reformule mes questions, dîtes le moi.

Merci d'avance.

En fait, lorsque la vérification est faite, le système va calculer le hash seulement après que le grain de sel ait été concaténé au mot de passe saisi par l'utilisateur.
Ex :
- l'utilisateur saisi "azerty"
- le script va lui adjoindre le sel statique et/ou dynamique : BoGossazerty_NA
- puis il le hashe
- enfin, il fait les comparaisons entre ce qui a été saisi et ce qui est dans la base de données


Oui, s'il trouve plusieurs mots de passe, il pourra le détecter et le grain de sel ne servira plus à rien. L'idée du grain de sel statique est de compliquer, un peu, la tâche de l'utilisateur pour le brute-force.

@Kysic
Merci pour les remarques. Je n'ai pas eu le temps de m'y attardé, mais dès que j'ai cinq minutes, je compléterai sans doute l'article avec les différentes remarques effectuées par tout le monde.

[ Ce message a été modifié pour la dernière fois le 5 mai 2011, à 17:15 ]

Bonjour,

Merci pour vos réponses !

Mais je veux juste rebondir sur ce que vous avez écrit :


Le grain statique est commun à tous les utilisateurs. Cependant, le grain dynamique étant spécifique, comment le site en question peut savoir s'il correspond à cet utilisateur là et un pas un autre ? Est ce par rapport à un login ?

Cordialement,

Mike

Le grain dynamique correspondra à une caractéristique correspondant à l'utilisateur. Par exemple, on pourra utiliser une partie de son adresse e-mail ou encore son pseudo.

Tout en sachant qu'il faut se baser sur des données qui ne changeront pas.

Prenons un exemple :
- je décide de baser le sel dynamique sur le pseudo des utilisateurs
- on a un utilisateur "dupont" avec le mot de passe "azerty"
- son mot de passe hashé est égal à : H(azertydupont)
- quand il va se connecter, le système d'authentification va concaténer, au mot de passe saisi, le pseudo de l'utilisateur, soit : H(azertydupont)
- puis il va le comparer à celui stocké dans la base de données (ça sera positif dans ce cas précis)

Jusque là, tout va bien. Cependant, imaginons maintenant que l'utilisateur change son pseudo en "dupuis" :
- lorsqu'il va se connecter, le système d'authentification va concaténer, au mot de passe saisi, le nouveau pseudo de l'utilisateur, soit : H(azertydupuis)
- puis il va le comparer celui stocké dans la base de données (H(azertydupont)), ce qui n'est pas égal. -> Problème !

En espérant avoir été clair.

[ Ce message a été modifié pour la dernière fois le 5 mai 2011, à 17:21 ]