LysSecure est une application web qui permet de stocker des mots de passe de façon sécurisée. Elle peut générer des mots de passe forts et les stocker de manière sécurisée. Elle permet aussi de copier un mot de passe en un clic. La force de ce gestionnaire réside dans sa sécurité : les mots de passe sont chiffrés à l'aide d'une clé unique pour chaque utilisateur, dérivée de trois sources différentes, dont l'une n'est pas enregistrée. Cela contribue à garantir la sécurité des mots de passe même si la base de données ou le code source sont compromis.
LysSecure est un gestionnaire de mots de passe développé sous la forme d'un bloc monolithique en PHP. Le choix de cette technologie, associée au framework Laravel, s'est fait tout naturellement à l'époque, puisqu'il s'agissait de l'un des rares environnements web que je maîtrisais et pratiquais au quotidien.
En analysant les solutions classiques du marché, j'ai identifié une faille conceptuelle majeure : pour être en mesure de restituer les identifiants en un clic, la plupart d'entre elles stockent directement la clé de déchiffrement côté serveur. Le problème est évident : en cas de compromission de la base de données, cette clé est souvent dérobée en même temps que les données chiffrées, rendant la protection cryptographique totalement caduque.
Bien que certains géants du secteur isolent le stockage de cette clé sur des serveurs distincts, le risque persiste à mon sens : la clé reste enregistrée sur une infrastructure connectée, et demeure donc potentiellement vulnérable à une attaque ciblée.
C'est précisément pour combler cette vulnérabilité que j'ai conçu LysSecure. L'objectif était de bâtir un coffre-fort numérique ultra-sécurisé, quitte à ce qu'il s'avère moins automatisé ou ergonomique que l'outil intégré de Google, tout en restant accessible depuis n'importe quelle machine détenant la clé d'accès.
Avant même d'initier la moindre ligne de code, j'ai pris la décision radicale de ne jamais exposer cette application sur un serveur connecté à Internet. Même si j'avais confiance en la rigueur de mes développements, j'ai préféré appliquer un principe de précaution strict : n'ayant pas la prétention d'avoir des connaissances exhaustives en cybersécurité, refuser la mise en ligne me garantissait de ne jamais exposer mes identifiants à des fuites massives.
Par conséquent, ce projet est resté à usage strictement personnel, hébergé localement à la maison sur un serveur domestique totalement isolé du réseau public.
Au-delà du besoin fonctionnel de contrôler mes propres accès, ce projet avait pour but principal de me servir de laboratoire d'apprentissage pour assimiler les mécanismes cryptographiques avancés, notamment le chiffrement symétrique et le hachage.
J'ai conçu, testé et déployé LysSecure de manière totalement autonome. Être le seul acteur de ce projet signifie que j'ai eu le contrôle total sur toutes les décisions de conception et de développement. Cependant, cela implique également que j'ai dû faire face à l'ensemble des défis techniques par moi-même, sans pouvoir m'appuyer sur l'aide directe d'un tiers.
Souhaitant concentrer mes efforts sur la logique cryptographique et la robustesse de l'infrastructure, j'ai volontairement relégué au second plan les aspects esthétiques et les fonctionnalités superflues.
Le cahier des charges fonctionnel et l'expérience utilisateur (UX) restaient minimalistes : un tableau de bord épuré listant les adresses email, les pseudos, les mots de passe masqués et les actions associées. J'y ai greffé une barre de recherche prédictive ainsi qu'un module d'import/export de données. Initialement conçue pour effectuer des sauvegardes de sécurité (backups) en cas de panne matérielle de mon serveur local, cette fonctionnalité de migration s'est avérée cruciale ces dernières semaines lors de mon changement de machine de développement principale, facilitant le transfert sécurisé de mes données.
C'est sur le plan de la sécurité que le projet prend toute sa dimension. Mon exigence absolue était de ne jamais sauvegarder la clé de chiffrement sur le serveur. Pour autant, je refusais qu'un mot de passe utilisateur faible (comme "1234") puisse fragiliser l'architecture. La clé finale devait être mathématiquement robuste dans tous les cas de figure.
Pour y parvenir, j'ai mis en place un protocole combinant trois sources d'informations distinctes pour générer dynamiquement la clé de chiffrement :
ssh-keygen).Pour éviter qu'une simple concaténation de ces variables ne soit vulnérable, j'ai structuré un algorithme de dérivation de clé plus complexe. L'ID utilisateur est d'abord combiné à un secret serveur, puis l'ensemble est haché pour former une première empreinte numérique. Le mot de passe maître (la saisie utilisateur) est ensuite combiné à cette empreinte, haché à nouveau, puis assemblé à la clé d'environnement avant de subir une ultime fonction de hachage cryptographique pour délivrer la clé de chiffrement finale.
Chaque opération de hachage intégrait un sel cryptographique (salt) généré de manière unique par la bibliothèque sous-jacente, interdisant ainsi toute attaque par table de correspondance (Rainbow Tables). De plus, j'ai volontairement encapsulé ce processus dans un mécanisme d'altération temporelle aléatoire (Time-padding) afin de masquer le temps d'exécution réel et de prémunir l'API contre les attaques par canal auxiliaire (Timing Attacks).
Ce flux garantissait qu'en cas d'intrusion physique ou logique sur la base de données, l'attaquant ne récupérerait que des blocs de données chiffrés, totalement indéchiffrables en l'absence simultanée de la clé d'environnement et du mot de passe maître de l'utilisateur.
LysSecure a été une expérience fondatrice très riche. Ce projet m'a permis de comprendre concrètement les principes du chiffrement appliqué, la gestion des secrets et la manipulation des fonctions cryptographiques complexes.
C'est d'ailleurs grâce à cette première immersion dans la gestion des jetons et des signatures numériques que j'ai pu assimiler avec une grande facilité les concepts de JWT (JSON Web Tokens) lorsque j'ai structuré l'architecture réseau de FlorAccess un peu plus tard.
Ce projet est aujourd'hui officiellement clos et n'évoluera plus. Initialement, j'envisageais une refonte complète de la stack technique en migrant le backend vers l'environnement Node.js et l'interface vers le framework Flutter, à l'image de mes productions récentes comme Econoris. L'objectif était de perfectionner mon algorithme de dérivation de clés et d'exporter les coffres sous forme de fichiers chiffrés locaux autonomes, synchronisables entre plusieurs appareils sans dépendre d'un serveur centralisé.
J'ai cependant choisi de suspendre ces développements par manque de temps, préférant concentrer mon énergie sur des briques plus stratégiques de mon portfolio, comme FlorAccess.
Par ailleurs, mes veilles techniques m'ont conduit à étudier des solutions open source industrielles extrêmement matures, à l'instar de KeePassXC. Cet outil repose sur des principes de sécurité rigoureux et met en œuvre exactement ce concept de fichier de clés chiffré, transférable de manière sécurisée. Bien que la synchronisation ne soit pas automatisée via un cloud centralisé, la solution bénéficie de l'audit et de la maintenance d'une vaste communauté internationale d'experts.
C'est mon collègue de travail qui m'a présenté KeePassXC, et cette découverte a confirmé ma décision : il était inutile de réinventer un outil hautement sensible alors qu'un standard open source de cette qualité existait déjà. LysSecure a donc rejoint mon cimetière de projets d'apprentissage. Ma philosophie de développement étant de concevoir des applications apportant une réelle valeur ajoutée par rapport à l'existant, maintenir ce projet n'était plus pertinent.
LysSecure m'a permis d'acquérir de solides compétences théoriques et pratiques en sécurité informatique. Rétrospectivement, si je devais concevoir un tel outil aujourd'hui, j'abandonnerais l'écosystème PHP au profit d'une architecture orientée micro-services, beaucoup plus adaptée.
Avec le recul et l'expérience que j'ai acquise depuis, je constate que j'ai eu une excellente intuition en refusant catégoriquement de mettre ce projet en ligne à l'époque. Malgré mes limites techniques d'alors, j'ai su faire preuve de lucidité et de responsabilité en mesurant les risques majeurs liés à l'exposition d'un coffre-fort de mots de passe sur Internet sans détenir une expertise totale en administration système et en durcissement de serveurs.
Aujourd'hui, bien que mes compétences en cybersécurité soient nettement plus avancées, je reste conscient qu'un gestionnaire de mots de passe grand public exige des certifications et des protocoles d'audit de sécurité d'un niveau industriel qu'un développeur seul ne peut matériellement pas assumer.
Savoir faire preuve de retenue et reconnaître les limites de ses propres outils est une qualité essentielle pour un ingénieur. C'est pourquoi le remplacement de LysSecure par une solution éprouvée comme KeePassXC est la meilleure décision que je pouvais prendre. Ce projet reste à mes yeux une totale réussite didactique, ayant servi de tremplin à ma rigueur actuelle.