Les téléphones pour la plupart sont maintenant chiffres. Donc juste avec un reset, sans ma clef, le « disque » ne doit contenir qu’un blog sans infos particulières.
Aucune idée, de mon côté j'ai viré depuis bien longtemps les décodeurs télé. Et sauf erreur de ma part chez SFR tout reste dans le même réseau non ? 192.168.1.0/24 pour moi
Le service Téloche est sur un autre VLAN inaccessible pour l'utilisateur donc bon… tu pourras pas foutre du pihole sur ta téloche tant que tu conserves ta livebox.
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 …
Merci ! J'adore vraiment ton blog !
Passer sous linux et python ? sans rire ?
Mystère et boule de gomme.
Donne son nom, je propose une lapidation en place publique !
Tchoum !
J'en connais un qui dit lignux, en plus, ce même mec termine toujours son blabla par un “Tcho !”. Hérésie.
C’est abusé. Après il suffit de couper wifi et Bluetooth. En plus ça bouffe la batterie ces trucs là
quelqu'un peut-il m'expliquer ce dont il s'agit ?
Les téléphones pour la plupart sont maintenant chiffres. Donc juste avec un reset, sans ma clef, le « disque » ne doit contenir qu’un blog sans infos particulières.
Aucune idée, de mon côté j'ai viré depuis bien longtemps les décodeurs télé. Et sauf erreur de ma part chez SFR tout reste dans le même réseau non ? 192.168.1.0/24 pour moi
Le service Téloche est sur un autre VLAN inaccessible pour l'utilisateur donc bon… tu pourras pas foutre du pihole sur ta téloche tant que tu conserves ta livebox.
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