Net-Actuality

Comment vos mots de passe sont protégés (ou pas) sur le net

Comment vos mots de passe sont protégés (ou pas) sur le net

L'une des clés de voûte assurant la sécurité de vos données personnelles sur Internet, c'est le mot de passe. En effet, ce précieux sésame permet de protéger l'accès aux comptes que vous possédez sur divers sites Internet. Pourtant, les mesures de sécurité mises en œuvre pour les protéger sont rarement très poussées.

Après vous avoir expliqué le principe de fonctionnement de l'identification par mot de passe, je vais essayer de vous montrer comment les sites peuvent s'y prendre pour protéger vos mots de passe, en vous présentant quelques méthodes utilisées par les développeurs. Après cela, je vous donnerai quelques conseils pour essayer de mieux protéger vos mots de passe de votre côté, puis vous montrerai que leur sécurité est malgré tout très difficile à assurer.

Principe de fonctionnement de l'identification par mot de passe

Avant de parler de la sécurité des mots de passe, il faut comprendre le fonctionnement de ces derniers. Lorsque vous vous inscrivez sur un site comme Net-Actuality, le script d'inscription ajoute, dans une base de données, une ligne contenant le pseudo, l'adresse email ainsi que le mot de passe que vous avez choisis. Par la suite, lorsque vous tentez de vous connecter, le script de connexion compare les informations que vous avez saisies dans le formulaire de connexion à celles qui sont présentes dans la base de données du site. Si elles coïncident, il vous connecte à votre compte ; dans le cas contraire, il vous refuse la connexion.

Imaginons que je crée un compte sur Net-Actuality avec le pseudo « Florian » et le mot de passe « azerty ». Si je renseigne, sur le formulaire de connexion, le pseudo « Florian », le script va chercher cette occurrence dans la base de données et la trouver. Pour passer l'étape de la connexion, il va maintenant comparer le mot de passe que j'ai saisi à celui stocké dans la base de données, puis me connecter à mon compte si le résultat est positif.


Gauche : schéma du processus d'inscription / Droite : schéma du processus de connexion.

Pour prendre un exemple plus concret, c'est comme à la banque. Si vous essayez d'ouvrir un coffre fort, vous avez à la fois besoin du numéro du coffre et d'une clé ou d'un code lui étant associé. La mauvaise clé utilisée avec le bon coffre ou la bonne clé utilisé avec le mauvais coffre se traduisant fatalement par un échec.

Comment les sites essaient de protéger les mots de passe ou pas

Cryptage des mots de passe

C'est lors de l'enregistrement dans la base de données que la confidentialité de vos données est assurée ou pas. En effet, lorsque le script d'enregistrement enregistre vos informations dans la base de données, y compris votre mot de passe, il a deux choix : le stocker tel quel ou le crypter.

L'intérêt du cryptage ? Il est très simple : imaginez qu'un individu malintentionné arrivait à accéder la base de données d'un site sur lequel vous êtes inscrit. Si votre mot de passe n'y était pas crypté, le pirate pourrait alors le récupérer et s'en servir sur l'ensemble des sites sur lesquels vous êtes inscrits avec le même mot de passe. Comment trouverait-il les sites sur lesquels vous êtes inscrit me demandez-vous dubitatif ? Une petite recherche sur Google, avec votre email ou votre pseudo, et le tour est joué ! Pire encore, supposons que vous vous soyez inscrit avec votre adresse Gmail et que vous ayez utilisé le même mot de passe aux deux endroits : le pirate pourrait alors accéder à votre compte mail en toute impunité.

Le but, vous l'aurez donc compris, c'est d'augmenter la sécurité de votre mot de passe. Pour cela, avant d'enregistrer celui-ci dans la base de données, le script va le crypter. Ainsi, si un utilisateur arrivait à accéder à la base de données, il n'obtiendrait pas votre mot de passe en clair, mais de manière cryptée : inutilisable donc, en apparence.


Schéma présentant le processus de stockage des informations dans la base de données.

Maintenant que vous avez saisi l'intérêt du cryptage, vous allez me demander comment le script de connexion fait pour comparer le mot de passe crypté (que j'appellerai « hash » par la suite) et celui que l'utilisateur saisit lorsqu'il veut se connecter. En effet, l'utilisateur n'ayant pas connaissance du mot de passe crypté et ne sachant sûrement même pas que vous le site le crypte, il saisira l'original lorsqu'il tentera de se connecter. Si avez bien compris le principe de fonctionnement du système d'identification que je vous ai expliqué tout à l'heure, vous saisissez le problème : le mot de passe original connu de l'internaute n'est pas égal au mot de passe crypté connu de la base de données.

L'astuce, pour contourner ce problème, est simple : le script de connexion va crypter le mot de passe saisi par l'utilisateur avant de le comparer à celui stocké dans la base de données. Selon la même méthode que lors de l'enregistrement, donc. Magie, magie !


Schéma du processus de connexion avec un mot de passe crypté.

C'est justement à cause de ce cryptage que certains sites ne peuvent pas vous rappeler votre mot de passe quand le perdez et qu'ils en génèrent un nouveau pour vous. En effet, les fonctions de hachage fonctionnent à sens unique. Par conséquent, lorsqu'un site est capable de vous le restituer, c'est généralement qu'il ne crypte pas les mots de passe dans sa base de données ; vous pouvez alors vous inquiéter pour la sécurité de vos données.

Pour résumer : La sécurité des mots de passe repose en grande partie sur leur cryptage dans la base de données.

Un algorithme pour crypter vos mots de passe : le MD5

Sur beaucoup de sites, c'est la fonction de cryptage (ou plutôt de hachage) MD5 qui est utilisée. Sa fonction est simple : elle transforme une chaine de caractères initiale (mon mot de passe « azerty »), en une nouvelle chaine de 32 caractères (128 bits) supposée unique. Avec cet algorithme, mon mot de passe « azerty » est transformé en « ab4f63f9ac65152575886860dde480a1 ».

Ainsi, avec ce système, si un individu malintentionné arrivait à accéder à la base de données d'un site sur lequel vous êtes inscrit, il arriverait seulement à récupérer le mot de passe crypté et non le précieux sésame, c'est-à-dire votre mot de passe personnel. De ce fait, il ne pourrait pas s'en servir directement sur des sites où vous l'auriez également utilisé. Sympa, non ?

Pas tellement, en fait... puisque l'utilisation de ce simple algorithme, bien que très (trop) répandue, est malheureusement loin d'être vraiment efficace.

Entre autres choses :

  1. En théorie, le décryptage d'un hash MD5 est impossible, mais en théorie seulement. En effet, MD5 étant très utilisé (et c'est un euphémisme), de nombreux dictionnaires « inversés » existent. Ainsi, comme sur un annuaire de téléphonie inversé, vous entrez le mot de passé crypté et le dictionnaire vous retourne le mot de passe d'origine, à condition qu'il le connaisse. Par conséquent, la plupart des mots de passe génériques, communs et courts (« azerty », « hello », « 123 »...), peuvent être décryptés en un clin d'œil.
  2. Le risque de collision. Kezako ? Concrètement, c'est le fait d'obtenir la même chaîne cryptée à partir de deux chaines de caractères différentes. Pour prendre un exemple concrêt, si « azerty » et « azerty2 » donnaient tous deux le hash « ab4f63f9ac65152575886860dde480a1 », on pourrait considérer cela comme une collision. Les risques, pour vos données sont plus que limités, mais une collision peut néanmoins permettre à quelqu'un d'accéder à votre compte alors même qu'il n'a pas saisi le bon mot de passe. Une chance sur quelques millions, je vous l'accorde, la collision restant difficile à mettre en œuvre.
  3. Imaginons qu'un des sites sur lesquels vous êtes inscrit se fait pirater. Supposons également qu'un autre site sur lequel vous êtes inscrit avec ce même mot de passe utilise le même type de cryptage. Dans ces deux cas, les mots de passe cryptés stockés dans les bases de données des deux sites seraient donc identiques. Imaginons en plus que le site « sain » utilise la méthode d'identification par cookies. Il suffirait alors au pirate de créer un cookie contenant le mot de passe crypté afin de se connecter au site non piraté. Je vous l'accorde, ça paraît extrême, mais c'est pourtant un véritable danger.


Schéma présentant ce qu'est une collision.

Pour résumer : MD5 est un premier rempart, pourtant loin d'être infaillible.

D'autres algorithmes pour crypter vos mots de passe

Vu les limites du MD5, de nombreux sites commencent à l'abandonner, au profit d'algorithmes jugés plus fiables. Ainsi, l'utilisation du SHA1 commence petit à petit à prendre le pas sur celle du MD5, car les collisions sont plus difficiles et les dictionnaires de mots de passe encore peu fournis, du fait de sa jeunesse.

Mais est-ce suffisant ? Non, car s'il était hier encore réputé fiable, il commence déjà à montrer ses limites ; les mêmes que celles du MD5.

Et c'est un cercle infini : les nouveaux arrivants, tels que SHA256 (qu'on préféra désormais), SHA512 ou encore Whirlpool non, non, pas les machines à laver , apportent tous une sécurité supplémentaire, dans la mesure où le nombre de caractères de la chaine cryptée augmente toujours. Imaginez : si azerty devient « f2d81a260dea8a100dd517984e53c56a7523d96942a834b9cdc249bd4e8c7aa9 » (SHA256) plutôt que « ab4f63f9ac65152575886860dde480a1 » (MD5), du fait de sa grandeur, le risque de collision est moins élevé, car il y a plus de combinaisons possibles. De plus, les tentatives d'attaque par brute force seront très longues, car il est moins facile de venir à bout d'un code de 32 caractères que de 64 caractères !

Pourtant, ils finiront toujours pas perdre en efficacité au fil du temps, dans la mesure où plus un algorithme est utilisé, plus les dictionnaires de mots de passe deviennent fournis.


Schéma présentant les principaux algorithmes de cryptage.

Pour résumer : MD5, SHA1, SHA256, SHA512, Whirlpool... Au final, ce n'est pas tant l'algorithme qui pose problème, mais c'est plutôt les limites de la technique inhérente au cryptage. C'est pourquoi il est intéressant de mettre en place une méthode supplémentaire pour protéger les mots de passe sur un site.

Les grains de sel statiques

L'idée, pour améliorer la sécurité des mots de passe, c'est donc d'utiliser un grain de sel (aussi appelé « salt »).

Kezako ? Lors de l'enregistrement de votre mot de passe dans la base de données, le script d'enregistrement effectue deux actions avant de stocker vos informations dans la base de données :

  1. Il va ajouter un « code secret » après le mot de passe, commun à tous les utilisateurs et stocké dans le code PHP. Par exemple, il va ajouter le grain de sel « _NA » après le mot de passe, ce qui donnera : « azerty_NA ».
  2. Le script va ensuite effectuer l'étape du cryptage du mot de passe modifié. Ici, il va crypter « azerty_NA » en MD5 et l'enregistrer dans la base de données, ce qui donnera : « ed50abc53d3f1b481bfc6641349afbb4 », au lieu de « ab4f63f9ac65152575886860dde480a1 » sans sel.


Schéma présentant le processus de fonctionnant des grains de sel statiques.

Quel intérêt ? Les bénéfices, ici, sont nombreux, car ils pallient presque tous aux défauts des méthodes de cryptage que j'avais soulevés précédemment :

  1. Même si l'un des sites sur lesquels vous étiez inscrit avec ce même mot de passe utilisait le même type de cryptage, le mot de passe enregistré dans sa base de données saine ne serait plus identique à celui récupéré sur la base piratée. Par conséquent, même si le site non piraté utilisait la méthode d'identification par cookies, le pirate ne pourrait pas y accéder à l'aide d'un cookie fabriqué.
  2. L'utilisation de dictionnaires inversés de mots de passe devient plus compliquée. En effet, il est moins probable que ceux-ci possèdent l'occurrence « azerty_NA » que « azerty ». Avec un grain de sel original, la possibilité que le dictionnaire dispose de ce mot de passe est donc diminuée.
  3. Dans le cas d'attaque par brute force ou si le mot de passe est présent dans le dictionnaire, le pirate obtiendrait le mot de passe tel que modifié : « azerty_NA ». Le problème pour lui, c'est qu'il ne saurait pas quel est le grain de sel, donc il ne pourrait pas utiliser le mot de passe, sauf s'il arrivait à localiser et à supprimer le salt.
  4. Enfin, les grains de sel permettent de lutter contre les lacunes de vos propres mots de passe, qu'il soient trop communs ou trop courts. Par dictionnaire inversé, « azerty » est en effet trouvé sans problème, alors que « azerty_NA» ne le sera pas forcément.


Pour résumer : D'une efficacité effarante, le grain de sel est pourtant assez peu utilisé, car peu connu. Bien sûr, si le pirate accède également au fichier côté serveur qui contient le sel, il aura connaissance de celui-ci, donc la protection offerte sera moins efficace.

Les grains de sel dynamiques

Avec les grains de sel, on peut même aller encore plus loin ! L'arme ultime, c'est en effet d'utiliser un second grain de sel, dynamique cette fois. C'est-à-dire qu'on va utiliser un code secret propre à chacun des utilisateurs qui sera apposé au mot de passe. On peut, par exemple, en générer un automatiquement, ou alors utiliser la date d'inscription de l'utilisateur, puis le stocker dans la base de données.

Lors de l'enregistrement de votre mot de passe dans la base de données, le script d'enregistrement va alors effectuer trois actions avant de stocker vos informations dans la base de données :

  1. Il va ajouter un « code secret » après le mot de passe, commun à tous les utilisateurs et stocké dans le code PHP. Ainsi, comme tout à l'heure, il va ajouter le grain de sel « _NA » après le mot de passe, ce qui donnera : « azerty_NA » (« ab4f63f9ac65152575886860dde480a1 »)
  2. La nouveauté, c'est qu'il va ensuite apposer le second grain de sel avant le mot de passe. Ici, supposons que mon grain de sel personnel soit « BoGoss », le mot de passe deviendra : « BoGossazerty_NA ».
  3. Le script va maintenant effectuer l'étape du cryptage de ce mot de passe modifié. Ici, il va donc crypter « BoGossazerty_NA » et l'enregistrer dans la base de données, ce qui donnera : « 56570953e016a8cdcde313bfe8152ff4 ».


Schéma présentant le processus de fonctionnant des grains de sel dynamiques.

Je vous vois venir : c'est inutile, puisque si le pirate réussit à accéder à la base de données, il découvre le sel dynamique ! Certes, mais ça complique lourdement sa tache, et c'est une raison suffisante pour le maître en place : on ne va quand même pas lui simplifier la tâche, à cette tâche !

En plus des avantages offerts par le sel statique, il en offre d'autres (ou les améliore) :

  1. Ici, l'utilisation d'un dictionnaire de mots de passe est inefficace dans 95% des cas. En effet, du fait de l'accumulation d'un grain de sel statique et d'un autre dynamique atypique, il y a très peu de chances qu'il possède une entrée répondant au hash piraté.
  2. Le pirate est obligé de mettre en place une procédure spécifique à chaque utilisateur s'il veut décrypter le mot de passe. Vous imaginez la galère !
  3. Ce salt dynamique permet de faire en sorte qu'aucun membre n'ait le même mot de passe crypté que vous. En effet, avec ces fonctions de cryptage, si deux utilisateurs ont choisi le même mot de passe, le hash des deux utilisateurs sera identique. Ca ne pose pas forcément de gros problèmes de sécurité, mais ce n'est pas forcément très appréciable, dans la mesure où, si vous connaissez le mot de passe non crypté de l'un des deux membres, vous êtes en mesure de connaître celui du second ! Ici, dans la mesure où le grain de sel est propre à chaque utilisateur, chacun a un hash différent. Il est même quasiment impossible que deux membres aient le même hash !

Pour résumer : L'utilisation de grains de sel associée au cryptage du mot de passe représente une arme redoutable pour assurer la sécurité de vos données.

Comment les protéger, de votre côté

De votre côté, vous disposez de quelques options qui vous permettront de limiter la casse et d'assurer au maximum votre sécurité dans l'hypothèse où l'une des bases de données d'un site sur lequel vous êtes inscrit venait à être piraté.

D'une part, il est primordial d'essayer de ne pas utiliser le même mot de passe partout. Je sais que c'est plus facile à dire qu'à faire, et je sais de quoi je parle : si on le faisait vraiment, on en finirait plus ! L'idée, c'est donc d'avoir trois mots de passe : un premier destiné aux sites critiques (banque, compte mail), un mot de passe « poubelle » pour les sites où vous ne comptez pas repasser ou qui ne vous inspirent pas confiance, et un dernier pour les sites avec une importance ni nulle, ni critique (Net-Actuality par exemple ).

D'autre part, choisissez un mot de passe original (pas le nom de votre chien, votre date de naissance), ni trop court, ni trop long. En outre, n'utilisez surtout pas de mot de passe commun (« azerty », « 123 », « hello »...). L'arme ultime reste d'associer chiffres et lettres, le summum étant d'y ajouter des caractères spéciaux (*, ^, @, #...), voire même de varier majuscules et minuscules dans le genre parano, on ne fait pas mieux

J'ai d'ailleurs hésité à lister ces dernières mesures dans la section précédente, car elles peuvent parfois même être mises en place du côté serveur. En effet, certains sites vous obligent parfois à choisir un mot de passe associant chiffres et lettres, ou faisant un minimum de caractères. Ca agace parfois lorsque l'on doit trouver un nouveau mot de passe, mais c'est pourtant pour notre bien !

Enfin, cela va de soi, mais évitez de vous inscrire sur des sites que vous ne pensez pas dignes de confiance, ou alors, confiez leur un mot de passe poubelle, comme conseillé tout à l'heure.

Pour résumer : Un mot de passe original et différent selon les sites est une solution idéale pour rendre vos mots de passe plus sécurisés.

Leur protection est-elle vraiment possible ?

Vous l'aurez donc compris, même en prenant toutes les précautions pour avoir un mot de passe solide, l'inscription sur un site ne sécurisant pas correctement vos données peut être fatale. Il faut savoir que beaucoup de sites n'utilisent qu'un simple hachage en MD5, qui n'est pourtant plus très fiable. Pire, certains sites (des boutiques parfois, même !) ne cryptent pas vos mots de passe ! Ainsi, n'hésitez pas à mener votre propre investigation, grâce à la méthode décrite tout à l'heure (formulaire de récupération de mot de passe). Vous pouvez également vous amuser à deviner quel type d'encodage le site utilise en passant en revue votre cookie, et plus particulièrement le champ mot de passe qui s'y trouve (s'il fait 32 caractères, c'est du SHA1/MD5, 64 caractères : SHA256, 128 caractères : SHA512/Whirlpool).


Schéma présentant comment décoder un cookie.

Malgré toutes les précautions à prendre du côté serveur et utilisateur, il faut prendre conscience que la sécurité de vos mots de passe sera toujours faillible. En effet, si un individu malintentionné n'arrive pas à récupérer les mots de passe depuis la base de données, il utilisera fatalement d'autres méthodes. Par exemple, il est possible que quelqu'un puisse accéder à votre mot de passe lorsqu'il transite, de manière non cryptée, de votre navigateur vers le serveur, lors de l'inscription ou de la connexion par exemple (il est néanmoins possible de s'en prémunir avec un tunnel SSH).

De même, de nombreux sites (pour ne pas dire la quasi totalité) envoient votre mot de passe en clair par email lorsque vous vous inscrivez. Là aussi, votre mot de passe pourrait être récupéré lors du transit du mail.

Pire encore, il est même possible que des webmestres peu scrupuleux décident de se servir de leurs bases de données pour tenter de récupérer la mine d'or. Imaginez un méchant webmestre. Supposez qu'un de ses membres s'inscrive sur son site avec son compte Yahoo et le même mot de passe : c'est le jackpot, car il peut alors accéder au compte mail de sa victime avec une facilité déconcertante !

Vous l'aurez donc compris, la protection des mots de passe, sur Internet, se fait à tous les niveaux. Il faut surtout retenir que l'arme ultime n'existe pas et que c'est là même le propre de l'informatique : aucun système n'est infaillible. La prudence est donc de mise.

Flux RSS des derniers billets publiés.

Ils ont dit...

n°2 - Ecrit par Ldfa (Visiteur), .

Rang : Visiteur

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

n°4 - Ecrit par pnprog (Visiteur), .

Rang : Visiteur

Vous pouvez également vous amuser à deviner quel type d'encodage le
site utilise en passant en revue votre cookie, et plus particulièrement
le champ mot de passe qui s'y trouve (s'il fait 32 caractères, c'est du
SHA1/MD5, 64 caractères : SHA256, 128 caractères : SHA512/Whirlpool).

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.

n°5 - Ecrit par leroiarthur, .

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 ?

n°6 - Ecrit par Florian, .

pnprog (visiteur) a dit :

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. [...]
Oui, pas mal comme système ! Pas pensé à l'évoquer dans l'article, mais il ne se veut pas exhaustif


leroiarthur a dit :

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 ?

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.

n°7 - Ecrit par 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).

[ Ce message a été modifié pour la dernière fois ].

n°8 - Ecrit par Mike (Visiteur), .

Rang : Visiteur

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

n°9 - Ecrit par Mike (Visiteur), .

Rang : Visiteur

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

Merci d'avance.

n°10 - Ecrit par Florian, .

Mike (visiteur) a dit :


Mais moi quand je rentre mon mot de passe,azerty, il est calculé le hash: H(azerty).
H(azerty) n'est pas égal à (BoGossazerty_NA). Donc je ne peux pas m'authentifier, non ?

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

Mike (visiteur) a dit :


Ma question est: Comme ce grain est commun, il suffit qu'il obtienne un mot de passe +grain statique d'un autre utilisateur (qwerty_NA). Il voit bien que le grain est _NA.
Donc il faut mieux utiliser un grain dynamique qui est spécifique à l'utilisateur.

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

Flux RSS des derniers commentaires publiés sur le billet.

Ajouter un commentaire

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 :Si vous voyez les champs suivants, veuillez ne surtout PAS LES COMPLETER. Ce test vise à nous protéger des robots spammeurs.
Mémoriser mes identifiants : Sauvegarde votre pseudo et votre adresse e-mail, afin que n'ayez plus à les resaisir ultérieurement.