Salut sispheor, je comprend ton point de vue. Mais dans Pi-Hole, je montre qu'il est possible d'activer l'option DHCP justement pour ne plus utiliser le DHCP de la Box d'SFR par exemple. Ca ne suffit pas pour ton besoin ? Il suffit juste de désactiver le service sur la box et de l'activer sur le rasperry ou autre
À 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.
Tu peux tjs le faire. ça empêche pas.
Moi se que je trouve dommage c'est que ce genre de tuto n'apporte pas grand chose par rapport à la doc.
Moi je cherche plutot un tuto ou l'on fait marcher pihole avec une Livebox + TV (la TV reçoit des parametres du DHCP qu'il faut du coup hacker)
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.
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 …
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.
Dans le cas présent, la problématique concerne des données qui ne devraient plus se trouver sur des matériels revendus. Il faudrait que tout les vendeurs (potentiellement tout le monde en fait) aient conscience et sachent comment nettoyer complètement n'importe quel support de stockage. Manifestement, même les professionnels sont loin de faire les choses proprement.
Alors oui, si on veut revendre son matériel sans donner accès à ses données, ce n'est pas évident. Si l'on ne sait ni comment effacer proprement, ni comment vérifier que l'effacement à bien fonctionné, et bien la seule solution est la destruction physique du support. Idéalement, il est quand même préférable de se renseigner mais encore faut-il trouver le professionnel compétent. Ma solution, c'est de ne jamais revendre un disque dur. Dans le meilleurs des cas, je le réutilise. Par contre pour un téléphone mobile très franchement, ça ne doit pas être aussi trivial.
Le recyclage des objets technologiques est un problème bien plus vaste… D'ailleurs, ce type de problème devrait encourager tout le monde à utiliser leurs équipements (et notamment leurs smartphones) jusqu'à ce qu'ils cessent de fonctionner. Ça limiterait la consommation de ressources naturelles.
Le « chercheur » suggère des méthodes idiotes et dangereuses pour se débarrasser du matériel comme mettre de l'acide, passer les objets au broyeur industriel, au micro-ondes ou mettre le feu. Pour filer sa connerie, je suggère l'usage de la radioactivité ou les jeter dans un trou noir.
Mais un peu sérieusement, ce serait bien en 2019 qu'on ait un circuit officiel de récupération et valorisation des trucs que les gens jettent. Combien de PC balancés à cause d'un Windows devenu un peu trop lourd ? Combien de télés jetées à cause d'un foutu condensateur sur la plaque d'alim ? (littéralement 5 minutes à réparer). Tellement de pollution qui pourrait être évitée et d'argent qui pourrait être économisé. J'aimerais fort que les électroniques jetés soient obligatoirement récupérés, disques effacés, nettoyés et que ça reparte en pièces détachées ou appareils reconditionnés.
Pourquoi on ferait ça ? C'est ce qui manque à l'article. C'est quoi l'intérêt de faire l'application en React ? C'est quoi l'intérêt de se servir de TypeScript plutôt que ES6 ? L'article manque de préciser les avantages qu'il y aurait avec quelques exemples. C'est ça qui crée la plus-value de la suite du tuto.
Samsung Galaxy Trend Lite (la ROM stock était une Android 4.1.2, 4.4.4 est le mieux que j'ai trouvé, sur les forums XDA Developper). De mémoire c'est de l'ARMv6 qu'il y a dessus, c'est vrai que le nom de l'APK précise pas quel ARM il gère.
Il faut pas être désolé de générer des échanges intéressants ;)
Tcho !
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…
Salut sispheor, je comprend ton point de vue. Mais dans Pi-Hole, je montre qu'il est possible d'activer l'option DHCP justement pour ne plus utiliser le DHCP de la Box d'SFR par exemple. Ca ne suffit pas pour ton besoin ? Il suffit juste de désactiver le service sur la box et de l'activer sur le rasperry ou autre
Merci pour votre retour je ferais un edit de l’article pour ajouter une partie sur les raisons. Et je tiendrais compte pour la suite ! bonne journée
Pensez à vous faire infecter par un cryptolocker avant de revendre. C'est automatique et ne demande aucune compétence pro.
À 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)
Tu peux tjs le faire. ça empêche pas. Moi se que je trouve dommage c'est que ce genre de tuto n'apporte pas grand chose par rapport à la doc. Moi je cherche plutot un tuto ou l'on fait marcher pihole avec une Livebox + TV (la TV reçoit des parametres du DHCP qu'il faut du coup hacker)
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.
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 …
Dommage d'utiliser cloudflare avec Pi-Hole. Mieux vaudrait un bon unbound qui tape directement les serveurs DNS primaires
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.
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
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.
Dans le cas présent, la problématique concerne des données qui ne devraient plus se trouver sur des matériels revendus. Il faudrait que tout les vendeurs (potentiellement tout le monde en fait) aient conscience et sachent comment nettoyer complètement n'importe quel support de stockage. Manifestement, même les professionnels sont loin de faire les choses proprement.
Alors oui, si on veut revendre son matériel sans donner accès à ses données, ce n'est pas évident. Si l'on ne sait ni comment effacer proprement, ni comment vérifier que l'effacement à bien fonctionné, et bien la seule solution est la destruction physique du support. Idéalement, il est quand même préférable de se renseigner mais encore faut-il trouver le professionnel compétent. Ma solution, c'est de ne jamais revendre un disque dur. Dans le meilleurs des cas, je le réutilise. Par contre pour un téléphone mobile très franchement, ça ne doit pas être aussi trivial.
Le recyclage des objets technologiques est un problème bien plus vaste… D'ailleurs, ce type de problème devrait encourager tout le monde à utiliser leurs équipements (et notamment leurs smartphones) jusqu'à ce qu'ils cessent de fonctionner. Ça limiterait la consommation de ressources naturelles.
Non cryptés c'est sur, mais encore moins non chiffrés
Chiffrés * bordel
Le « chercheur » suggère des méthodes idiotes et dangereuses pour se débarrasser du matériel comme mettre de l'acide, passer les objets au broyeur industriel, au micro-ondes ou mettre le feu. Pour filer sa connerie, je suggère l'usage de la radioactivité ou les jeter dans un trou noir.
Mais un peu sérieusement, ce serait bien en 2019 qu'on ait un circuit officiel de récupération et valorisation des trucs que les gens jettent. Combien de PC balancés à cause d'un Windows devenu un peu trop lourd ? Combien de télés jetées à cause d'un foutu condensateur sur la plaque d'alim ? (littéralement 5 minutes à réparer). Tellement de pollution qui pourrait être évitée et d'argent qui pourrait être économisé. J'aimerais fort que les électroniques jetés soient obligatoirement récupérés, disques effacés, nettoyés et que ça reparte en pièces détachées ou appareils reconditionnés.
Pourquoi on ferait ça ? C'est ce qui manque à l'article. C'est quoi l'intérêt de faire l'application en React ? C'est quoi l'intérêt de se servir de TypeScript plutôt que ES6 ? L'article manque de préciser les avantages qu'il y aurait avec quelques exemples. C'est ça qui crée la plus-value de la suite du tuto.
Je confirme, si tu as survécu à IE 6, t'es un warrior !
Samsung Galaxy Trend Lite (la ROM stock était une Android 4.1.2, 4.4.4 est le mieux que j'ai trouvé, sur les forums XDA Developper). De mémoire c'est de l'ARMv6 qu'il y a dessus, c'est vrai que le nom de l'APK précise pas quel ARM il gère.