La première version de la console d'administration FLIN avait un modèle de sécurité qui ferait grimacer tout auditeur de sécurité : le nom d'utilisateur était « flin » et le mot de passe était « flin ». Codé en dur. Dans le code source. Identique pour chaque application FLIN sur la planète.
C'était intentionnel pour les tests alpha. La session 319b a traversé l'océan entre « alpha fonctionnel » et « déploiement en production », remplaçant les identifiants par défaut par des mots de passe hachés en bcrypt, des jetons de session aléatoires cryptographiquement, un assistant de configuration première utilisation et une authentification à deux facteurs par e-mail.
Le système d'authentification inclut maintenant : mots de passe hachés en bcrypt stockés dans .flindb/console_admin.json, jetons de session de 64 caractères hexadécimaux, un assistant de configuration en trois étapes pour les nouvelles applications, et un 2FA par OTP e-mail utilisant Postmark SMTP intégré directement dans le runtime.
L'évolution de l'authentification reflète un schéma plus large dans le développement de FLIN : livrer quelque chose de fonctionnel, puis le durcir. Le 2FA par e-mail a été choisi plutôt que TOTP ou SMS car l'e-mail est universel, tandis que les apps TOTP ne sont pas toujours installées et les SMS sont peu fiables et chers en Afrique de l'Ouest.
Ceci est la partie 139 de la série « Comment nous avons construit FLIN », documentant comment un CEO à Abidjan et un CTO IA ont fait évoluer l'authentification admin des identifiants par défaut à la sécurité de niveau production.
Navigation de la série : - [138] Navigateur d'entités et opérations CRUD - [139] Connexion et authentification admin (vous êtes ici) - [140] Observabilité et monitoring