Journal Passwords managers sous linux : où en est-on ?

Posté par  . Licence CC By‑SA.
Étiquettes :
-4
22
juil.
2016

Bonjour à tous.

Je n'utilise quasi plus de bureau libre depuis qq temps (saletés de jeux prévus pour win :'( ) malgré ma préférence pour KDE. (mais j'aimerais le récupérer comme principal dès que possible)

L'un des journaux précédents parlant de Keepass m'a rappelé que l'un des points qui m’embêtait régulièrement était l'intégration des passwords managers. Keepass, Kwallet, Gnome-Keyring, Firefox (& autres?) non synchronisables & autres…

Je me souviens d'une initiative FreeDesktop dans ce sens. (avec un nom genre secret service..)
Qqun peut-il me dire ce que ca a donné dans les différents bureaux/managers/clients ?

Merci d'avance.

  • # Google est ton ami

    Posté par  . Évalué à 4. Dernière modification le 22 juillet 2016 à 14:45.

    Je n'y connaissais pas grand chose dans le domaine, j'ai utilisé un moteur de recherche, et :

    L'article de lwn date de 2012, et présente une bonne vue de la chose.

    Bonne lecture donc !

    • [^] # Re: Google est ton ami

      Posté par  . Évalué à 7.

      De ce coté, j'avais aussi fini par retrouver ces mêmes adresses, où en gros ils disent chacun "on a fait notre part du boulot, non testé avec d'autres"

      Enfin, merci quand même pour la doc Arch qui répond déjà mieux à une description actuelle de la situation.

      Je n'avais surement pas été assez clair dans le journal en lui même…
      Je pensais obtenir, probablement via retours d'expériences, si maintenant il était possible d'avoir un seul stockage de passes pour les applis gnome/kde/firefox/autres partagés, comment ça se passe coté backends, si il existait (ou si c'était possible de faire) un backend keepass histoire de partager ses comptes avec d'autres OS, d'autres détails de ce genre…

      Bref, comment ces softs ont avancé et ce qui existe actuellement étant donné que je n'ai pas eu l'occasion de tester & suivre moi-même. (bref, l'avancement entre la théorie de 2012 et la pratique de 2016.)

      Note:Vu la cote de ce journal, je suppose que certains s'attendaient plus à une réponse qu'à une question dans le texte du journal, j'aurais p'tet mieux fait de l'envoyer coté forum.

  • # Les forums sont tes amis

    Posté par  . Évalué à 4. Dernière modification le 22 juillet 2016 à 16:37.

    https://linuxfr.org/forums

    (Tu le dis toi-même dans ton commentaire. Je ne l'ai vu qu'après.)

  • # pass

    Posté par  . Évalué à 7.

    J'utilise pass. Ça fonctionne en CLI mais il existe aussi plusieurs GUI par dessus pour ceux qui préfèrent. Ça chiffre avec gnupg donc c'est bien secure, ça peut optionnellement être versionné avec git donc pour la synchro c'est juste un git push/pull, et avec le script dmenu qui va bien ça peut copier temporairement le mot de passe, voire l'entrer directement si on couple avec xdotool.

    • [^] # Re: pass

      Posté par  . Évalué à 4.

      Pareil: gnupass, dmenu et utilisation de git de mon coté.

      Avoir ces mots de passe synchro sur PC perso, boulot et téléphone via un serveur git sur Internet, je trouve ça excellent.

      • [^] # Re: pass

        Posté par  (site web personnel) . Évalué à 2.

        Je viens d'y migrer depuis Revelation. C'est parfait ! L'application disponible sur Fdroid est aboutie et il existe des scripts de migration depuis tous les gestionnaires de mot de passe connus

  • # keepassx

    Posté par  (site web personnel) . Évalué à 3.

    multiplateforme
    simple d'utilisation

    • [^] # Re: keepassx

      Posté par  . Évalué à 1.

      Et on peut utiliser d'autres clients compatibles.
      je synchronise ma base keepass via seafile (multiplateforme), et j'y accède via keepassc en cli, super pratique et simple. Et keepassdroid sur le téléphone.

  • # UPM vs pass

    Posté par  (site web personnel) . Évalué à 1. Dernière modification le 23 juillet 2016 à 12:06.

    (j'avais posté sur un des posts dupliqués dans le forum, je reposte ici en complétant suite à la découverte de pass)

    Personnellement, j'utilise Universal Password Manager : c'est en Java donc ça tourne sur Linux (et aussi sur Windows et Mac) et il y a une application Android.
    Ça se synchronise via un serveur web et un script PHP.

    Ça n'est pas parfait (si j'ai du temps cet été, je regarderai le code et j'essayerai d'ajouter ce que je veux) mais ça fonctionne.

    D'un autre coté, je viens de tester pass avec Qtpass … et c'est pas mal du tout.
    En particulier, il y a une fonction qui manque cruellement (pour moi) à UPM c'est la gestion en dossiers hiérarchisés. Forcément pass reposant sur le filesystem, cette fonction est native. J'aurai préféré des noeuds unique (pas de distinction dossier / mot de passe, donc pouvoir mettre un sous mot de passe à un mot de passe) … mais je peux vivre avec ça.
    Je vais tester tout ça (en particulier, la synchro Android/Linux), et du coup, je vais peut-être abandonner UPM !

    Merci pour la découverte de pass et de sa progéniture !

  • # Keepass, Passbolt

    Posté par  . Évalué à 1.

    KeepassX ne gère pas les accès concurrents.
    Sinon Keepass(tout court), pour Linux et Windows, la GUI OSX, Kypass, est payante (et non libre si mes souvenirs sont bons).

    Il y a aussi Passbolt pour du collaboratif, il y a un add-on Firefox. Pas encore testé.

  • # Keeweb la GUI multiplateforme qui va bien

    Posté par  . Évalué à 2.

    Il y a Keeweb qui est sortie récemment pour gérer les mots de passe au format KeePass2.

    https://keeweb.info

    Je l'utilise tous les jours, il est très bien fait.

    Pour android il y a KeePassDroid qui est simple mais que fait le boulot.

    À++

  • # Authentification à deux facteurs?

    Posté par  . Évalué à 1.

    Je serai curieux de connaître le niveau d'intégration de ce genre de gestionnaires de mots de passes mais avec une option d'authentification à deux facteurs.
    Aux dernières nouvelles, il n'y avait pas grand chose de pratique.

    Des retours d’expérience?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.