Il ne faut pas tout confondre. Là on parle de processus qui permettent de stocker des données de manière sécurisée. Les données sont bien issues d'un processus de chiffrement. Ces mots de passe sont donc chiffrés. Du reste, il doit toujours être possible de déchiffrer des données chiffrées (mais uniquement pour celui qui possède la clé).
Pour un tiers non autorisé, ça reste bien des données chiffrées pour lesquelles il ne dispose pas de la clé de déchiffrement. Le fait que dans ce cas il n'y ait pas d'autre choix que de décrypter les données pour y avoir accès n'enlève rien au fait qu'il a fallu connaître la clé de chiffrement pour procéder à l'opération initiale.
Concernant la production de données cryptées, si l'on va par là et pour s'amuser un peu, ça revient à dire que pour les obtenir on réalise une opération sur des données sans avoir connaissance de la clé utilisée. Seule une opération de décryptage est alors possible ensuite. Perso, je préfère éviter de stocker mes données sensibles comme ça :D …
Le chiffrement implique l'utilisation d'une clé et la possibilité de déchiffrer le message à partir de celle-ci. Dans le cadre de la conservation d'un mot de passe, Milosh a raison, on ne doit pas utiliser le chiffrement, car on ne doit pas pouvoir obtenir le message initial (ici, le mot de passe) à partir du message chiffré. La compromission de la clé de chiffrement impliquerait la compromission de tous les mots de passe.
Dans la plupart des cas, les mots de passes sont conservés sous formes hachés (et non chiffrés). Le principe de hachage cryptographique consiste à appliquer une succession d'opération à une donnée afin de générer une valeur unique, communément appelée empreinte. C'est sous cette forme que doit être conservée les mots de passe car le processus de hachage est théoriquement non réversible. La possession de l'empreinte et la connaissance de l'algorithme de hachage utilisé ne permettent pas de revenir au message original.
Dans le cas des mots de passe, pour vérifier que l'utilisateur est en possession du bon mot de passe. Il faut rejouer le processus utilisé pour générer l'empreinte du mot de passe sur celui que vient de donner l'utilisateur. Si l'empreinte générée corresponds à celle conservé par le système, l'utilisateur est bien en possession du mot de passe.
Je n'ai volontairement pas abordé la question du sel, des rainbow tables et de l'importance du choix des algorithmes de hachage. Pour ceux et celles qui veulent aller plus loin, les pages wikipedia relatives au chiffrement et au fonction de hachage cryptographique sont assez complètes.
Chiffré ou crypté c'est pas important, on appelle ça un abus de langage et dans le contexte ça ne pose pas de problème, car c'est un article pour le commun des mortels, pas une publication scientifique. Dans le langage courant ça arrive de confondre « bus » avec « car », « gruyère » avec « emmental » ou « Linux » à la place de « GNU/Linux » et on s'en sort bien pour communiquer.
À cette occasion. Lorsque j'ai publié “Linux aux petits oignons” en 2009, je me suis fait salement incendier sur LinuxFR.org parce qu'il y avait pas “GNU/Linux” dans le titre. Un de ces talibans du libre est même allé jusqu'à m'écrire un mail à rallonge pour m'expliquer la gravité de mon manquement. J'ai transféré le mail à la directrice de collection chez Eyrolles, et elle lui a répondu directement. En le remerciant infiniment pour sa perspicacité, et en l'informant qu'Eyrolles allait procéder de ce pas à la destruction des 3.000 exemplaires imprimés.
Chiffrés * bordel
Certainement pas ! Le stockage de mots de passe chiffrés est une absurdité. Jamais il ne doit etre possible de déchiffrer les mots de passe.
Il ne faut pas tout confondre. Là on parle de processus qui permettent de stocker des données de manière sécurisée. Les données sont bien issues d'un processus de chiffrement. Ces mots de passe sont donc chiffrés. Du reste, il doit toujours être possible de déchiffrer des données chiffrées (mais uniquement pour celui qui possède la clé).
Pour un tiers non autorisé, ça reste bien des données chiffrées pour lesquelles il ne dispose pas de la clé de déchiffrement. Le fait que dans ce cas il n'y ait pas d'autre choix que de décrypter les données pour y avoir accès n'enlève rien au fait qu'il a fallu connaître la clé de chiffrement pour procéder à l'opération initiale.
Concernant la production de données cryptées, si l'on va par là et pour s'amuser un peu, ça revient à dire que pour les obtenir on réalise une opération sur des données sans avoir connaissance de la clé utilisée. Seule une opération de décryptage est alors possible ensuite. Perso, je préfère éviter de stocker mes données sensibles comme ça :D …
Le chiffrement implique l'utilisation d'une clé et la possibilité de déchiffrer le message à partir de celle-ci. Dans le cadre de la conservation d'un mot de passe, Milosh a raison, on ne doit pas utiliser le chiffrement, car on ne doit pas pouvoir obtenir le message initial (ici, le mot de passe) à partir du message chiffré. La compromission de la clé de chiffrement impliquerait la compromission de tous les mots de passe.
Dans la plupart des cas, les mots de passes sont conservés sous formes hachés (et non chiffrés). Le principe de hachage cryptographique consiste à appliquer une succession d'opération à une donnée afin de générer une valeur unique, communément appelée empreinte. C'est sous cette forme que doit être conservée les mots de passe car le processus de hachage est théoriquement non réversible. La possession de l'empreinte et la connaissance de l'algorithme de hachage utilisé ne permettent pas de revenir au message original.
Dans le cas des mots de passe, pour vérifier que l'utilisateur est en possession du bon mot de passe. Il faut rejouer le processus utilisé pour générer l'empreinte du mot de passe sur celui que vient de donner l'utilisateur. Si l'empreinte générée corresponds à celle conservé par le système, l'utilisateur est bien en possession du mot de passe.
Je n'ai volontairement pas abordé la question du sel, des rainbow tables et de l'importance du choix des algorithmes de hachage. Pour ceux et celles qui veulent aller plus loin, les pages wikipedia relatives au chiffrement et au fonction de hachage cryptographique sont assez complètes.
J'en était resté à chiffrer vs crypter. Ça m'apprendra à répondre trop vite.
Tout à fait d'accord avec toi donc et avec milosh, désolé pour le bruit…
Il faut pas être désolé de générer des échanges intéressants ;)
Tcho !
Chiffré ou crypté c'est pas important, on appelle ça un abus de langage et dans le contexte ça ne pose pas de problème, car c'est un article pour le commun des mortels, pas une publication scientifique. Dans le langage courant ça arrive de confondre « bus » avec « car », « gruyère » avec « emmental » ou « Linux » à la place de « GNU/Linux » et on s'en sort bien pour communiquer.
À cette occasion. Lorsque j'ai publié “Linux aux petits oignons” en 2009, je me suis fait salement incendier sur LinuxFR.org parce qu'il y avait pas “GNU/Linux” dans le titre. Un de ces talibans du libre est même allé jusqu'à m'écrire un mail à rallonge pour m'expliquer la gravité de mon manquement. J'ai transféré le mail à la directrice de collection chez Eyrolles, et elle lui a répondu directement. En le remerciant infiniment pour sa perspicacité, et en l'informant qu'Eyrolles allait procéder de ce pas à la destruction des 3.000 exemplaires imprimés.
J'adore mon éditeur. :o)
J'en connais un qui dit lignux, en plus, ce même mec termine toujours son blabla par un “Tcho !”. Hérésie.
Donne son nom, je propose une lapidation en place publique !
Tchoum !
Mystère et boule de gomme.
Non cryptés c'est sur, mais encore moins non chiffrés
Au passage, l'article du monde ne tombe pas dans le piège : https://www.lemonde.fr/pixels/article/2019/03/21/facebook-a-conserve-des-centaines-de-millions-de-mots-de-passe-de-maniere-non-securisee_5439366_4408996.html?xtor=RSS-3208