Journal Passprotect - Gestionnaire de mot de passe

Posté par (page perso) . Licence CC by-sa
5
2
oct.
2016

Bonjour à tous,

Récemment j'ai eu l'envie d'écrire un gestionnaire de mot de passe. Les gestionnaires existants sur le marché ne me convenant pas (et aussi ayant envie d'écrire le mien).

Le gestionnaire de mots de passe est relativement simple. On peut créer un utilisateur avec son mot de passe et tous les enregistrements (mot de passe, carte bancaire, autres) sont enregistrés cryptés.

L'application (le client, et le serveur) est écrite en javascript et propose une API REST (afin de pouvoir écrire une application Android par la suite).

Passprotect

Une clé maître est utilisée pour chiffrer les mots de passe (à l'aide de la méthode AES-256-CTR). Cette clé est elle-même chiffrée avec le mot de passe de l'utilisateur et le sel, ainsi seul l'utilisateur peut dévérouiller ses propres données.

Le chiffrage et le déchiffrage est fait côté serveur pour des raisons de performances. Cela nécessite d'avoir un minimum de confiance au serveur et d'avoir une connection HTTPS. C'est pas grave, le serveur peut être auto-hebergé.

Un peu plus d'explication par ici et vous pouvez tester l'application ici et enfin les sources.

Que pensez-vous de ce projet ? De son utilité ? De sa sécurité ?

Merci

  • # Correction

    Posté par . Évalué à 8.

    Chiffrement/déchiffrement et non chiffrage/déchiffrage ;)

  • # Performances

    Posté par (page perso) . Évalué à 10.

    Je ne comprends pas pourquoi les opérations de chiffrements et de déchiffrements sont effectués côté serveur?
    Soit disant pour des raisons de performances.

    Les smartphones de nos jours sont très puissants.
    Mon smartphone, vieux de 5 ans, est plus puissant que 3 de mes serveurs par exemple.

    Et, la nécessité d'avoir une connexion vers un serveur va poser problème dans certains pays, comme la Chine, où les connexions à des serveurs étrangers sont souvent aléatoires.

    • [^] # Re: Performances

      Posté par (page perso) . Évalué à 2.

      Par rapport à la question des performances, la librairies crypto de nodejs est écris en C si je ne me trompe.

      Si le chiffrement et déchiffrement est fait coté navigateur, la librairies devra être écrite en JavaScript. Ce qui risque d'être beaucoup moins performant. J'avoue je n'ai pas fais de test de performance. Mon téléphone étant un haut de gamme, il est très puissant, et mon PC étant lui aussi relativement puissant. Je me suis dit que hébergé chez moi cela ne posera pas de problème.

      De plus pour le coté besoin d'un serveur WEB, actuellement l'application ne gère pas de mode offline (C'est une web application / single page app). Elle pourrait gérer le mode offline, mais actuellement même si le chiffrement/déchiffrement était fait coté client, l'application aurait tout de même besoin de télécharger les éléments du serveur.

      Par contre je compte écrire une application android qui se synchroniserai avec le serveur et permettrai de sauvegarder les mots de passe offline. Sur cette application je pourrais envisager de faire le chiffrage coté application.

      Mon but est de pouvoir regarder mes mots de passes de n'importe où, que j'ai ou non mon téléphone sur moi. D'où l'idée d'un client léger (application web) et non d'un client lourd qu'il faut installer.

      Je regarderai quand même à l'occasion quels sont les performances des librairies cryptographiques coté navigateur (donc en javascript) pour me faire une idée des performances et voir si je ne peux pas faire le chiffrement coté client uniquement, ou optionellement.

      • [^] # Re: Performances

        Posté par (page perso) . Évalué à 3.

        Je viens de faire un simple benchmark (sur mon PC i7 à 3.60GHz) :

        Pour effectuer un chiffrement d'une chaîne de caractère depuis nodejs avec la lib crypto il faut 0,13896 ms

        Le même benchmark depuis le navigateur me donne 5.685ms, soit 40x plus lent.

        Bon 5ms pour une opération c'est raisonnable sur un navigateur. Il faudrait que je fasse le même test navigateur sur un navigateur mobile d'un mobile bas de gamme.

        • [^] # Re: Performances

          Posté par . Évalué à -10.

          S'agit il de Openssl ?

          • [^] # Re: Performances

            Posté par (page perso) . Évalué à 2.

            La lib crypto de nodejs coté serveur est basé sur openssl.

            Par contre, si je ne me trompe, la lib crypto utilisable coté navigateur et une réécriture en full-javascript.

        • [^] # Re: Performances

          Posté par . Évalué à 3.

          5ms c'est largement acceptable, même 1 seconde ca reste acceptable, surtout quand ca assure un surcroit de sécurité qui est de ne pas faire totalement confiance au serveur, ni au réseau de transport.

          • [^] # Re: Performances

            Posté par . Évalué à 5.

            ne pas faire totalement confiance au serveur, ni au réseau de transport.

            Faut quand même leur faire confiance pour t'envoyer le bon code JS, non?

      • [^] # Re: Performances

        Posté par . Évalué à 3.

        Regarde du coté de clipperz : tout est chiffré coté serveur, et le déchiffrement se fait coté navigateur avec une lib js. Et ça reste acceptable en temps d'execution.

  • # Crypto pas crypto

    Posté par (page perso) . Évalué à 8. Dernière modification le 03/10/16 à 10:41.

    Hello !

    J’ai regardé rapidement ta crypto, elle n’est pas correcte du tout (key/iv reusage, password as key, no HMAC…) :P
    Je vais t’ouvrir tout plein de petits tickets sur Bitbucket du coup.

    Cf https://blog.imirhil.fr/2016/03/03/chiffrement-donnees.html

    • [^] # Re: Crypto pas crypto

      Posté par (page perso) . Évalué à 1.

      Pas de soucis pour faire des rapports de bug.

      Je ne suis malheureusement pas cryptolog.

      De ce que je comprend l'un des problèmes est que je me sert de la clé maître pour chiffrer tout les mots de passes. Si chaque mots de passe à sa clé et son IV, je ne vais pas stocker en claire ces derniers. Il faut donc que je l'ai chiffre à leur tour. Et si je les chiffres avec la clé maître, je retombe sur le même problème.

      Du coup comment faire ?

      La clé maitre est quant à elle chiffrer en effet avec le mot de passe. Du coup que proposes-tu ? Chiffrer la clé maitre avec un hash du mot de passe ?

      • [^] # Re: Crypto pas crypto

        Posté par (page perso) . Évalué à 4. Dernière modification le 03/10/16 à 13:04.

        En théorie, tu n’as même pas besoin de clef maître, puisque tu pourrais la baser sur le mot de passe via une dérivation de clef.
        Tu en as besoin en pratique pour permettre le changement de mot de passe et d’éviter de le stocker au login.

        La subtilité est d’arriver à obtenir une clef et un iv (même si c’est moins grave pour le 2nd) unique pour chaque chiffrement à réaliser. Réutiliser une clef de chiffrement est une erreur grave en crypto (on est potentiellement capable de deviner des choses sur les textes en clair à partir des données chiffrées uniquement).

        À la création de l’utilisateur :

        • on génère un sel S de 64 bits via un CSPRNG
        • on génère une clef maîtresse MK de chiffrement de 256 bits via un CSPRNG
        • on calcule une clef de chiffrement K et un IV IV via K, IV = PBKDF2(password, S)
        • on chiffre MK via C, T = AES-256-GCM(MK, K, IV)
        • on stocket S, T et C en bdd, associé à l’utilisateur

        Au login utilisateur :

        • on calcule K, IV = PBKDF2(password, S)
        • on déchiffre MK via MK = AES-256-GCM(C, K, IV, T)

        Pour chiffrer une donnée :

        • on génère un salt s de 64 bits via un CSPRNG
        • on calcule une clef de chiffrement k et un iv de 256 bits à partir de de la master key via k, iv = PBKDF2(MK, s) (en résumé c’est cette étape qui manque chez toi)
        • on chiffre les données d via c, t = AES-256-GCM(d, k, iv)
        • on stocke s, t et c en bdd

        Pour déchiffrer une donnée :

        • on lit s, t et c en bdd
        • on recalcule la clef et l’iv via k, iv = PBKDF2(K, s)
        • on déchiffre les données d via d = AES-256-GCM(c, k, iv, t)
        • [^] # Re: Crypto pas crypto

          Posté par . Évalué à 1.

          Réutiliser une clé n'est pas une erreur grave, tant que le service est le même (par exemple, une clé utilisée pour chiffrer toutes les autres).
          Par contre réutiliser un IV est une erreur grave. Tous les couples (clé,IV) doivent être différents. On peut donc utiliser une IV I une fois avec la clé K1 et une fois avec la clé K2 mais jamais deux fois avec la même clé.

          Une autre chose importante : toujours utiliser un chiffrement intègre. Par exemple CBC + HMAC, ou mieux un mode combiné comme CCM ou GCM. Attention cependant dans le premier cas (utilisation d'un mode de confidentialité et un mode d'intégrité) : les clés doivent être différentes (services différents), et l'intégrité doit être calculée sur le chiffré, et non sur le clair.

          • [^] # Re: Crypto pas crypto

            Posté par (page perso) . Évalué à 1. Dernière modification le 03/10/16 à 14:28.

            Réutiliser une clé n'est pas une erreur grave, tant que le service est le même (par exemple, une clé utilisée pour chiffrer toutes les autres).
            Par contre réutiliser un IV est une erreur grave. Tous les couples (clé,IV) doivent être différents. On peut donc utiliser une IV I une fois avec la clé K1 et une fois avec la clé K2 mais jamais deux fois avec la même clé.

            C’est complètement faux. Et c’est même l’inverse.

            L’IV peut être une donnée publique (qu’on peut par exemple générer de la même manière qu’un sel) et peut être réutilisée sans problème tant qu’on changera la clef de chiffrement (c’est le couple clef+iv qui doit être unique lors du chiffrement).
            C’est juste emmerder encore plus un attaquant que de le générer via un moyen cryptographique sûr et de ne pas le communiquer (clef de 256 bits + iv privé de 256 bits peut donner jusqu’à 512 bits de sécurité totale si ils sont générés de manière indépendante).

            La clef de chiffrement, elle, doit bien être unique, d’autant plus que certains algos ne nécessitent pas d’IV (RC4, le mode ECB ou CTR de AES, …).

            Ça évite en prime de voir l’intégralité des messages qui tombent en cas de compromission de la clef unique (d’autant plus si l’IV est public).

            La règle générale est donc clef à usage unique par défaut.
            Et tu ne réutilises jamais une clef, sauf à RÉELLEMENT savoir ce que tu fais (et même dans ce cas, ne la réutilise pas, la probabilité est importante que tu ais raté quelque chose dans ton étude).

            • [^] # Re: Crypto pas crypto

              Posté par . Évalué à 3.

              La clef de chiffrement, elle, doit bien être unique, d’autant plus que certains algos ne nécessitent pas d’IV (RC4, le mode ECB ou CTR de AES, …).

              Si si, il y a bien un IV dans CTR : https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_.28CTR.29

              Ça évite en prime de voir l’intégralité des messages qui tombent en cas de compromission de la clef unique (d’autant plus si l’IV est public).

              Je vois pas ce que ça change. Dans ton schéma plus haut, si MK tombe tes clés uniques tombent aussi.

              • [^] # Re: Crypto pas crypto

                Posté par (page perso) . Évalué à 2.

                Si si, il y a bien un IV dans CTR : https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_.28CTR.29

                Ah oui, j’avais zappé le nounce effectivement /o\

                Je vois pas ce que ça change. Dans ton schéma plus haut, si MK tombe tes clés uniques tombent aussi.

                Oui, mais à la différence d’une clef réutilisée, elle n’a pas vocation à être transporté sur le réseau, de manière directe ou indirecte (via un chiffré).
                Ça la rend beaucoup plus robuste en pratique (des attaques ne sont plus possibles, comme une attaque en known-plain-text ou une par oracle par exemple).

                Il y a donc un gros fossé en terme de robustesse entre une clef maîtresse réutilisé (inaccessible sans hack de la bdd) et une clef secondaire réutilisée (accessible au moins indirectement par les chiffrés).

            • [^] # Re: Crypto pas crypto

              Posté par . Évalué à 2.

              C’est complètement faux. Et c’est même l’inverse.

              Merci. Ça fait plus de 10 ans que je travaille dans le domaine, il va donc me falloir tout revoir à la base :)

              L’IV peut être une donnée publique

              Où ai-je dis l'inverse ? Par définition il est publique puisqu'il est nécessaire pour déchiffrer. Il doit donc être transmis sur la ligne avec le message (dans le cas général, ici il n'y a pas de ligne puisque l'on protège des mots de passe).

              c’est le couple clef+iv qui doit être unique lors du chiffrement

              C'est bien ce que j'ai dit ci-dessus.

              La clef de chiffrement, elle, doit bien être unique, d’autant plus que certains algos ne nécessitent pas d’IV (RC4, le mode ECB ou CTR de AES, …).

              Effectivement, on peut parler de vieux algorithmes (RC4) ou encore de modes à bannir (ECB)…
              Plus sérieusement, la même clé peut être utilisée pour chiffrer différent messages tant que l'IV pour un message donné n'a pas déjà été utilisé par un autre message chiffré avec la même clé.

              La règle générale est donc clef à usage unique par défaut.

              Cela signifie donc que TLS, IPsec et la plupart des protocoles de sécurité ne sont pas sûr, c'est bien ça ?
              Parce que ces protocoles chiffrent bien plusieurs messages avec la même clé, qui est mise à jour régulièrement mais pas à chaque message. Par exemple, IPsec permet de chiffrer jusqu'à 264 messages avec la même clé. Et cette borne est sûre.

              • [^] # Re: Crypto pas crypto

                Posté par . Évalué à 2.

                Et cette borne est sûre.

                Oups, je préfère préciser : cette borne est sûre avec des algorithmes et des modes à l'état de l'art (AES-CBC + HMAC-SHA256 ou AES-CCM, par exemple).

              • [^] # Re: Crypto pas crypto

                Posté par (page perso) . Évalué à 2. Dernière modification le 03/10/16 à 21:49.

                Cela signifie donc que TLS, IPsec et la plupart des protocoles de sécurité ne sont pas sûr, c'est bien ça ?

                Tout à fait. C’est même pour ça qu’on a inventé PFS et qu’on demande de faire TRÈS attention à ses configurations IPSec.

                Et encore, même en version de base non PFS de TLS, la clef privée ne sert qu’à s’assurer de l’identité de la machine, une clef de session unique est négociée lors du handshake et est utilisée par la suite lors du chiffrement.
                PFS a justement fait en plus en sorte que cette clef de session ne soit pas chiffrée par la clef privée mais par une nouvelle clef de session unique négociée de manière fiable par un protocole à 0 knowledge (DHE ou ECDHE).

                Où ai-je dis l'inverse ? Par définition il est publique puisqu'il est nécessaire pour déchiffrer. Il doit donc être transmis sur la ligne avec le message (dans le cas général, ici il n'y a pas de ligne puisque l'on protège des mots de passe).

                Pas nécessaire de le transmettre. Il peut être recalculé au déchiffrement, par exemple par une dérivation PBKDF2.

                • [^] # Re: Crypto pas crypto

                  Posté par . Évalué à 1.

                  Je répond rapidement et dans le désordre.

                  IPsec c'est du pur symétrique. Pour la PFS, il faut de l'asymétrique (un échange Diffie-Hellman en l'occurence).

                  En ce qui concerne les clés IPsec, la PFS est apportée par IKE qui permet de négocier et mettre à jour les clés IPsec (quoiqu'une gestion manuelle est possible, bien qu'hardue). Il n'empêche qu'entre deux négociations IKE, plusieurs messages sont chiffrés avec la même clé dans une SA IPsec.

                  La clé privée ne chiffre rien du tout : DH et ses variantes sont des protocoles pour se mettre d'accord sur un secret commun. J'ai l'impression que tu mélanges un peu tout.

                  Ceci est mon dernier message sur le sujet, vu que ça commence à partir dans tous les sens.

                  • [^] # Re: Crypto pas crypto

                    Posté par (page perso) . Évalué à 0. Dernière modification le 04/10/16 à 00:27.

                    La clé privée ne chiffre rien du tout : DH et ses variantes sont des protocoles pour se mettre d'accord sur un secret commun. J'ai l'impression que tu mélanges un peu tout.

                    Pas quand on utilise un algo non PFS.
                    Dans le cas du non PFS (donc sans DHE ni ECDHE), le client et le serveur s’échange un nounce random, l’un des 2 en déduit une pre-master-key (généralement le client) qui est chiffré avec la clef publique de l’autre et est envoyé sur le réseau.
                    Le récepteur déchiffre cette pre-master-key avec sa clef privée, et les 2 peuvent alors calculer la master-key de session à partir de cette pre-master-key commune (l’un des côtés l’a calculé, l’autre l’a recu).

                    Sans PFS
                    TLS without PFS

                    Avec PFS
                    TLS with PFS

                    Ça a été tout le drame de Heartbleed et du key reusage : si la NSA a intercepté et stocké l’intégralité des communications entre X clients et un serveur, l’accès à la clef privée du serveur via Heartbleed leurs permettait alors de déchiffrer toutes les pre-master-key et d’en déduire les clefs de session permettant de déchiffrer tout le reste de toutes les communications.

                    Ce n’est plus du tout le cas avec PFS puisque cette pre-master-key ne circule pas sur le réseau mais est calculée des 2 côtés via un mécanisme en 0-knowledge (Diffie Hellman en version nombre premier pour DHE ou courbe elliptique pour ECDHE).
                    Et la NSA doit alors casser chaque clef de session indépendament les unes des autres, il n’y a plus de moyen de les casser toutes en une seul fois.

        • [^] # Re: Crypto pas crypto

          Posté par . Évalué à 4. Dernière modification le 03/10/16 à 13:38.

          Réutiliser une clef de chiffrement est une erreur grave en crypto

          Huh… source ? De mémoire de mes cours de crypto, c’est le couple (clé, IV) qui ne doit pas être réutilisé.

          Edit : stackoverflow confirme mes souvenirs : http://crypto.stackexchange.com/questions/33751/aes-key-reuse-and-guessing-the-key/33757

          To simplify, you can reuse a private key as often as you want as long as you can generate new initialization vector for each message.

          • [^] # Re: Crypto pas crypto

            Posté par (page perso) . Évalué à 2.

            Oui, pardon pour l’abus de langage, il faut comprendre clef par « clef + iv » effectivement. Tant que le couple est unique, on est tranquille (en tout cas dans le cas de AES).

        • [^] # Re: Crypto pas crypto

          Posté par (page perso) . Évalué à 1.

          Bonjour,

          Je suis en train de retravailler sur la partie crypto avec les informations que vous m'avez données.

          Je me pose quelques questions :

          • sur la partie authentification de l'utilisateur, si je veux faire de la crypto coté client, il est raisonnable d'envoyer les informations S, T, et C que je possède à l'utilisateur authentifié ? Est-ce que j'ai un autre choix ?

          • sur la partie session : si les opérations se font côtés serveur, je dois maintenir un certain temps les informations me permettant de déchiffrer les messages dans la session. Je peux garder soit le mot de passe de l'utilisateur, soit la clé de chiffrement K. Quel est la meilleur solution ?
            Actuellement je chiffre à l'aide d'une clé de session propre à l'utilisateur un token JWT contenant la clé maître (K).

          Merci

          • [^] # Re: Crypto pas crypto

            Posté par (page perso) . Évalué à 1. Dernière modification le 06/10/16 à 10:20.

            il est raisonnable d'envoyer les informations S, T, et C que je possède à l'utilisateur authentifié ? Est-ce que j'ai un autre choix ?

            S, T et C sont publiables sur un lien non fiable. C’est même tout le but recherché par le chiffrement :D

            Par contre si tu fais de la crypto côté client, le mieux serait de ne jamais avoir à envoyer ces données sur le réseau.
            Tu calcules et conserves S,T,C uniquement côté client, et tu mets juste en place un moyen de transférer la clef maîtresse sur un autre périphérique (par exemple avec un QR code ou une chaîne mnémotechnique).

            Je peux garder soit le mot de passe de l'utilisateur, soit la clé de chiffrement K. Quel est la meilleur solution ?

            Les 2 solutions sont équivalentes en terme de sécurité (si tu as le pass, tu as la clef K de toute façon).
            J’aurais tendance à conserver la clef en mémoire, ça évite d’avoir à redériver le pass et à déchiffrer la clef à chaque fois qu’on en a besoin.

            • [^] # Re: Crypto pas crypto

              Posté par (page perso) . Évalué à 3.

              Je viens de mettre à jour https://passprotect.shadoware.org avec un chiffrage pour chaque clé. De plus je chiffre maintenant coté client, et non plus coté serveur.

              Par contre j'utilise le serveur pour stocker les données.

              Pour moi, et mon utilisation personnelle, le fait de stocké les valeurs S, T, et C coté client est un risque en cas de cache navigateur vidé. Et le fait de pouvoir en faire une sauvegarde par QR code, ou fichier texte est intéressant mais trop compliqué pour l'utilisation que j'ai envie d'en faire.

      • [^] # Re: Crypto pas crypto

        Posté par . Évalué à 4.

        Sur la réutilisation du couple key/iv, c'est effectivement toujours une erreur, mais en mode CTR, c'est absolument catastrophique. Ça signifie par exemple que si je connais un couple cleartext/ciphertext, je peux déchiffrer absolument tous les autres messages chiffrés avec le même couple key/iv d'une taille inférieure ou égale à mon message ! (et les autres, je peux déchiffrer le début)

        Utiliser des algorithmes connus et réputés, c'est bien, mais c'est la partie facile. Concevoir un système complet qui soit sécurisé, c'est très difficile, et même les pros et spécialistes dans le domaine font des erreurs. Pour un débutant (et à te lire, je pense que c'est ton cas), c'est quasiment impossible d'y arriver du premier coup, tellement il y a de pièges à éviter et d'erreurs à ne pas commettre.

        Il n'y a aucun mal à essayer et développer son propre système (c'est une façon d'apprendre), par contre, il faut bien être conscient que ce n'est en l'état qu'un jouet, et ça ne devrait en aucun cas être utilisé pour stocker quoi que ce soit d'important. Le numéro de version 1.0.0 est trompeur, ça donne l'impression qu'on a quelque chose qui est prêt à être utilisé, or ce n'est pas le cas du tout. Tu devrais mettre un avertissement clair sur le site, histoire d'éviter que quelqu'un n'utilise ça en pensant être en sécurité.

  • # Crypto & Modules externes

    Posté par (page perso) . Évalué à 4.

    Remarque supplémentaire concernant la crypto : faire transiter les données en clair (même via un canal HTTPS) rend le logiciel inefficace d'une point de vue sécurité, et ce quelle que soit la force de la crypto côté serveur. Il est trop facile de détourner/abuser d'une connexion serveur.

    Il serait également intéressant de développer des modules/applications pour les navigateurs ainsi que pour la ligne de commande.

  • # Liste des autres outils

    Posté par (page perso) . Évalué à 5. Dernière modification le 03/10/16 à 12:20.

    Bonjour,

    tu nous dis avoir essayé d'autres outils.
    Je suis curieux de savoir lesquels, et éventuellement pourquoi tu les as rejetés.

    Cela nous fera une liste intéressante d'alternatives.

    • [^] # Re: Liste des autres outils

      Posté par (page perso) . Évalué à 3.

      • aWallet: Un outil pour android que j'utilise actuellement (sans la partie synchro). Même si l'utilise jusqu'à présent régulièrement, le logiciel ne me convient pas. Il est propriétaire. Je n'ai pas confiance dans la synchro cloud. Je ne peux pas l'héberger moi même.
      • LastPass: propriétaire, trop compliqué,
      • KeePass: Client lourd, je souhaite d'abord un client léger avec potentiellement un futur client lourd sur android, et une extension chrome.
      • Encryptr: Libre :) Belle interface :) Mais basée sur un serveur crypton distant. J'aurais bien sûr pu forker le projet et le faire pointer sur un de mes serveurs, installé manuellement.

      Ensuite j'avais envie de le développer moi-même.

      • [^] # Re: Liste des autres outils

        Posté par (page perso) . Évalué à 1.

        As-tu testé gPass ? Je viens de rajouter récemment l'interface en ligne de commande.

      • [^] # Re: Liste des autres outils

        Posté par . Évalué à 3. Dernière modification le 06/10/16 à 15:16.

        Pour compléter la liste:
        - Keepass2Android: application android
        - KeeWeb
        Ils utilisent tous les deux le format kdbx de keepass v2, fonctionnent offline ou online (avec synchro vers dropbox ou autre). Et ils sont tous les deux libres et ont des fonctionnalités de saisie automatique et de génération de mot de passe.
        Donc ils me semblent couvrir tes besoins. Mais l'envie de développer soi-même est suffisante ;)

        Sinon, le stockage local avec synchro me semble indispensable, non seulement pour un côté pratique (accès offline) mais aussi car c'est un moyen d'avoir des sauvegardes multiples plutôt que de devoir compter sur la sauvegarde sôté serveur.

        • [^] # Re: Liste des autres outils

          Posté par . Évalué à 3.

          Sinon, le stockage local avec synchro me semble indispensable, non seulement pour un côté pratique (accès offline) mais aussi car c'est un moyen d'avoir des sauvegardes multiples plutôt que de devoir compter sur la sauvegarde sôté serveur.

          Ça ne te dispense pas de la sauvegarde non plus. Si jamais ta base keepass est en vrac (ça m'est arrivé une fois), il faudra que tu puisses revenir à une version antérieure, ce qui ne sera pas possible si la dernière version a été synchronisée partout (sauf si tu synchronises avec un gestionnaire de versions).

          • [^] # Re: Liste des autres outils

            Posté par . Évalué à 1. Dernière modification le 06/10/16 à 20:21.

            Tout à fait, et dans ce cas dropbox me permettrait de revenir aux versions antérieures :) (ça ne m'est jamais arrivé)

            • [^] # Re: Liste des autres outils

              Posté par . Évalué à 1. Dernière modification le 06/10/16 à 20:33.

              Ah et puis, je n'ouvre jamais directement le fichier qui est sur dropbox, je travaille avec une copie locale qui est synchronisée par keepass/keepass2android avec la version qui est sur dropbox.
              Comme expliqué sur http://keepass.info/help/kb/trigger_examples.html#dbsync
              Donc il est impossible qu'une copie locale et la version dropbox partent en vrac toutes les deux.

        • [^] # Re: Liste des autres outils

          Posté par . Évalué à 3.

          avec synchro vers dropbox ou autre

          Il y a notamment une appli {own,next}cloud pour lire ces fichiers kdbx. Très pratique.

        • [^] # Re: Liste des autres outils

          Posté par (page perso) . Évalué à 1.

          Pour android j'utilise KeePassDroid un avis par rapport à Keepass2Android pour ceux qui connaîtraient les deux?

          • [^] # Re: Liste des autres outils

            Posté par . Évalué à 1. Dernière modification le 07/10/16 à 20:50.

            • Les deux sont libres
            • KeepassDroid supporte les kdb et les kdbx (quand je l'utilisais il me semble qu'il ne supportait que les kdb). Keepass2Android ne supporte que les kdbx.
            • Keepass2Android est plus lourd en stockage et ram (quelques dizaines de Mo contre quelques Mo).
            • Keepass2Android a une fonctionnalité de "quick unlock" (permet de ré-ouvrir plus rapidement la base)
            • Keepass2Android a un soft keyboard intégré (méthode de saisie alternative au copier/coller)
            • Keepass2Android permet de synchroniser (fusionner) les modifications locales avec les modifications distantes - je ne suis pas sûr que KeepassDroid permette de le faire.
  • # Et sodium alors ?

    Posté par . Évalué à 0.

Suivre le flux des commentaires

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