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 :/
Mouais, c'est plus compliqué qu'il n'y parait… un logiciel libre devrait être rémunéré à la juste hauteur du coût pour le fabriquer, le maintenir et l'héberger…
On peut aussi retourner le truc, par exemple, si les développeurs de chez Gitlab utilisent Linux sur leur desktop, est-ce qu'ils rémunèrent la distribution qu'ils utilisent, encore plus fort, ils codent ruby, ont-t-ils versé de l'argent à la Ruby fondation (ou truc équivalent). Pour ma part, j'ai installé Gitlab par effet de mode il y a un an et demi, je le conserve parceque les équipes aiment bien mais pioufff quelle usine à gaz ! J'installe régulièrement les nouvelles mises à jour et je ne vois d'intéressant arriver. Bref, si c'était à refaire (ça peut être être le cas bientôt si ils retirent des fonctons). Je me tournerais vers gitea.
Bonjour, quelqu'un aurait la source correspondant à la phrase de l'article “la semaine dernière Gitlab a enlevé de son offre gratuite la possibilité de pouvoir approuver une merge request dans les dépôts privés” ?
Je ne trouve pas la source :(
Certes. Il faut cependant noter qu'il ne critique directement le documentaire que dans les 4 premières lignes de l'article également, et que le reste de l'article est correct. Si y'avait pas ces 4 lignes, j'hésiterais pas à le sortir dès qu'on me parle d'IA au sens bullshit / marketing du terme.
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
Déprimant :
Mouais, c'est plus compliqué qu'il n'y parait… un logiciel libre devrait être rémunéré à la juste hauteur du coût pour le fabriquer, le maintenir et l'héberger…
On peut aussi retourner le truc, par exemple, si les développeurs de chez Gitlab utilisent Linux sur leur desktop, est-ce qu'ils rémunèrent la distribution qu'ils utilisent, encore plus fort, ils codent ruby, ont-t-ils versé de l'argent à la Ruby fondation (ou truc équivalent). Pour ma part, j'ai installé Gitlab par effet de mode il y a un an et demi, je le conserve parceque les équipes aiment bien mais pioufff quelle usine à gaz ! J'installe régulièrement les nouvelles mises à jour et je ne vois d'intéressant arriver. Bref, si c'était à refaire (ça peut être être le cas bientôt si ils retirent des fonctons). Je me tournerais vers gitea.
Bonjour, quelqu'un aurait la source correspondant à la phrase de l'article “la semaine dernière Gitlab a enlevé de son offre gratuite la possibilité de pouvoir approuver une merge request dans les dépôts privés” ? Je ne trouve pas la source :(
J'ai mis à jour l'article pour les paquets installés depuis les dépôts SCL officiels.
Certes. Il faut cependant noter qu'il ne critique directement le documentaire que dans les 4 premières lignes de l'article également, et que le reste de l'article est correct. Si y'avait pas ces 4 lignes, j'hésiterais pas à le sortir dès qu'on me parle d'IA au sens bullshit / marketing du terme.