Journal gPass : un concurrent libre de lastPass

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
26
1
nov.
2013

Bonjour bonjour,

Je vous présente encore un projet personnel. Sans le lier aux récents scandales de la NSA, ça faisait longtemps que ça me trottait dans la tête. Comme la plupart des personnes, je n'ai pas un ensemble important de mots de passes pour me connecter aux multiples services du web. Du coup, s'il y en a un qui tombe, c'est plusieurs comptes qui sont accessibles. Une des solutions est le Single Sign On, mais il n'est pas disponible partout. Donc pour avoir un mot de passe complexe et unique par site, j'ai développé un trousseau de mot de passe en ligne qui sera interrogé par un plugin lors de la connexion.

Cette solution se rapproche de lastPass, mais je voulais qu'elle soit ouverte (quel est le protocole ?) et auto hébergeable. Ce n'est pas un clone (et n'a pas vocation à l'être), car elle ne dispose pas de toutes les fonctionnalités de lastPass. Mais, contrairement à lui, on peut avoir plusieurs clés maîtres. Pour l'instant je ne m'en sert que sur Firefox (seul addon disponible). Le serveur (PHP) est extrêmement simple, puisqu'il ne sert qu'à accéder à la base de données. Tout est fait en javascrit côté client. La base de données ne contient que les champs "login" et "password", tout deux chiffrés. C'est le niveau de sécurité maximal, puisqu'il n'y a aucune information concernant les utilisateurs : si de dernier perd sa clé maître, personne ne pourra l'aider. À l'inverse, un hacker qui ne possède pas un supercalculateur ne pourra rien faire de la base de données, sauf si la clé maître est trop faible. gPass (global Password) fonctionne sur la plupart des sites que j'ai pû rencontrer.

Un site de démo est disponible ici (je sais, les couleurs sont chatoyantes). La présentation détaillée et le code ici.

  • # Excellente initiative !

    Posté par  . Évalué à -7. Dernière modification le 01 novembre 2013 à 11:45.

    Un truc comme LastPass est indispensable parce que l'alternative c'est de faire tout sur Facebook (un seul mot de passe là aussi) ou d'avoir un truc aussi prise de tête qu'insécurisé (utiliser quelques mots de passe sur un grand nombre de sites, en oubliant qu'en matière de sécurité, c'est la maillon faible qui décide de la solidité de la chaîne)

    C'est ce que j'avais commencé à expliquer ci-dessos. Par contre si ça vous intérese, dépliez le commentaire car certains ont pris l'habitude d'utiliser le bouton "Inutile" au lieu de comprendre, réfléchir et argumenter

    http://linuxfr.org/users/gui13/journaux/la-proche-fin-des-mots-de-passe#comment-1491805

    Le truc c'est que faire quelque chose aussi important et sensible que LastPass n'est pas à la portée d'un développeur isolé faisant ça sur son temps libre ; il me parait indispensable d'avoir une ou plusieurs personnes payées pour travailler dessus. L'union faisant la force, je te conseillerais de te rapprocher de fondations (Mozilla?) prêtes à investir sur ce sujet tellement important.

    • [^] # Re: Excellente initiative !

      Posté par  . Évalué à 8.

      Le truc c'est que faire quelque chose aussi important et sensible que LastPass n'est pas à la portée d'un développeur isolé faisant ça sur son temps libre

      Le monsieur qui a écrit le journal vient de te prouver que si.

      J’ai d’ailleurs moi-même fait un projet similaire, que j’utilise tous les jours, et la seule chose qui m’empêche de le publier c’est la flemme d’écrire une doc. Et je peux te dire que c’est vraiment pas compliqué.

      • [^] # Re: Excellente initiative !

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

        Ce n'est effectivement pas "très" compliqué, mais je comprends ce que veux dire Jean-Michel. Il s'agit 1) du support à long terme (multi versions, multi navigateurs) et de 2) de la disponibilité du/des serveurs.

        L'avantage ici est que le secret est distribué.

        • [^] # Re: Excellente initiative !

          Posté par  . Évalué à 2. Dernière modification le 01 novembre 2013 à 17:07.

          Pour le 1, il suffit de faire une solution en bookmarklet plutôt qu’en extension et ça passe sur tous les navigateurs.

          Pour le 2, comme tu dis c’est décentralisé, et ta solution côté serveur c’est un bête script PHP qui peut très bien être mis sur n’importe quel serveur mutualisé à la con, on a vu pire niveau maintenance.

          • [^] # Re: Excellente initiative !

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

            1) Un bookmarklet c'est plutôt limité vu le code Javascript à exécuter, ça pourrait éventuellement être une solution en téléchargeant du code externe

            2) Ce n'est pas "compliqué", il faut juste y mettre les moyens. Les gars de lastPass font ça à plein temps, si mon serveur tombe je suis bien embêté…

            Autre avantage de ma solution : on peut accéder au trousseau via la page web, donc sans plugin.

            • [^] # Re: Excellente initiative !

              Posté par  . Évalué à 2. Dernière modification le 01 novembre 2013 à 17:26.

              Un bookmarklet c'est plutôt limité vu le code Javascript à exécuter, ça pourrait éventuellement être une solution en téléchargeant du code externe

              Oui, c’est la méthode que j’utilise, j’ai juste un bookmarklet qui fait ça :

                  javascript:(function(){document.body.appendChild(document.createElement("script")).src="http://example.com/keyring.js";})()

              Le vrai code étant dans keyring.js.

              Ce n'est pas "compliqué", il faut juste y mettre les moyens.

              Mais aucune différence entre lastpass et un script php sur un mutualisé : tu paies pour que des gens s’occupent de gérer à plein temps la disponibilité des serveurs.

              • [^] # Re: Excellente initiative !

                Posté par  . Évalué à 1.

                Loin de moi l'idée d'interférer dans votre débat mais qu'en est-il de la sécurité ?

                Parce que dans le genre permissif Javascrit et PHP on fait pas mieux.
                Je ne remets pas en cause les compétences de l'auteur du journal mais ca ne me rassure pas.

                Je préfère que plusieurs comptes tombent que tous mes comptes à cause d'un faille XSS.

                Merci de vos lumières !

                • [^] # Re: Excellente initiative !

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

                  Le PHP ne fait qu'un ADD/DELETE/GET de valeurs chiffrées (AES-256). On pourrait éventuellement s'interfacer directement avec le SGBD (les bases NoSQL pourraient être une solution à l'avenir, mais c'est moins facile à déployer sur le parc existant).

                  Comme tout est chiffré côté serveur, on pourrait à priori rendre cette base de données publique.

                  Les requêtes sont faites par Javascript (comme tout plugin). La clé maître est dérivée via PKDBF2, elle n'est pas stockée.

                  Il y a un joli schéma ici avec tous les détails techniques d'implémentation (protocole, chiffrement…).

                  Comme le signale Gof, il est possible d'intercepter la clé maître lors de la saisie. Si c'est un point bloquant, il y a toujours l'interface web pour récupérer les mots de passes en clair.

                • [^] # Re: Excellente initiative !

                  Posté par  . Évalué à 3. Dernière modification le 04 novembre 2013 à 19:06.

                  Il faut partir d’un principe simple : tout code JS executé sur un domaine peut être « vérolé » par le webmaster du dit site. Dans le cadre de gPass et si j’ai bien suivi, c’est simple, il faut faire confiance au site web.

                  Maintenant les browsers intègrent en standard des politiques qui ne permettent les communications inter-domaines très codifiées, et il est possible d’utiliser ces mécanismes pour sécuriser le processus. Une solution possible est par exemple d’insérer une iframe via javascript et de communiquer via postMessage. Grosso-modo, si je veux m’identifier sur http://consumer.example, je clique sur un bookmarklet qui va charger un script qui lui-même va :
                  - ajouter une iframe pointant vers https://provider.example/getCredentials?url=http://consumer.example (qui est un serveur hébergé chez moi). getCredentials() me demandera mon mot de passe maître, téléchargera le keyring chiffré et s’occupera du déchiffrement.
                  - ajouter un handler pour l’event "message" sur la page http://consumer.example, qui recevra les données (utilisateur/mot de passe) de la frame et s’occupera de remplir le formulaire d’authentification du site et de le soumettre.

                  Avec cette séparation la clé secrète et le mot de passe maître restent sur le domaine de confiance https://provider.example et ne filtrent jamais sur http://consumer.example.

                  À partir de là l’essentiel de la sécurité repose sur le navigateur, c’est à dire :
                  - que le navigateur ne permette pas à un script sur http://consumer.example d’accéder ou interagir de quelque manière que ce soit avec le DOM (ou les scripts) de https://provider.example
                  - que le script https://provider.example/getCredentials?url=http://consumer.example puisse s’assurer que les données qu’il envoie arrivent bien sur une page contrôlée par http://consumer.example, afin qu’un site mal-intentionné ne puisse pas tout bêtement intercepter l’ajout de la frame et la remplacer par https://provider.example/getCredentials?url=http://paypal.example

                  La seule faille de ce schéma à ma connaissance est dans le fait qu’un site malintentionné peut parfaitement intercepter la création de la frame, remplacer par sa propre page et faire un classique phishing.

                  • [^] # Re: Excellente initiative !

                    Posté par  . Évalué à 2.

                    Merci messieurs pour ces précisions.
                    Je ne suis pas sûr de maîtriser tous les paramètres mais votre réponse me rassure.
                    A priori ce n'est pas moins fiable que les autres solutions existantes.

                    • [^] # Re: Excellente initiative !

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

                      Je pense qu'aucune solution n'est parfaite. Il s'agit juste de placer le bon niveau de sécurité par rapport à la facilité d'utilisation. Sécurité est synonyme de contrainte, et quand il y a trop de contraintes il n'y a plus de sécurité (car l'utilisateur fera tout pour se simplifier la vie).

                      Autre point que j'ai oublié de préciser : on peut utiliser plusieurs clés maîtres pour différents groupes de mots de passes contrairement à lastPass (ou autre) où il n'y a qu'un seul maillon possible.

      • [^] # Re: Excellente initiative !

        Posté par  . Évalué à -10.

        J’ai d’ailleurs moi-même fait un projet similaire, que j’utilise tous les jours, et la seule chose qui m’empêche de le publier c’est la flemme d’écrire une doc. Et je peux te dire que c’est vraiment pas compliqué.

        Ah ah ah, t'as fait un équivalent de LastPass chez toi et ils ne te manquent plus que de rédiger la doc pour avoir résolu un problème aussi compliqué ?

        Et bien, on a affaire soit à un ignorant soit à un génie.
        J'avoue opter naturellement pour la première option, mais n'excluons pas la seconde par principe. Pourquoi ne prendrais tu pas un peu de temps pour rédiger les grandes lignes de cette doc ?

        • [^] # Re: Excellente initiative !

          Posté par  . Évalué à 2.

          En quoi ce problème est compliqué ? Un keyring chiffré ça se code en quelques centaines de lignes grand max (en utilisant une bonne lib genre forge) (et encore, le mien est assez complexe parce que je voulais un keyring hiérarchique avec chiffrage asymétrique, mais un keyring classique sans hiérarchie et avec chiffrement symétrique c’est moins d’une centaine de lignes à vue de pif), le reste c’est du boilerplate en javascript/html que n’importe quel dev web pas trop manchot est capable de faire.

          • [^] # Re: Excellente initiative !

            Posté par  . Évalué à -10.

            Ce que je trouve génial, c'est que tu sais que tu as répondu aux problèmes qu'ont les gens avant même d'avoir montré et testé ta solution autour de toi. Bravo, mais moi ce n'est pas comme ça que je fonctionne.

  • # Lien vers la démo

    Posté par  . Évalué à 6.

    La démo ne se situe pas en http://demo-gpass.soutade.fr/ mais en http://gpass-demo.soutade.fr/.

  • # Sécurité

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

    Pas mal.
    Mais un site mal intentionné pourrait avoir du javascript qui est notifié à chaque changement du champ password. Et qui envoi via ajax le contenu à un server. Et pourrait donc récupérer la clé maître.

    • [^] # Re: Sécurité

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

      Exact. L'optique initiale était surtout de ne pas faire confiance aux sites tiers au cas où ils se font hacker.

      Comme je l'ai dit plus haut, on peut toujours passer par l'interface web pour récupérer manuellement le mot de passe.

  • # Chez moi, Ça ne marche pas

    Posté par  . Évalué à 1. Dernière modification le 01 novembre 2013 à 18:34.

    J’ai bien réussi à installer le serveur et à mettre une entrée dedans.
    Par contre, l’extension firefox me dit toujours « Protocol version not supported, please upgrade your addon ». Il y a une autre version de disponible ?

    • [^] # Re: Chez moi, Ça ne marche pas

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

      Je viens de tester avec le xpi dispo dans downloads et le serveur du git, mais je n'ai pas cette erreur. Est-ce que tu as la même configuration ? Tu peux toujours essayer avec le serveur de démo.

      • [^] # Re: Chez moi, Ça ne marche pas

        Posté par  . Évalué à 1.

        En effet, ça marche sur le serveur de test…

        Pour la configuration :
        j’ai repris les fichiers serveur du dépo git. Mon serveur Web est propulsé par NGINX et je suis en HTTPS.

        • [^] # Re: Et c’est résolu !

          Posté par  . Évalué à 1.

          Tu avais raison de poser la question.
          Le soucis venait de la règle de réécriture de l’URL.

          Si ça intéresse du monde, voilà la conf :

          location / {
    if (!-e $request_filename) {
        rewrite ^/(.*)$ /users/$1/index.php;
    }
    # First attempt to serve request as file, then
    # as directory, then fall back to displaying a 404.
    try_files $uri $uri/ =404;
    # Uncomment to enable naxsi on this location
    # include /etc/nginx/naxsi.rules
}

          • [^] # Re: Et c’est résolu !

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

            J'y ai pensé cette nuit. Si le plugin (client) ne reçoit pas "1" comme premier caractère (numéro de version), il affiche une erreur, mais il ne sait pas si c'est une réponse d'un serveur gPass ou autre. Il faudra que je le corrige pour la version suivante.

          • [^] # Au fait, Naxsi, c'est efficace ?

            Posté par  . Évalué à 0.

            Je viens de voir que tu utilises Naxsi, tu en es content ?

            Je suis tombé sur la conf de 2 dév de Naxsi lors de PSES2012, et j'ai trouvé ça intéressant, je suis tenté par l'installer et le config.

            Vraiment efficace, pas trop de problème sur un serveur en prod ?

            • [^] # Re: Au fait, Naxsi, c'est efficace ?

              Posté par  . Évalué à 1.

              C’est commenté :-)
              La commande est là car elle est présente dans le fichier par défaut de debian et que je l’utilise toujours pour dupliquer mes vhost.

              Par contre je vais aller me renseigner sur ce qu’est naxis…

  • # outils de génération de mot de passe ?

    Posté par  . Évalué à 3.

    Vous n'aimez pas les outils qui permettent de ne se rappeler que d'un seul mot de passe et de le décliner automatiquement en des version différentes pour chaque site ?

    -> un seul mot de passe a se rappeler
    -> pas besoin d'un serveur centralisé pour stocker quoi que ce soit
    -> mot de passe généré suffisamment compliqué et différents pour chaque site

    genre celui là ( https://addons.mozilla.org/fr/firefox/addon/password-hasher/ ) mais y'en a plein de ce genre.
    j'y vois pas mal d'avantages et peu d'inconvénients …

    • [^] # Re: outils de génération de mot de passe ?

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

      le plugin en question joue avec le gestionnaire de mots de passes intégré, donc synchronisation automatique via FirefoxSync, mais aussi tous les problèmes liés à ce gestionnaire.

      Pour info, l'algo de dérivation utilisé (maison) est une combinaison d'un modulo avec un nombre pseudo aléatoire (hmac(sha1, domain)), ce qui n''est pas très fort d'un point de vue cryptographique.

    • [^] # Re: outils de génération de mot de passe ?

      Posté par  . Évalué à 3.

      Trois gros inconvénients qui sont rédhibitoires pour moi :

      1. Je ne peux pas changer ma clé maitre en cas de suspicion de compromission
      2. S’intègre mal avec mes mots de passe déjà en place (je dois changer tous mes mots de passe un par un…)
      3. S’adapte mal aux sites à la con qui demandent une taille maximale de mot de passe (facepalm, je sais) ou qui excluent les caractères spéciaux (re-facepalm, je sais) ou autre exigence à la con (votre mot de passe doit comporter 2 majuscules, 5 minuscules et/ou 3,2 chiffres)

    • [^] # Re: outils de génération de mot de passe ?

      Posté par  . Évalué à 2.

      Vous n'aimez pas

      Si si

  • # trousseau interne FF + FFsync

    Posté par  . Évalué à 3.

    J'ai lu un peu rapidement certes mais je ne vois pas ce que cela apporte par rapport au trousseau interne de FF combiné FFsync ?

Suivre le flux des commentaires

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