Dans ce cas, la surface d'attaque augmente grandement
Si je ne m'abuse, elle est déjà la même dès qu'un mot de passe est accessible. Cette simple fenêtre ouverte empêche Passbolt de garantir quoi que ce soit sur la traçabilité des mots de passe : un mot de passe accédé est potentiellement un mot de passe fuité. Pour boucher ce trou il faudrait de l'OTP à tous les niveaux (sauf au sommet sa passphrase personnelle).
Si Passbolt garde en cache localement les mots de passe récupérés, mais bien entendu chiffrés au repos (chiffrage symétrique assuré par la même passphrase que l'accès au coffre fort), je ne vois pas la différence en terme de surface d'attaque. C'est ce que fait Bitwarden/Vaultwarden. Leur CLI va jusqu'à télécharger tous les mdp dès le 1er appel, même si on ne le demande pas. C'est très efficient et comme effet de bord ça limite beaucoup les communications avec le serveur de clés.
Je pense même que c'est une amélioration, tout ce qui vise à automatiquement stocker au repos une version chiffrée d'un secret évite qu'un dév/admin invente un contournement qui revient à se tirer un gros missile dans le pied. Tout comme globalement un Passbolt permet de largement lutter contre les post-its sous le clavier, mdp envoyés en clair par mail/chat/etc...
Dans mon cas Bitwarden (enfin https://github.com/doy/rbw car le cli officiel est une m* sans nom) me permet de trivialement remplacer un PASS=ohmygoddontlook dans des scripts par un PASS=$(rbw get secret-for-service-bla) sans 1/ complexifier et ralentir les scripts, 2/ péter en mode offline/confiné (CI sécurisées, etc), 3/ sans disruption : si l'agent n'est pas déverouillé il demande la passphrase à l'admin et le script attend tranquillement que ce soit fait avant de continuer normalement. C'est win-win-win à tous les étages.
De façon générale l'ergonomie est presque toujours un gain stratégique en sécurité effective. L'humain, le contexte, tout ça ...
[^] # Re: Mode offline
Posté par zerodeux (site web personnel) . En réponse à la dépêche Sortie de passbolt 4.9.0 : recherche par dossiers et amélioration des performances. Évalué à 5.
Si je ne m'abuse, elle est déjà la même dès qu'un mot de passe est accessible. Cette simple fenêtre ouverte empêche Passbolt de garantir quoi que ce soit sur la traçabilité des mots de passe : un mot de passe accédé est potentiellement un mot de passe fuité. Pour boucher ce trou il faudrait de l'OTP à tous les niveaux (sauf au sommet sa passphrase personnelle).
Si Passbolt garde en cache localement les mots de passe récupérés, mais bien entendu chiffrés au repos (chiffrage symétrique assuré par la même passphrase que l'accès au coffre fort), je ne vois pas la différence en terme de surface d'attaque. C'est ce que fait Bitwarden/Vaultwarden. Leur CLI va jusqu'à télécharger tous les mdp dès le 1er appel, même si on ne le demande pas. C'est très efficient et comme effet de bord ça limite beaucoup les communications avec le serveur de clés.
Je pense même que c'est une amélioration, tout ce qui vise à automatiquement stocker au repos une version chiffrée d'un secret évite qu'un dév/admin invente un contournement qui revient à se tirer un gros missile dans le pied. Tout comme globalement un Passbolt permet de largement lutter contre les post-its sous le clavier, mdp envoyés en clair par mail/chat/etc...
Dans mon cas Bitwarden (enfin https://github.com/doy/rbw car le cli officiel est une m* sans nom) me permet de trivialement remplacer un
PASS=ohmygoddontlookdans des scripts par unPASS=$(rbw get secret-for-service-bla)sans 1/ complexifier et ralentir les scripts, 2/ péter en mode offline/confiné (CI sécurisées, etc), 3/ sans disruption : si l'agent n'est pas déverouillé il demande la passphrase à l'admin et le script attend tranquillement que ce soit fait avant de continuer normalement. C'est win-win-win à tous les étages.De façon générale l'ergonomie est presque toujours un gain stratégique en sécurité effective. L'humain, le contexte, tout ça ...