Autrefois, il suffisait de demander un mot de passe pour vérifier l'identité d'une personne sur l'internet.
Cependant, il existe de multiples façons de deviner un mot de passe ou de le voler à quelqu'un, et les utilisateurs ont rapidement commencé à prendre des habitudes peu recommandables à leur égard, comme l'utilisation du même mot de passe sur tous les sites web.
Mais il n'y a pas que les mots de passe.
Les développeurs de logiciels se sont rendu compte que, surtout pour les applications sensibles, il n'est pas possible d'utiliser une seule méthode d'authentification : chacune d'entre elles présente des faiblesses et peut éventuellement être piratée.
La solution a consisté à demander aux utilisateurs de s'authentifier à l'aide d'au moins deux méthodes d'authentification, ou facteurs - d'où le nom d'authentification multifactorielle.
Pour un logiciel de gestion de l'identité comme Canaille, il s'agissait d'une fonctionnalité essentielle, et nous l'avons mise en œuvre pour quatre méthodes différentes :
Les méthodes HOTP/TOTP exigent que l'utilisateur télécharge et configure une application mobile ou un logiciel d'authentification (comme FreeOTP), qui produira à son tour des mots de passe à usage unique.
Ces mots de passe changent périodiquement (chaque fois que vous appuyez sur le bouton de votre authentificateur pour HOTP, ou après une période fixe pour TOTP), ce qui rend plus difficile pour les attaquants de mettre la main sur un mot de passe et de l'utiliser à temps.
Ce sont probablement les facteurs d'authentification les plus sûrs actuellement disponibles pour Canaille.
Les deux autres facteurs (codes par e-mail ou SMS) sont plus basiques mais offrent une meilleure sécurité lorsqu'ils sont combinés au mot de passe.
Ils pourraient être adaptés à des cas d'utilisation où la facilité d'utilisation semble plus importante que la sécurité.
La méthode du e-mail exige que les administrateurs de l'instance Canaille aient configuré un serveur SMTP.
De même, un serveur SMPP fonctionnel est nécessaire pour la méthode SMS.
Ces facteurs peuvent être cumulés, jusqu'à 3 facteurs différents (HOTP et TOTP, en utilisant la même application d'authentification, s'excluent mutuellement) en plus du mot de passe traditionnel.
L'utilisateur devra alors remplir tous les codes requis pour se connecter à son compte.
La fonction MFA peut également être complètement désactivée - dans ce cas, l'utilisateur n'aura besoin que de son mot de passe pour se connecter.
Verrouillage anti-intrusion
Pour empêcher les attaques par force brute sur les comptes Canaille, nous avons ajouté un délai entre chaque tentative de connexion échouée.
Ce délai est doublé chaque fois qu'un utilisateur saisit un mot de passe erroné.
Nous avons également envisagé de verrouiller les comptes après un certain nombre de tentatives infructueuses, mais cela aurait permis aux attaquants de verrouiller trop facilement tous les comptes d'utilisateurs.
Journalisation des événements de sécurité
Afin de faciliter la détection d'une attaque potentielle sur une instance de Canaille, nous avons ajouté la journalisation des événements sensibles.
Ces journaux sont marqués d'une étiquette spéciale "sécurité" pour faciliter leur récupération.
Les événements de sécurité enregistrés comprennent les tentatives d'authentification, les mises à jour de mot de passe ou d'e-mail, l'émission ou la révocation de jetons OAuth, etc.
Vérification de la compromission du mot de passe
Comme les utilisateurs ont tendance à réutiliser les mêmes mots de passe (avec quelques petites variations dans le meilleur des cas), il est désormais possible de vérifier si chaque nouveau mot de passe ne se trouve pas dans une base de données de mots de passe compromis, grâce à l'API de Have I Been Pwned.
HIBP offre un point de terminaison API gratuit qui peut être consulté pour les mots de passe compromis.
Politique d'expiration des mots de passe
Afin d'accroître la sécurité des comptes d'utilisateurs, il est désormais possible de déterminer une durée de vie pour les mots de passe.
Lorsqu'un mot de passe expire, les utilisateurs sont obligés de le mettre à jour lors de leur prochaine connexion, ou pendant leur session s'ils sont déjà connectés.
Approvisionnement avec SCIM
Canaille fournit une implémentation de serveur SCIM, qui peut être utilisée par les applications clientes pour gérer les utilisateurs et les groupes directement dans Canaille (avec les droits d'autorisation).
À l'avenir, nous aimerions créer une petite application de gestion d'abonnements à des services, et SCIM est un protocole bien adapté pour qu'une telle application puisse communiquer avec Canaille.
Grâce à nos récents travaux sur SCIM, nous avions presque tout prêt pour ajouter une implémentation côté serveur de SCIM.
C'était aussi un moyen de tester nos bibliothèques SCIM en situation réelle.
Au final, cette intégration nous a fait corriger beaucoup de choses aussi bien dans notre boîte à outils SCIM que dans Canaille.
Documentation
Internationalisation
Pour rendre Canaille plus accessible, nous avons passé du temps à rendre notre documentation traduisible.
L'interface de traduction est disponible sur Weblate.
Nous avons également traduit la documentation en français pour valider le mécanisme.
Ce fut également l’occasion pour nous de revoir toute la documentation existante et de corriger les erreurs de formulation et les fautes de frappe.
In the old days, asking for a password was considered sufficient to verify the identity of a person on the internet.
However, there are multiple ways to guess a password or steal it from someone, and users quickly began to form less than ideal habits around them - like using the same password on every websites.
But it's not just passwords.
Software developers came to the realization that, especially for sensitive applications, you can't get away with using a single authentication method: every one of them has its weaknesses, and can eventually be cracked.
The solution was found in asking users to authenticate themselves using two or more authentication methods, or factors - hence the name multi-factor authentication.
For an identity management software like Canaille, this was a key feature to have, and we implemented it for four different methods:
The HOTP/TOTP methods require the user to download and set up an authenticator mobile app or software (like FreeOTP), which will in turn produce one-time passwords.
These passwords change periodically (each time you press the button in your authenticator for HOTP, or after a fixed period for TOTP), which makes it harder for attackers to get their hands on a password and use it in time.
These are probably the most secure authentication factors available now for Canaille.
The remaining two factors (codes via email or SMS) are more basic but still offer a better security when combined with the password.
They might be adapted for use cases where ease of use appears more important than security.
The email method requires the administrators of the Canaille instance to have configured a SMTP server.
Likewise, a functioning SMPP server is needed for the SMS method.
These factors can be stacked, up to 3 different factors (HOTP and TOTP, using the same authenticator app, are mutually exclusive) in addition to the traditional password.
The user will then need to fill out all the required codes in order to log in to their account.
The MFA feature can also be deactivated completely - in that case the user will only need their password to login.
Intruder lockout
To prevent brute-force attacks on Canaille accounts, we added a delay between each failed login attempt.
The delay doubles each time someone enters a wrong password.
We also considered locking accounts after a given number of failed attempts, but this would have made it too easy for attackers to lock all user accounts.
Security events logging
In order to facilitate the detection of a potential attack on a Canaille instance, we added logging for sensitive events.
Those logs are marked with a special "security" tag for easy retrieval.
They can be configured to be written in a separate file than usual log entries.
Logged security events include authentication attempts, password or email updates, emission or revokation of OAuth tokens, and more.
Password compromise investigation
Since users tend to reuse the same passwords (with some small variations in the best case), it is now possible to check if each new password is not in a compromised passwords database, thanks to the Have I Been Pwned's API.
HIBP offers a free API endpoint that can be consulted for compromised passwords.
Password expiry policy
In order to increase the security of user accounts, it is now possible to determine a lifetime for passwords.
When a password expires, users are forced to update their password on their next login, or during their session if already logged in.
Provisioning with SCIM
Canaille provides a SCIM server implementation, that can be used by client applications to manage users and group directly in Canaille (given the rights permissions).
In the future we would love to build a small service subscription management application, and SCIM is a well suited protocol for such an application to communicate with Canaille.
Thanks to our recent work on SCIM we had almost everything ready to add a server-side implementation of SCIM.
It was also a way to test our SCIM libraries in a real-world situation.
In the end, this integration made us fix a lot of things both in our SCIM toolbox and in Canaille.
Documentation
Internationalization
To make Canaille more accessible, we spent some time to make our translation translatable.
The translation interface is available on Weblate.
We also translated the documentation in French to validate the mechanism.
This was also an opportunity for us to review all the existing documentation and fix wording errors and typos.
Theming
We also have worked on the theming documentation to help users customize how their Canaille instance looks.
We wanted to reference and document all our templates, to help designers modify them.
To achieve this we had to fork an old unmaintained library into a new library jinja-autodoc for automatic template documentation generation.
We cleaned it, made a few improvements, and pushed it under the sphinx-contrib organization.
Commown est une coopérative (SCIC) qui soutient le mouvement naissant de l’électronique responsable par la location longue durée d’appareils électroniques aussi éthiques et écologiques que possible.
Plus qu’une simple coopérative de location, Commown :
Fait du lobbying d’intérêt général aux côtés d’autres associations du domaine comme Halte à l’Obsolescence Programmée, voir cet article;
Soutient les producteurs responsables : achats, soutien de marketing, relai de services, financement de R&D ;
Crée et gère des biens communs comme notre logiciel libre de gestion des locations de longue durée publié sur notre GitHub
Sensibilise ses bénéficiaires à l’emprise des GAFAM et au respect de la vie privée sur internet et dans la téléphonie mobile.
Vos missions :
Au siège de Commown à Strasbourg, vous rejoindrez l’équipe Outils informatiques et vous contribuerez :
Au développement du système de gestion et à l’amélioration des outils internes
À la consolidation des systèmes en production et à la sûreté des données
Ainsi, vous pourrez travailler sur :
Le développement et la maintenance du logiciel de gestion de toute l’activité de Commown : l’ERP Open Source Odoo, version communautaire, muni de nombreux modules développés et maintenus par l’OCA (Odoo Community Association)
Intégration de modules OCA pour nos besoins fonctionnels par encore ou mal couverts : assemblage, logistique, réparation…
Développement de nouveaux modules pour nos besoins spécifiques (ergonomie, interaction avec d’autres services, extension de nos activités…)
Migration vers les nouvelles versions Odoo (tous les 3 ans environ)
La spécification des besoins internes (ceux de nos équipes) ou externes (ceux des bénéficiaires de nos services). Ceci requiert l’apprentissage de domaines fonctionnels extrêmement variés, de la vente en ligne à la logistique en passant par la comptabilité, le support, la gestion de parcs d’appareils etc.
La maintenance corrective et évolutive des outils liés à Odoo : CI, serveurs de test et de production, outils de sauvegarde, outils de déploiement, etc.
La gestion de notre intranet et des outils informatiques mis à disposition de nos équipes (gestionnaire de mot de passe, nextcloud, etc.), en fonction de votre expérience acquise au sein de Commown et de vos appétences
Nous recherchons une personne qui :
À un intérêt marqué pour ce type de projet : écologique, éthique, coopératif, bien commun (logiciel libre)
S’intègre facilement dans une équipe et communique bien avec les autres
À une bonne capacité d’abstraction et de modélisation de connaissances variées
Aime comprendre de manière approfondie les sujets techniques
Favorise la logique et la connaissance dans la résolution de problèmes
Aime aller au bout des choses : rendre des travaux terminés, fonctionnels, bien testés et documentés, pensés pour la maintenance future
Sait apprendre en permanence, par la veille, la lecture, la réflexion méthodologique
Cherche un emploi en phase avec ses valeurs
Compétences idéales
Bonne connaissance du fonctionnement du web (protocoles, back et front)
Connaissance théorique et pratique du langage python et de sa librairie standard
Pratique fluide de git ou mercurial dans un contexte de travail collectif
Maîtrise élémentaire du shell posix
Notions et un peu d’expérience pratique de l’administration-système sous Linux
Idéalement expérience d’interaction avec des communautés du logiciel libre
Modalités
CDI
Télétravail possible plusieurs jours par semaine
Lieu de travail : Strasbourg ; distanciel complet envisageable à terme
NB 1 : Nous avons conscience que le père Noël n’existe pas, si vous n’avez pas toutes les compétences de notre liste, mais que notre projet vous motive, postulez !
NB 2 : Nous mettons tout en place pour que le monde de l’électronique ne reste pas majoritairement masculin et que les femmes se sentent à l’aise chez nous.
NB 3 : Lieux de travail : Strasbourg, full distanciel possible à terme
Si je développe un truc en Python, je peux faire les choses proprement en me faisant un environnement virtuel (j'aime bcp venv). Ensuite avec un pip freeze j'ai ma liste des packages.
Bon, mais si quelqu'un désire utiliser mon travail, il va devoir se recréer un environnement virtuel, y faire son pip install, le sourcer puis ensuite exécuter mon code.
Est-ce qu'il existerait un truc plus immédiat, à la appimage, où tu peux tout empaqueter prêt à l'emploi ?
Découvrez pourquoi et comment adopter uv, le gestionnaire de packages révolutionnaire qui transforme l’écosystème Python. Ce guide détaillé vous présente ses fonctionnalités innovantes, ses avantages, et ses usages pour optimiser vos projets Python.
Nos copains d’IndieHosters proposent à leurs utilisateurs un catalogue de services étoffé.
Leur métier est de gérer toute l’infrastructure autour de ces services, et un des enjeux importants du métier est la gestion des utilisateurs.
Lorsqu’un nouveau compte utilisateur est créé auprès d’un serveur d’identité, généralement le jeton d'accès que l’utilisateur transmet aux services contient les informations nécessaires à la création du compte utilisateur auprès de ces services.
Prenons un exemple avec le serveur d’identité Keycloak et le service d’hébergement de fichiers Nextcloud :
je crée mon compte utilisateur auprès de Keycloak (par exemple, en remplissant un formulaire d’inscription),
je tente d’accéder à Nextcloud, mais je n’ai pas de session ouverte, je suis donc redirigé vers Keycloak,
je m’identifie, Keycloak génère un jeton contenant mes informations personnelles,
ce jeton est transmis à Nextcloud,
Nextcloud lit mes informations personnelles dans le jeton.
Si mon compte utilisateur n’existait pas sur Nextcloud, alors il est créé.
Sinon, mes informations personnelles sont mises à jour dans Nextcloud.
Nextcloud m’autorise enfin l’accès aux fichiers.
C’est très pratique, mais ça ne couvre pas tous les cas de figure :
Comment faire pour partager un document avec un utilisateur qui ne s’est jamais encore connecté à un service ? Pour le moment il est nécessaire d’attendre la première connexion d’un utilisateur avant que son compte ne soit créé sur Nextcloud.
Un utilisateur édite une information le concernant sur le serveur d’identité, par exemple son nom d’affichage. Comment faire pour diffuser l'information instantanément auprès des services (par exemple un compte mail ou un chat qui identifie l'utilisateur par ce même Keycloak) ?Actuellement, les mises à jour d’informations personnelles ne sont répandues sur Nextcloud que lorsque les utilisateurs s’y connectent.
Comment supprimer ou désactiver un compte utilisateur auprès de tous les services ?
Pour effectuer toutes ces opérations, on utilise un protocole de provisionnement.
Provisionner consiste grossièrement à diffuser des modification sur un objet entre plusieurs services.
De nos jours, le protocole de provisionnement souvent utilisé dans l’industrie est SCIM.
IndieHosters a préparé une page web d’explications sur le protocole que l’on vous invite à consulter.
IndieHosters a obtenu un financement auprès de NLNet pour développer SCIM dans l’écosystème des outils qu’ils utilisent, et ont fait appel à Yaal Coop pour une partie des travaux.
Nous avions plusieurs mission :
Fournir un outil en ligne de commandes qui permette de communiquer avec un serveur SCIM, et de tester la conformité d’un serveur SCIM vis-à-vis de la norme.
Ce projet a donné lieu à plusieurs sous-projets:
scim2-models, une bibliothèque Python de sérialisation et validation de ressources SCIM.
Elle est basée sur Pydantic et fournit des objets natifs qui représentent des ressources SCIM et qui implémente une partie de la norme.
Elle a pour but de servir de brique de base à des serveurs ou des clients SCIM.
scim2-client, une bibliothèque Python de fabrication et d’analyse pythonique de requêtes SCIM.
Elle s’appuie sur scim2-models et sur httpx pour créer des requêtes SCIM, et analyser les réponses des serveurs.
scim2-server, un prototype de serveur SCIM développé par CONTACT Software utilisant scim2-models, et co-maintenu par Yaal Coop.
scim2-tester, une bibliothèque Python de test de conformité aux normes SCIM. Elle s’appuie sur scim2-client pour envoyer diverses requêtes à un serveur SCIM et observer son comportement en réponse.
scim2-cli, un outil en ligne de commandes qui s’appuie sur scim2-client et scim2-tester et qui fournit une interface pour effectuer des opérations simples sur un serveur SCIM.
Proposer l’adoption de SCIM comme protocole officiel de provisionnement dans le protocole de messagerie instantanée Matrix.
Nous avons rédigé une proposition d’évolution de la norme (MSC4098), pour lesquelles les discussions sont en cours.
À l’heure actuelle la proposition est toujours à l’étude, mais le principal argument contre est que le provisionnement est hors du périmètre fonctionnel que cherche à couvrir Matrix.
Conjointement à la proposition d’évolution de la norme, nous avons proposé une implémentation de SCIM dans synapse, le serveur Matrix le plus utilisé actuellement.
L’implémentation se base sur scim2-models.
SCIM nous apparaît comme une norme d'avenir pour le provisionnement et espérons que les bibliothèques que nous avons construites aideront son développement, grâce à de nouveaux outils Python et, à terme, sans ce limiter à ce langage.
Le provisionnement de services est une technique utile aux petit fournisseurs se services en ligne, comme ceux du collectif CHATONS.
Ils font généralement fonctionner ensemble des services hétérogènes, et des normes telles que SCIM aident ces services à communiquer entre eux.
Nous espérons qu'à terme nos travaux permettront d'avoir un impact sur la qualité de service de ces petits fournisseurs, et ainsi aider leur développement.
Our friends from IndieHosters provide a rich catalog of services to their users.
They are specialized in infrastructure management of those services, and one of the major aspects of their work is the management of user accounts.
When a new user account is created against an identity server, most of the time the access token that the users provide to the services contains information about the user. This information is generally enough to create the users account on the service provider.
Let us study an example with the Keycloak identity provider and a the Nextcloud file management service.
the users create their account against Keycloak (for instance by filling a subscription form),
they try to access Nextcloud, but they have no open session, so they get redirected to Keycloak,
they log in, Keycloak generates a token containing their personal information,
this token is forwarded to Nextcloud,
Nextcloud reads the personal information from the token.
If the user account does not exist on Nextcloud, then it is created.
Otherwise, the personal information is updated on Nextcloud.
Nextcloud finally gives access to the user.
This is convenient, but this does not cover all the use cases:
How to share a document with users that never logged in yet?
For the moment it is needed to wait for a first user login on Nextcloud before its Nextcloud account is created.
Users edit their personal information on the identity server (for instance, their display name).
How to instantly spread the modification on all the services?
Currently, personal information are only updated when users log-in anew on the services.
How to delete or deactivate user accounts on all the services, once they have been created?
To achieve all those operations, it is needed to use a provisioning protocol.
Provisioning is the action of forwarding objects (often user and groups) modifications between several services.
These days, the industry standard is SCIM.
IndieHosters started a nice presentation webpage about SCIM.
They obtained a NLNet grant to develop SCIM in the ecosystem of their tools, and hired Yaal Coop for a part of the project.
We had several missions:
Provide a command line interface that would allow to easily communicate with a SCIM server, and test the conformity of a SCIM server towards the specifications.
This project gave birth to several sub-projects:
scim2-models, a SCIM resources validation and serialization Python library.
It relies on Pydantic, provides native objects that implement the SCIM specification.
It aims to be used as a building block for SCIM server and client applications.
scim2-client, a Python library that creates and validates SCIM network requests.
It uses httpx to handle the network part.
scim2-server, a SCIM server prototype that uses scim2-models developped by CONTACT Software, and co-maintained by Yaal Coop.
scim2-tester, a SCIM compliance testing Python library.
It uses scim2-client to send various requests to a SCIM server, and check if it behaves as expected by the SCIM specifications.
scim2-cli, a command line utility that uses scim2-client and scim2-tester, and provides an interface to perform various operations on SCIM servers.
Discuss the adoption of SCIM as the official provisioning protocol for the instant messaging protocol Matrix.
We redacted an evolution request for the protocol (MSC4098), for which discussions are still opened.
To this day the proposition has not been adopted, the main argument against is that provisioning is out of scope of the Matrix protocol.
In parallel, we developed a SCIM implementation in synapse, the most famous Matrix server currently. The implementation uses scim2-models.
SCIM appears to us a future standard for provisioning and we hope that the libraries developed will help its development, thanks to new Python tools and eventually without limiting this language.
Provisioning is an useful technique for alternative online service providers, such as the ones in the CHATONS collective.
They deploy heterogeneous sets of services, and specifications such as SCIM help those services to communicate.
We hope that in the long run our work will have an impact on the quality of service of those little providers, and help them grow.
#!/usr/bin/python -Bu
# -*- coding: utf-8 -*-
import gi,sys
gi.require_version("Gtk","4.0")
from gi.repository import Gtk,Gio
import signal
signal.signal(signal.SIGINT, signal.SIG_DFL)
class call():
def back(a,b,c,evt,*_):
print("*"+str(evt)+"*")
class ecran(Gtk.ApplicationWindow):
def __init__(self,app,*args,**kwargs):
Gtk.ApplicationWindow.__init__(self,application=app)
btn=Gtk.Button(label= "surveillance de "+sys.argv[0]+
"\ncliquer pour quitter")
btn.connect("clicked",self.quitter)
self.set_child(btn)
self.present()
**#======== *mis ici, ça ne donne rien* ========**
** fich=Gio.File.new_for_path(sys.argv[0])**
** mon=fich.monitor_file(Gio.FileMonitorFlags.NONE,None)**
** mon.connect("changed",call.back)**
** #================**
def quitter(self,*_):
self.close()
app=Gtk.Application()
app.connect('activate',ecran)
**"""**
**#======== *mis ici, ça baigne* ========**
**fich=Gio.File.new_for_path(sys.argv[0])**
**mon=fich.monitor_file(Gio.FileMonitorFlags.NONE,None)**
**mon.connect("changed",call.back)**
**#================**
**"""**
app.run(sys.argv)
je tente de surveiller si un fichier est modifié par un autre programme
( pour le test, le script lui-même )
si je place le contrôle dans le corps du programme,
aucune réaction, alors qu’au lancement, ça marche
dans mon application j’ai besoin de mettre cette
surveillance “en dynamique”, au fur et à mesure
on peut faire comment ?
merci d’avance
