La Poste a apparemment décidé de faire l'exact contraire de la bonne pratique : supprimer la fonctionnalité permettant l'authentification en deux étapes via une application OTP (comme Google Authenticator). La raison :

La fonctionnalité de double authentification par l’application mobile […] pouvait générer des blocages (notamment lors d’un changement de téléphone).

Elle recommande désormais l'utilisation de l'authentification en deux étapes par l'envoi d'un code par SMS, comme on en voit encore partout et alors même que cette fonctionnalité est moins sécurisée, puisque non chiffré (là où l'OTP avait l'avantage d'être calculé par l'application, et donc ne nécessitait aucune communication).

Bon. À la personne à La Poste qui a pondu cette décision : sachez que l'argument du changement de téléphone peut tout aussi bien s'appliquer à l'authentification par SMS, dans la mesure où (fun fact) on peut aussi changer de numéro de mobile. Si si !

Ah et autre fun fact, la problématique soulevée, en fait, elle est déjà connue, et une solution assez élégante a été proposée : générer des clés de secours à usage unique.

Bref, plutôt que de supprimer le support de fonctionnalités de sécurité qui ont fait leurs preuves (d'autant plus qu'on parle d'un coffre-fort numérique…), et si vous faisiez de la pédagogie auprès de vos utilisateurs, histoire de leur donner un peu de bonne pratique et d'hygiène numérique ?

Mise à jour 19/05/2022 : le service Digiposte a répondu (très) succinctement via Twitter qu'un nouveau dispositif d'authentification en deux étapes sera proposé, sans donner plus de détail sur sa nature et sur sa date de disponibilité. Je reste tout de même assez étonné de la manœuvre qui consiste à affaiblir la sécurité d'une application avant même de proposer une meilleure solution…

NVIDIA semble d'être ENFIN décidé à libérer le code de ses pilotes sous licence MIT !
Il reste encore pas mal de boulot (le processus a à peine commencé), mais je ne pouvais pas m'empêcher de partager cette heureuse nouvelle en partageant cette très belle issue #1 !

Cette avancée devrait permettre à l'avenir une intégration bien plus propre et, surtout, plus poussée des cartes graphiques de NVIDIA sous GNU/Linux, sujet de discorde depuis bien longtemps.

[Les trois géants de la tech] vont faire en sorte que leurs produits prennent en charge la norme de connexion sans mot de passe de la Fido Alliance (Fast IDentity Online) et du World Wide Web Consortium. Empreinte digitale, scan du visage, ou code PIN seront les nouveaux sésames universels pour déverrouiller votre appareil et retrouver vos données.

Je trouve cette nouvelle très inquiétante. N'ayant jamais fait confiance à la biométrie pour l'authentification (trop intrusif et moins sûr), j'espérais ne jamais voir les mots de passe disparaître pour de bon.
Sans compter que ça va laisser sur le carreau de nombreux utilisateurs qui ne possèdent pas l'équipement pour cela, et vont donc devoir se rabattre sur le code PIN (bien moins sécurisé qu'un mot de passe).

— C'est qui Deuchnord ?
— C'est moi.

Un début de discussion tout à fait normal chez Les-Tilleuls.coop

Hier soir, j'indiquais brièvement et en 280 caractères que ce site avait subi une indisponibilité dans certaines situations. Pour être plus précis, cela arrivait notamment quand on tentait de venir sur tech.deuchnord.fr avec Safari et qu'on utilisait le réseau mobile d'Orange.

Autant vous dire que quand j'ai découvert ça, je ne comprenais pas tout. C'est avec l'aide d'un collègue que j'ai fini par trouver le coupable : la configuration du serveur Nginx !

Quand on installe Nginx pour la première fois sur son serveur, il crée un fichier par défaut qui ressemble à ceci :

server {
     # ...
     listen 80;
     # ...
}

Tel quel, on pourrait comprendre qu'une fois chargé, Nginx écoutera sur le port 80 (port standard dédié au protocole HTTP à la base du Web), et puis c'est marre. Spoiler : non, c'est pas le cas.

Ou pour être plus précis, Nginx ouvre bien le port 80 pour écouter ce qu'il se passe dessus, mais il le fait sur l'adresse IPv4 uniquement.
Si votre serveur possède aussi une adresse IPv6, vous devrez aussi indiquer à Nginx d'ouvrir le port sur ce protocole, autrement, il n'écoutera pas dessus !

Pour faire cela, rien de plus simple, il suffit d'éditer votre fichier et d'ajouter la directive suivante dans la section server :

listen [::]:80;

Notez bien les deux signes : entre crochets, suivis d'un nouveau signe :.
Une fois cette modification faite, rechargez la configuration (service nginx reload sous Debian), et votre site sera désormais bien disponible sur les adresses IPv6 !

Où l'on apprend soudain que l'on ne peut pas compiler un programme écrit dans un langage A avec un compilateur conçu pour un langage B. 🤪