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 …
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.
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.
Ah. Ben justement, moi c'est l'ARM qui foire. Cependant, je me dis que Android 4.4.4 (CyanogenMod 11 déguisé en LineageOS) se fait vieux… mais j'ai pas trouvé de ROM plus récente :/
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
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
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.
Tu as quel modèle de portable ?
Ah. Ben justement, moi c'est l'ARM qui foire. Cependant, je me dis que Android 4.4.4 (CyanogenMod 11 déguisé en LineageOS) se fait vieux… mais j'ai pas trouvé de ROM plus récente :/
J'ai téléchargé l'apk arch64, qui marche bien sur lineageOS 15.1. Il existe aussi l'apk pour arm. Il y a aussi l'apk pour x86.
L'APK semble corrompu… si quelqu'un sait quelle version fonctionne, je veux bien un lien ^^
Pour télécharger l'apk : https://tools.taskcluster.net/index/project.mobile.fenix.signed-nightly.nightly/latest