cg a écrit 1744 commentaires

Il me semble avoir vu que ce problème est déjà résolu : tu montres tes papiers une fois par an (ou tous les deux ans), et tu peux renouveler tous les x jours. Dommage, ça aurait été une bonne occasion de se débarrasser de ce business juteux.

L'idée derrière, c'est de limiter l'impact de la compromission d'un serveur, du vol de la partie privée du certificat (la clé), et l'usurpation d'identité du site qui s'ensuit. Le vol d'une telle clé pour un certificat valable 10 ans permet au voleur de se faire passer pour le site pendant 10 ans. Pour un certificat valable pendant 10 jours, le voleur n'aura que 10 jours.

Ça permet aussi aux sites ou autres services abandonnés d'être repérés plus vite.

Voilà pour la théorie.

En pratique, les attaquants vont sans doute s'adapter, et mettront en place un bidule technique qui permettra de recevoir la nouvelle version du certificat à chaque renouvellement. Ce genre d'attaque dans laquelle le voleur reste en place sans se faire repérer est plus complexe à mettre en œuvre. Ça ne changera rien pour les structures mal sécurisées, qui se feront piquer leurs certifs encore et encore sans s'en rendre compte.

Au final, ça relève la barre pour les attaquants, ce qui est bien, mais ça relève aussi un peu la barre pour les attaqués, ce qui est moins sympa.

Ça va aussi sans doute pousser à déployer DNSSEC pour authentifier les réponses DNS, car le protocole ACME repose en partie sur le DNS.

Mon cœur est arc-en-ciel sur le sujet, je ne sais pas si je trouve ça bien ou pas ;)

Pour le cas des certificats des sites internes, tu as trois grandes situations :

1. Certif autosigné sans CA racine interne. Tu peux le générer en local et le renouveler autant que tu veux. Tu as seulement le chiffrement, sans le tiers de confiance.

2. Certif avec CA racine interne connue du navigateur/du client, et une PKI interne. Tu peux l'automatiser (par exemple avec le module ACME d'EJBCA ou un procesus interne).

3. Certif wildcard avec CA racine externe (Let's encrypt). Tu peux l'automatiser avec Certbot et avoir un process qui distribue le wildcard aux services internes.

Pour ce dernier cas, avoir un protocole de distribution standard, un peu comme un "proxy ACME" serait génial, est-ce que ça existe ?

Sinon clairement BSD niveau sécurité et propreté c’est mieux.

Je suis certain de pouvoir en faire une porcherie ouverte aux quatre vents en quelques heures :p.

Ce n'est absolument pas caché qu'il y a des groupes de secours dans les datacenters, c'est même un argument de vente ! Et leur usage, comme pour les hôpitaux, est super anecdotique. Il faut les tester de temps en temps, mais ça reste minime.

L'article est totalement à charge, rempli de conditionnel et de suppositions, on se croirait sur BFMTV, c'est assez décevant au final :-/.

Je vois l'historique des mots de passe sur bitwarden.com, l'appli iOs, et l'extension Firefox.
Je suis client payant, cette fonction n'est peut-être pas dispo pour les comptes gratuits ? Ou alors l'auteur du journal a mal regardé.

La question de fond reste pertinente, ceci dit, si Bitwarden ferme soudainement demain, comment avoir planifié la sauvegarde ? L'export manuel est simple, mais le stockage d'un tel export est plus compliqué (impression papier ?).

Merci pour les éclaircissements !

En effet la rentabilité n'est pas le seul critère. Chez moi je pense pouvoir caler un groupe extérieur plus courant et moins cher sur le balconnet. Mais comme chez toi, c'est mal isolé au niveau des murs et c'est la première chose qui sera mise en œuvre, en isolant par l'extérieur d'ici deux ans (et je pense en avoir pour environ 50 000€ hors aides). On devrait en profiter été comme hiver (l'isolation du toit de l'immeuble a démontré que c'est assez utile).

Merci pour ce retour, je me posais la question de remplacer la chaudière à gaz par une pompe à chaleur air/eau.

Le prix du gaz a beaucoup augmenté en début d'année, si tu refais ton calcul avec le tarif actuel, tu verras qu'en 2025 c'est plus que 150€/mois que tu économises.

En combien de mois penses-tu revenir à zéro quand au prix d'installation de la pompe à chaleur ?

qui lis sûrement l'URL avant de coller ton mot de passe

On peut faire des versions identiques de l'affichage, au pixel près, de deux URLs différentes. Il y a cet exemple avec apple.com, dans lequel le l était en fait un caractère cyrillique identique au l minuscule. Même en zoomant tu ne peux pas le voir. Il faut regarder l'URL non encodée. Au quotidien, on ne le fait pas trop.

Et donc pour ce genre de cas, le remplissage automatique est comme tu le dis un moyen très efficace de ne pas se tromper. Et même, je dois dire que j'ai pris l'habitude de passer par les liens stockés dans Bitwarden au lieu de taper les noms des sites. Ainsi, je me met en plus à l'abri d'une faute de frappe ou d'un moteur de recherche qui renvoie le mauvais site en premier.

L'article parle aussi d'interdire la propagande. In fine, d'interdire l'échange d'idées ? Ça commence où, ça termine où ?

Je comprend l'intention de l'article, mais la première étape n'est-elle pas de définir ce qu'est la publicité (bonne chance) ?

En intermédiaire, tu as Regolith, qui est un mélange de Gnome et de i3 (pour Xorg) ou Sway (pour Wayland). C'est du tiling, mais avec le confort du DE.

Tu as aussi, dans Gnome, l'extension Tactile (petite démo en trois minutes) qui permet d'avoir le positionnement par le clavier des fenêtres, sans changer d'environnement pour autant.

Une réponse sur certains points abordés dans le journal : de mémoire, la DSP2 demande que l'authentification de l'utilisateur soit faite de telle manière qu'il soit conscient du montant et du bénéficiaire de l'opération qu'il réalise.

Sauf que ni la carte à codes unique, ni le boîtier lecteur de CB ne le permettent. Pour le boîtier qui fait des qr-codes, peut-être ?

Bref, ça ressemble tout de même fortement au syndrome de NIH.

Perso j'étais très content avec la carte papier à codes uniques au début des années 2000.

En complément d'un HIDS (Snort, OSSec, Wazuh), un truc important est de déporter les logs, par exemple avec syslog ou journald, tu peux envoyer les logs à une autre machine.

Car l'effacement des traces fait partie des phases d'attaque classiques, par exemple par la destruction des logs. Si les logs sont sur une autre machine, ils seront peut-être épargnés.

Des programmes comme fail2ban ont des règles en place pour beaucoup de services (ssh, proftpd, roundcube, postfix…), aussi. Ça peut te permettre de détecter et bloquer les attaques par force brute assez simplement. Il est relativement facile d'écrire de nouvelles règles fail2ban en s'inspirant de l'existant.

C'est simplement pragmatique comme réponse au risque, ça augmente le niveau de difficulté pour les voleurs sans pénaliser les autres. En plus, si les documents filigranés se retrouvent dans la nature, ça facilite la traçabilité.

Et ce n'est pas un projet de société :), c'est une mesure qui n'est pas exclusive à d'autres moyens, comme la sensibilisation et la législation.

Tu devrais lui dire que Whatsapp et les autres réseaux sociaux sont interdits aux moins de 13 ans et que la police va passer dans les classes, succès assuré à la récré ;).

Alors je n'ai rien prétendu d'aussi con :), j'ai parlé pour le cas général, pour lequel les données sont accessibles côté serveur. Dans le cas d'applications en E2EE (Signal, WhatsApp, mail avec GPG), on ne peut pas chercher côté serveur¹.

C'était plus en opposition entre GMail et Proton, par exemple.

D'où l'intérêt de filigraner ses documents. Même si le filigrane est possible à enlever, cela peut inciter les pirates à passer au document d'après.

En l'occurrence la grande a 13 ans. Ce doit être la dernière de sa classe à ne pas avoir de téléphone.

Ce site liste bon an mal an les fuites de données (Autosur y est): https://bonjourlafuite.eu.org/

Tu as tout à fait raison concernant ISO27001, c'est une certification qui atteste que tu suis un certain nombre de pratiques concernant la sécurité de l'information, ou au moins que tu t'en occupe. Aujourd'hui, il est très difficile de se prémunir de toutes les tentatives d'intrusion :(.

Le RGPD oblige les entreprises à annoncer les fuites aux personnes dont les données ont fuité, et rend juridiquement responsable les entreprises des fuites si les moyens de protection sont insuffisants. Gageons que ça aide à monter le niveau, petit à petit.

L'article de Zataz dit que les fichiers volés contiennent des données sensible. Du point de vue du RGPD, ce n'est pas le cas, les informations comme nom/prénom/adresse mail… n'en sont pas.

Avec dlopen(), tu peux avoir un programme qui compile mais plante de la même façon à l'exécution.

Tu peux aussi compiler un programme, le faire fonctionner, mettre à jour la distrib, et hop ça ne fonctionne plus.

Avec de la compilation entièrement statique, tu n'as certes pas ce genre de problème, tu en as d'autres :).

Suite à vos conseils et retours, on a créé une adresse Free attachée à l'abonnement Internet, on verra bien comment ça se passe !

Merci et bon dimanche !

Je doute qu'à l'heure actuelle les données soient réellement chiffrées. Les serveurs ont très vraisemblablement des chiffrements au niveau des communications, et sur les support de stockages, mais les données en elle-même j'en doute. Si vous avez de sources sur le chiffrement des données en interne, ça m'intéresse.

Oui, les données sont chiffrées côté client chez certains prestataires comme Proton (ce qu'on appelle le zéro knowledge), mais pas chez Google, Meta ou autres, sinon la fonction de recherche dans les messages ne fonctionnerait tout simplement pas.

Sur le principe du nom, je suis d'accord. En pratique, il se trouve que j'ai un nom de domaine qui répond aux critères que tu donnes, et c'est un peu pénible (et source d'erreurs) de devoir dicter son adresse mail :-/.

Mais je retiens de ne pas en faire des caisses non plus, c'est pas non plus un tatouage :).

Tu as raison, le + fait partie du standard, mais est rejeté sur pas mal de sites. Le - est plus passe-partout.