QGestpass logiciel de gestion de mots de passe et de sites web

18
30
mai
2022
C et C++

Ce logiciel de gestion de mots de passe a été développé au départ pour une utilisation personnelle et aussi dans un but didactique pour mieux appréhender les fonctions de cryptographie.
Compte tenu du nombre de mots de passe à gérer sur les différents sites Internet et pour avoir un mot de passe par site il était nécessaire d’utiliser un gestionnaire de mots de passe tout ayant accès aux mots de passe sur différents ordinateurs et navigateurs. Toutefois la solution de stockage des mots de passe sur le cloud et les logiciels commerciaux ne nous (NdM: l'équipe de QGestpass) convenant pas, il a été décidé de développer une solution spécifique dédiée à la création et la gestion d’identifiants et de mots de passe pour les sites web.
Ce n’est pas une application destinée à protéger des données sensibles, mais uniquement à gérer la connexion à des sites Internet.

QGestpass est développé en Qt C++ pour Linux sous licence GLPV3, et peut donc être facilement compilé pour d’autres systèmes d’exploitation. Le code source est disponible sur le site sourceforge.net.

Seul le code source Qt C++ est fourni à titre d’exemple que vous pouvez utiliser après l’avoir compilé ou l’intégrer partiellement dans vos applications.
Testé en version Qt 5.15 pour Linux et MacOS.

Fonctionnalités :
Le logiciel permet la création de fiches de sites Internet avec le mot de passe et le nom d’utilisateur.
L’accès au site est réalisé directement à partir du logiciel qui ouvre le navigateur par défaut à l’adresse URL enregistrée dans la fiche. Les noms utilisateurs et mots de passe peuvent être copiés et collés à partir de la fiche dans les champs du site web.
Des champs disponibles permettent éventuellement d’enregistrer des observations et un mot de passe spécifique, qui seront enregistrés encodés dans une base de données avec un algorithme de chiffrement de type AES 256.
Les fiches peuvent être classées dans des dossiers.

Le mode d’encodage
Le logiciel génère des mots de passe qui ne sont pas enregistrés, mais calculés avec la fonction de hachage cryptographique Keccak512, en prenant en compte les éléments suivants :

  • une chaîne aléatoire enregistrée dans un fichier config,
  • un mot de passe maître saisi lors du lancement du programme par l’utilisateur et non enregistré,
  • les données saisies dans la fiche du site. La longueur de chaque mot de passe est définie lors de sa création de la fiche. Chaque mot de passe est unique, et défini une seule fois pour chaque fiche.

Les données enregistrées dans la base de données SQLite et qui sont utilisées pour calculer les mots de passe sont également encodées avec un algorithme de chiffrement de type AES 256 CBC.

Suivant les termes de la GNU General Public Licence telle que publiée par la Free Software Foundation licence GNU GPL version 3.0, ce code source est fourni dans l’espoir qu’il sera utile, mais sans aucune garantie ni prise de responsabilité de notre part lors de son utilisation, vous pouvez l’utiliser, le redistribuer ou le modifier.

fenêtre principale

Aller plus loin

  • # Alternative a LessPass

    Posté par  . Évalué à 2 (+0/-0).

    Solution intéressante qui partage la même philosophie que LessPass.
    J'aurais une question, qu'est-ce qui vous a poussé a faire une application client lourd au lieux d'un plugin pour navigateur vue que c'est votre principal cible d'utilisation ?

    Sinon LessPass offre la possibilité de mettre un "compteur" pour générer un nouveaux mot de passe sans changer les paramètres du site, ce qui me semble une bonne option dans le cas ou un mot de passe est compromis ou nous force a en changer.

  • # KeepassXC

    Posté par  (site Web personnel) . Évalué à 6 (+6/-0).

    KeepassXC me convient bien depuis des années, avec mes fichiers séquestres sur une instance nextcloud pour accès depuis plusieurs machines.

    Du coup, je ne comprends pas bien votre(vos) raison(s) précise(s) d'en créer un de plus.

    • [^] # Re: KeepassXC

      Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

      A ce propos, ça se passe bien lorsqu'une de tes machines modifie un fichier sur l'instance ? Les autres machines/keepassXC voient immédiatement les modifications ?

      • [^] # Re: KeepassXC

        Posté par  . Évalué à 4 (+3/-0). Dernière modification le 30/05/22 à 15:17.

        Je l'utilise également avec Nextcloud et cela fonctionne très très bien.
        Utilisation depuis presque 2 ans avec pas mal de bases dont certaines partagées avec d'autres utilisateur Nextcloud.
        La gestion de l'ouverture de base automatique (autopen) et le fait de pouvoir faire des entrées pour des bases "enfants" est vraiment super (l'url de l'entrée est une base keepassxc).

        Il faut juste activer l'option "Recharger automatiquement la base de données quand elle est modifiée de l’extérieur"

      • [^] # Re: KeepassXC

        Posté par  . Évalué à 2 (+1/-0).

        Même constat que zedS, ca fonctionne très bien !

  • # Cryptographie fragile

    Posté par  (site Web personnel) . Évalué à 10 (+18/-0). Dernière modification le 30/05/22 à 11:44.

    Je n’aime pas écrire ce commentaire, parce que je ne veux pas « descendre » un projet libre partagé « dans l’espoir qu’il sera utile ».

    Mais en l’état, je me dois de déconseiller l’utilisation de ce logiciel excepté dans les situations où la menace est quasiment inexistante — autrement dit, si vous ne voulez que stocker vos identifiants sans aucunement chercher à les protéger.

    La première phrase de la dépêche dit tout :

    Ce logiciel de gestion de mots de passe a été développé au départ pour une utilisation personnelle et aussi dans un but didactique pour mieux appréhender les fonctions de cryptographie.

    Il n’y a bien sûr aucun mal à créer un logiciel dans un but didactique et ce n’est sûrement pas quelque chose qui doit être découragé, bien au contraire.

    Mais du côté des utilisateurs potentiels, il faut être conscient de ce que ça implique. En l’occurrence ici, que la protection cryptographique semble reposer sur des bases fragiles.

    Un rapide coup d’œil au code montre (au moins, pas tout regardé en détail) deux gros red flags :

    • une implémentation personnelle d’AES (aka rolling your own crypto), au lieu d’utiliser une bibliothèque cryptographique éprouvée — certes ça se justifie dans un but didactique, mais pas pour un logiciel proposé à l’utilisation (c’est une violation du Foot-Shooting Prevention Agreement que tout développeur apprenant AES devrait normalement signer ;) ) ;
    • la clef principale est dérivée du master password par une simple condensation SHA2-256 :
    // définir key et iv pour AES cbc
    // key est calculé à partir du master password saisi par l'utilisateur
    QByteArray combined = getMasterPassword().toLatin1();
    QByteArray hashed   = QCryptographicHash::hash(combined, QCryptographicHash::Sha256);
    hashed = hashed.toHex().toBase64();
    hashed = hashed.replace('+', 'A').replace('/', 'B').replace('=', 'C');
    key    = hashed.simplified().left(64);

    C’était acceptable il y a vingt ans, ça… Aujourd’hui l’état de l’art commande d’utiliser des primitives cryptographiques spécialement conçues pour la dérivation de clef. Au minimum PBKDF2, ou mieux encore de nos jours les fonctions de la famille Argon2.

    • [^] # Re: Cryptographie fragile

      Posté par  . Évalué à 4 (+1/-0). Dernière modification le 30/05/22 à 14:04.

      une implémentation personnelle d’AES (aka rolling your own crypto), au lieu d’utiliser une bibliothèque cryptographique éprouvée — certes ça se justifie dans un but didactique, mais pas pour un logiciel proposé à l’utilisation (c’est une violation du Foot-Shooting Prevention Agreement que tout développeur apprenant AES devrait normalement signer ;) ) ;

      ça va peut être paraître naïf, mais justement au vu de l'utilisation locale du logiciel, et de son usage, quels sont les risques d'utiliser sa propre bibliothèque?

      Le second point me parait effectivement plus problématique, mais peut aisément se corriger.

      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: Cryptographie fragile

        Posté par  . Évalué à 5 (+2/-0).

        ça va peut être paraître naïf, mais justement au vu de l'utilisation locale du logiciel, et de son usage, quels sont les risques d'utiliser sa propre bibliothèque?

        Si tu chiffre, c'est que tu veux te protéger de quelqu'un qui a accès au fichier. Si tu utilise une implémentation bancale, tu donne un moyen de le déchiffrement facilement.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Cryptographie fragile

          Posté par  . Évalué à 3 (+0/-0).

          à priori vu que c'est justement pour apprendre j'imagine qu'il a vérifié que son chiffrement correspondait à une implémentation de référence. L'une des raisons pour ne pas utiliser des implémentations basique de crypto, c'est pour éviter les attaques par cache et/ou timing de réponses; je pense qu'aucune de ces attaques s'applique ici

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: Cryptographie fragile

      Posté par  . Évalué à -2 (+1/-3).

      C’était acceptable il y a vingt ans, ça… Aujourd’hui l’état de l’art commande d’utiliser des primitives cryptographiques spécialement conçues pour la dérivation de clef. Au minimum PBKDF2, ou mieux encore de nos jours les fonctions de la famille Argon2.

      beaucoup de dérivation de clefs sont basées sur les fonctions de hâchages.
      - voir NIST SP800-108: tout à fait adapté même pour le post quantique (en augmentant la taille)
      - plus ancien KDF X9.63

      le SHA256 est donc tout à fait adapté.
      il faut par contre dans tous les cas utiliser des schémas cryptographiques connus, ne jamais en inventer.

      • [^] # Re: Cryptographie fragile

        Posté par  . Évalué à 6 (+3/-0).

        voir NIST SP800-108: tout à fait adapté même pour le post quantique (en augmentant la taille)

        En lisant, le document c'est bien spécifié de ne pas utiliser SHA256 simplement, mais bien en plusieurs itération de manière bien spécifique (comme dans pbkf2)(dans les section 5.1, 5.2 et 5.3).

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Cryptographie fragile

          Posté par  . Évalué à -2 (+0/-2). Dernière modification le 01/06/22 à 17:30.

          Non, c'est inexact.
          un seul appel à un SHA256 en counter mode permet de générer une clé de 128 ou 256 bits. par contre, pour générer 5 clefs de 128 bits, il faut faire 2 itérations. le nombre d'itérations dépend de la taille de la sortie et aussi du mode choisi. ainsi, il n'y a aucune obligation à faire plusieurs itérations.
          les fonctions approuvées par le NIST sont considérées comme cryptographiquement fiables. On a imposé aux fonctions non fiables (typiquement DES) un chaînage pour les sécuriser (triple-DES).
          donc pour moi, je persiste il n'y a aucun souci à utiliser le SHA256 en une instance.
          Sinon, pointez moi vers une publi qui décrit une telle attaque.

          • [^] # Re: Cryptographie fragile

            Posté par  (site Web personnel) . Évalué à 9 (+7/-0).

            donc pour moi, je persiste il n'y a aucun souci à utiliser le SHA256 en une instance.

            Si, parce qu’ici l’entrée de la KDF est un mot de passe, dont l’entropie est incertaine et toujours considérée comme significativement plus faible qu‘une suite d’octets aléatoires de même longueur.

            La fiabilité de la fonction de condensation ne te sauvera pas si l‘attaquant peut brute-forcer ton mot de passe — ce qui ne pose aucune difficulté si la fonction de dérivation ne consiste qu‘en un unique appel à une fonction extrêmement rapide comme SHA2-256.

            Ici, on n’a pas besoin d’une Key Derivation Function tout court mais d’une Password-Based Key Derivation Function (PBKDF), qui prend précisément en compte la faible entropie du mot de passe d’entrée.

            Du coup ce n’est pas le NIST SP800-108 qu’il faut consulter, mais le NIST SP800-132, qui recommande au minimum 1 000 itérations.

            • [^] # Re: Cryptographie fragile

              Posté par  . Évalué à -3 (+1/-4).

              Si en plus, on ajoute l'entropie pas de soucis.
              l'entropie n'augmente pas avec le nombre d'itérations. c'est mathématique. les itérations ne servent alors qu'à cacher la misère. à donner aux données une apparence de nombre aléatoire.
              ce n'est pas une bonne méthode. il vaut mieux mettre en place un système d'accumulation d'entropie et ne faire qu'un hash en sortie plutôt que le système décrit dans ce document..
              je maintiens que la fonction SHA256 est cryptographiquement assez bonne pour générer en une passe.
              le document me laisse un peu songeur étant donné qu'il conseille l'utilisation du SHA-1 comme PRF qui ne doit plus être utilisé dans les systèmes modernes.

              • [^] # Re: Cryptographie fragile

                Posté par  (site Web personnel) . Évalué à 10 (+10/-0).

                l'entropie n'augmente pas avec le nombre d'itérations.

                Personne n’a prétendu le contraire.

                les itérations ne servent alors qu'à cacher la misère. à donner aux données une apparence de nombre aléatoire

                Pas du tout. On ne compte pas sur le nombre d‘itérations pour « donner aux données une apparence de nombre aléatoire » (ça voudrait dire quoi d’ailleurs ?).

                Le nombre d’itérations ne sert pas à augmenter l’entropie, mais à compenser la faible entropie de départ en rendant plus difficile de réaliser une attaque par force brute.

                Parce que le problème des mots de passe, c’est justement qu’ils sont vulnérables aux attaques par force brute (contrairement à une suite d’octets aléatoires provenant d’un RNG). Un mot de passe de 8 caractères alphanumériques par exemple, c’est au maximum (26 + 26 + 10)⁸ possibilités. C‘est largement à la portée des machines modernes, qui peuvent calculer plusieurs milliards de condensats SHA2-256 par seconde.

                (Et encore, là je ne tiens pas compte de plusieurs facteurs qui rendent les attaques encore plus faisables, comme le fait que les humains sont notooirement très mauvais quand il s’agit de choisir un mot de passe – ce que les craqueurs de mots de passe savent très bien exploiter, notamment en faisant des attaques par dictionnaire plutôt que d’énumérer bêtement toutes les combinaisons de caractères possibles.)

                Du coup, puisque le nombre de possibilités à tester est relativement faible (suffisamment faible pour être brute-forceable), on augmente le nombre d’itérations pour que chaque possibilité à tester prenne plus longtemps. Avec 1 000 itérations, une machine capable de calculer un milliard de condensats SHA2-256 par seconde ne peut plus tester qu’un million de possibilités par seconde.

                C’est à ça, et uniquement à ça, que sert le nombre d’itérations.

                il vaut mieux mettre en place un système d'accumulation d'entropie et ne faire qu'un hash en sortie plutôt que le système décrit dans ce document..

                C’est quoi que tu ne comprends pas dans le fait qu’ici l’entrée de la fonction est un mot de passe entré par l’utilisateur ?

                Tu ne peux pas ajouter de l’entropie à un mot de passe ! Ta fonction de dérivation doit se débrouiller avec le mot de passe choisi par l’utilisateur.

                je maintiens que la fonction SHA256 est cryptographiquement assez bonne pour générer en une passe.

                Lorsque l‘entrée est une suite d’octets (pseudo-)aléatoire (par exemple une graine en provenance directe d‘un RNG), oui. Lorsque l’entrée est un mot de passe, catégoriquement pas.

                Le problème n’est pas que SHA2-256 n’est pas « cryptographiquement assez bonne » (elle l’est), le problème est qu’elle est rapide.

                le document me laisse un peu songeur étant donné qu'il conseille l'utilisation du SHA-1 comme PRF qui ne doit plus être utilisé dans les systèmes modernes.

                L’absence de résistance aux collisions n’a absoluement aucune importance ici.

                Fun fact : la principale raison pour laquelle on veut se débarasser complètement de SHA-1 est que les cryptologues ont en assez de devoir expliquer constamment que non, toutes les applications cryptographiques des fonctions de condensation n’ont pas forcément besoin de la propriété de résistance aux collisions.

    • [^] # Re: Cryptographie fragile

      Posté par  (site Web personnel) . Évalué à 5 (+4/-0). Dernière modification le 30/05/22 à 19:54.

      Le logiciel utilise plusieurs méthode de cryptage: sha256 pour une chaîne, AES pour l'enregistrement dans la base de données SQLite des données de la fiche utilisées pour calculer le mot de passe, et surtout la fonction cryptographique de hachage KECCAK_512 pour le calcul des mots de passe à partir de la concaténation d'une chaîne initiale stockée dans un fichier config, de différentes chaînes figurant dans la fiche, et du mot de passe saisi par l'utilisateur; ces mots de passe ne sont jamais stockés mais bien calculés à partir de ces différents éléments qui sont dispatchés à différents endroits ( base de données encodée, fichier config et le mot de passe principal qui est saisi par l'utilisateur).
      Le calcul du mot de passe peut également inclure une chaîne aléatoire complémentaire, on peut définir un nombre de caractères et sa position dans la chaîne calculée par la hachage Keccak_512.

      Ce logiciel de gestion de mots de passe a été développé dans un but didactique pour mieux appréhender différentes fonctions de cryptographie combinées et en conséquence il n'est pas fourni compilé pour être utilisé tel quel.

      Par contre merci pour les conseils dont je tiendrai compte pour les améliorations futures.

  • # Ce n’est pas une application destinée à protéger des données sensibles

    Posté par  . Évalué à 5 (+3/-0).

    Ce n’est pas une application destinée à protéger des données sensibles, mais uniquement à gérer la connexion à des sites Internet.

    heu … j’admire la malice de cette phrase ;-)
    Du coup, il faut utiliser QGestPass que pour les sites qui ne gèrent aucune donnée sensible ? Mais alors à quoi bon s’emmerder avec des mdp multiples ?

    BeOS le faisait il y a 20 ans !

  • # Modèle de stockage ?

    Posté par  . Évalué à 4 (+2/-0). Dernière modification le 31/05/22 à 23:30.

    Hello,
    je ne suis pas certain de comprendre le stockage des mots de passe :

    • Le logiciel génère des mots de passe qui ne sont pas enregistrés, mais calculés […]
    • Mot de passe généré mais non stocké […]
    • Mot de passe stocké dans la base […]

    Quand on change de mot de passe maître, on peut toujours déchiffrer ses mots de passes ?

    • [^] # Re: Modèle de stockage ?

      Posté par  (site Web personnel) . Évalué à 1 (+0/-0).

      Le logiciel reprend certaines données de la fiche, des codes du fichier config, ainsi que le mot de passe maître saisi à l'ouverture pour calculer avec une fonction de hachage les mots de passe et les afficher.
      Les mots de passe ne sont donc pas stockés sur l'ordinateur.
      Chaque mot de passe reste le même tant que les données la fiche ou le mot de passe maître saisi au lancement du logiciel ne sont pas modifiés.

      Il est possible toutefois d’enregistrer un mot de passe supplémentaire par fiche qui lui ne sera pas calculé mais enregistré dans la base de données avec un algorithme de chiffrement de type AES 256.
      Sans le mot de passe maître il n'est pas possible de lire les mots de passe calculés et les données enregistrées dans la base de données.

      • [^] # Re: Modèle de stockage ?

        Posté par  . Évalué à 6 (+4/-0).

        Chaque mot de passe reste le même tant que les données la fiche ou le mot de passe maître saisi au lancement du logiciel ne sont pas modifiés.

        Ça me semble dangereux, non ? Au changement de mot de passe maître, les mots de passe calculés changent… Et donc il faut les changer sur tous les sites concernés ?

        Étant utilisateur de gestionnaire de mot de passe avec quelque chose comme ~350 entrées au boulot, et ~80 en perso, je ne me vois pas jongler avec ceci.

        Il y a peut-être un cas d'usage à dériver des mots de passe à partir d'autres infos (pour une paire de clés privée/publique, je vois bien), mais j'avoue que ça m'échappe dans ce cas :-/.

        Au final, ça me rend vraiment curieux de savoir ce qui a mené à mettre ce comportement en place.

        • [^] # Re: Modèle de stockage ?

          Posté par  (site Web personnel) . Évalué à 1 (+0/-0).

          Le but c'est d'avoir un code maitre unique pour gérer l'ensemble des mots de passe, et d'utiliser une fonction de hachage pour générer les mots de passe sans les stocker. Ensuite on peut également enregistrer des mots de passe encodés dans la base de données.

          • [^] # Re: Modèle de stockage ?

            Posté par  . Évalué à 3 (+1/-0). Dernière modification le 07/06/22 à 13:35.

            Je trouve que cette spécificité fonctionnelle n'apparaît pas assez explicitement dans la présentation initiale alors qu'elle est sans aucun doute un élément clé pour choisir ou rejeter ce logiciel.

            Il m'a fallu le commentaire de cg pour en prendre conscience.

  • # Teampass

    Posté par  (site Web personnel) . Évalué à 0 (+0/-0).

    Il y a ça qui semble pas mal :

    A++

Envoyer un commentaire

Suivre le flux des commentaires

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