-
Oui, l’article est intéressant et montre quelque chose que l’on voit régulièrement. En fait, dès qu’une entreprise porte seule un logiciel open source, on retrouve souvent la distinction entre une version communautaire (effectivement sous licence libre) et une version entreprise (sous licence propriétaire). Les briques à visées professionnelles dans les projets ne sont bien évidemment pas présentes dans les versions communautaires.
L’open source est devenu une sorte de produit d’appel. Le message, c’est qu’on peut jouer avec si on est un petit (particulier, petite association ou PME) mais que pour la version pro, t’as pas trop le choix, c’est la version “entreprise”. En soit, ça ne me choque pas trop mais ça amène parfois à des cas limites comme des versions communautaires artificiellement “bridées” par endroits, une communication assez agressive de certains projets vis à vis d’autres projets similaires concurents, de la documentation publique parfois assez limitée des fonctionnalités entreprise (en dehors des présentations commerciales), …
Pour moi, ces entreprises ne font pas du logiciel libre à proprement parler dans le sens où il n’est pas question pour elles d’adhérer à une quelconque philosophie. On ne peut donc pas réellement leur reprocher d’attaquer le logiciel libre. Pour elles, c’est juste de l’open source (en tant que modèle de développement) et ça leur permet de faire de l’argent… C’est bien parce qu’il y a une confusion entre ces termes qu’il y a un problème.
-
Jouer avec le DNS peut être relativement efficace en temps normal. Par contre là, on peut imaginer qu'un doctorant souhaitant consulter un papier saura se documenter si nécessaire pour accéder quand même à ces contenus. Je pense que personne n'est dupe.
Autre fait amusant, visiblement seuls les gros FAI semblent avoir été sollicités pour bloquer sci-hub…
-
Chiffrés * bordel
-
-
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.
-
-
-
-
-
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
-
hyakosm il y a 5 ans | lien | sur : Enorme quantité de données personnelles laissées sur les ordinateurs et téléphones usagés
[Comment removed by author]
-
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.
-
-
-
SuperFred édité il y a 5 ans | lien | sur : Générer un mot de passe solide | CNIL => ou les supers recommandations de sécurité...
Avec ces recommandations, la CNIL et l'ANSSI ne cherchent pas à atteindre un public qui a déjà de la maturité au niveau de sa gestion des mots de passe et pour qui la principale menace est de tenir face à des tentatives de cassage plus ou moins ciblées. En discutant ici, on est entre personnes qui ont un intérêt pour le sujet et une part importante de ceux qui lisent et commentent ici ont déjà adopté des pratiques plus correctes que la moyenne en la matière. Ceux qui travaillent avec des mots de passe plus complexe n'iront pas abaisser la qualité des leurs pour s'aligner.
S'agissant uniquement de la robustesse des mots de passe, je serais curieux de connaître la proportion d'utilisateurs “normaux” ayant déjà des mots de passe de 10 caractères ou plus, incluant des caractères spéciaux en plus des alphanumériques (minuscules et majuscules). Les utilisateurs “normaux” que je connais ont plutôt tendance à prendre une date de naissance ou le nom de leurs enfants pour mot de passe par exemple.
Le qualificatif de “mauvais mot de passe” pour ce qui résulte des recommandations de la CNIL me semble excessif dans la mesure où ce sera déjà souvent bien plus robuste qui ce qui est en place. En la matière, tout est souvent question de compromis.
Au passage, le problème ce n'est pas tant qu'il soit nécessaire de retenir des mots de passe que d'être tenté de mettre du sens dedans. D'ailleurs, l'exemple proposé par xkcd ne déroge pas à la règle dans la mesure où ce ne sont pas des lettres mais des mots pris dans une langue unique (mots qui peuvent être associés dans une phrase pouvant avoir un certain sens ensuite). Les coffres-forts de mots de passe permettent de travailler avec des mdp uniques générés aléatoirement et qui ne sont donc pas porteurs de sens. Ces outils ne sont pas sans contraintes non plus mais là encore, tout est question de compromis. Je rejoins donc la conclusion de ton billet…
-
Impossible de consulter: “Forbidden You don’t have permission to access / on this server.”
-
-
-
-
Je pense que c'est bon à présent.
J'ai testé il y a quelques temps un blocage par géolocalisation IP en tirant 5 pays au sort et le pays où tu te situe était dans cette liste. Comme j'avais zappé de désactiver ce filtrage après mes essais, il était toujours actif. Je viens donc de le désactiver à l'instant.
Toutes mes excuses et merci de ce retour d'information.
-
-
-
-
Je ne sais pas si c’est moi (probablement quand même) mais je trouve cette conversation SMS très orientée en faveur de l’application. Je m’attendais à quelque chose de plus équilibré mais non en fait et je trouve que certains arguments proposés en faveur de l’application sont un peu faibles :
Je suis d’accord aussi sur le fait qu’une fois sur la table, ce type d’outil sera forcement réutilisé pour tout et n’importe quoi, il suffit d’attendre…