Journal Publication de WKR

Posté par  . Licence CC By‑SA.
Étiquettes :
42
29
jan.
2014

Sommaire

Présentation

WKR signifie "Web KeyRing". Il se veut un gestionnaire de mot de passe similaire à LastPass, gPass, ou le gestionnaire de mot de passe de votre navigateur. Plutôt que d’expliquer en détail tout ce qu’il fait, je vais plutôt vous expliquer les différences avec ses concurrents :

  • Contrairement au gestionnaire de mots de passe du navigateur, il est indépendant du navigateur et n’utilise aucune spécificité à Firefox/Chrome
  • Contrairement à LastPass, il est libre et autohébergeable
  • Contrairement à tous ses concurrents (et c’est la principale raison qui m’a poussé à le développer, qui me pousse à continuer malgré l’arrivée de gPass, et qui me pousse à le publier) est l’approche hiérarchique.

« Mékeskidi » ?

Tout simplement qu’un « ring » (désolé pour les puristes du français, mais « trousseau » c’est super moche) peut être défini comme un « ring » fils d’un parent. À ce moment là, il pourra être déchiffré de deux manière :

  • Soit à l’aide du mot de passe du ring
  • Soit à l’aide du mot de passe du ring parent

Par exemple, supposons la hierarchie suivante, pas fictive du tout (c’est celle que j’utilise)

master (le plus sensible: mails et sites gérant de l’argent (amazon par exemple))
    perso (sites moins sensibles sur lequel je suis inscrit avec ma véritable identité)
        web (sites sur lequel j’utilise un pseudonyme auquel je tiens, par exemple LinuxFR ou Github)
            bmn (sites sur lesquels je me suis inscrit parce que j’y étais obligé, mais que j’en ai rien à faire si je me le fait pirater)
    pro (sites sur lequel je me suis inscrit pour des raisons professionnelles)

Lorsque WKR me demande mon mot de passe, je peux donner le mot de passe maître (correspondant à la racine, que j’ai appelé « master » dans mon exemple), me permettant de lire absolument tous les mots de passe. Mais je peux également me contenter de donner le mot de passe « web », qui me permettra d’ouvrir (par exemple) LinuxFR mais pas Gmail.

Les intérêts de cette approche :
- je peux (et je compte) partager "bmn" avec des amis, ce qui en fera une sorte de bugmenot privé (d’où le nom). Ou mon mot de passe pro avec un collègue.
- quand je ne suis pas certain du navigateur sur lequel je suis, je peux donner les accès minimum nécessaires pour ce que je veux faire

Les inconvénients :
- ça fait 5 mots de passe à retenir
- sûrement d’autres que je n’ai pas remarqué

Description un peu plus technique

Commençons par parler de mes concurrents.

En théorie, LastPass est celui qui offre le plus de sécurité : en tant qu’extension Firefox, il est complètement isolé du reste du web pour faire ses opérations cryptographiques ; son interface intégrée dans le navigateur (à l’opposé de la page web) le rend à peu près insensible à toute tentative de phising. En pratique, son caractère non-libre signifie un « non » définitif pour un logiciel ayant vocation à gérer le mot de passe d’un site qui a accès à ma carte bancaire.

gPass est aussi implémenté en tant qu’extension Firefox ; son point absolument bloquant pour moi est que le mot de passe maître doit être entré sur le site sur lequel il s’authentifie ; un webmaster malintentionné n’aura absolument aucune difficulté à le récupérer. Le second inconvénient est qu’il ne fonctionne que sous Firefox (merci Captain Obvious !)

WKR n’est pas une extension. Aujourd’hui, il se présente comme un script GreaseMonkey — il pourrait tout aussi bien se présenter comme un bookmarklet, c’était le cas sur mes premiers jets du projet. Il devrait donc marcher sur tous les navigateurs (qui supportent javascript 1.7, j’aime le sucre, tant qu’il est syntaxique). Comme toute personne s’étant intéressé au sujet, un bookmarklet ou un script GreaseMonkey pouvant plus ou moins facilement être manipulé par la page visitée, le script se contente de faire deux choses :

  • Inclure une pointant sur l’installation de WKR
  • Mettre en place un mécanisme de communication entre cette frame et le site appelant

Il est à savoir que tout navigateur digne de ce nom empêchera le site appelant de faire des choses cochonnes avec le contenu de l’iframe, c’est la base du modèle de sécurité de WKR. Si votre navigateur est un peu trop tolérant envers les opérations cross-domain pas très catholiques, vous êtes aussi mal loti que gPass.

À partir de là, le site appelant, à l’aide du canal de communication, demande à l’iframe les données associées à l’URL. L’iframe télécharge le keyring chiffré, demande le mot de passe, trouve les informations correspondantes, et renvoie, toujours via le canal de communication, les infos liées au site. Le script se charge alors de remplir le formulaire, et le tour est joué.

Pour résumer, voici en qui vous devez avoir confiance dans chacune des solutions :
- LastPass : vous devez avoir confiance dans le fait que l’implémentation réelle correspond à ce qui est annoncé par LastPass Inc.
- gPass : vous devez avoir confiance dans le site que vous visitez ; l’hébergeur des données peut être vérolé jusqu’à la mœlle sans que ça ne pose de souci
- WKR : vous devez avoir confiance dans l’intégrité de l’hébergeur, c’est à dire qu’il n’ait pas modifié les fichiers pour y intéger un keylogger (par exemple). La confidientialité, comme ses concurrents, n’est pas un problème, les opérations cryptographiques étant faites côté client, comme ses concurrents.

Si vous testez WKR (comment ça, je ne vous ai pas encore suffisamment dégoûté ?), vous remarquerez une case « retenir le mot de passe ». Le mot de passe est enregistré dans le DOM storage (donc le navigateur) associé à l’hébergeur de WKR. Sachez tout de même que si vous utilisez cette option, votre clé AES sera stockée en clair sur votre disque dur. Comme le mien est chiffré, je m’en fiche.

Installation & Utilisation

Le code se trouve sur http://github.com/sloonz/wkr

Côté serveur :

  • Insallez autofill.htm, keyring.js, forge.min.js et keyring.php où vous voulez. Comme l’extension de ce dernier fichier vous le fait dire, il vous faudra PHP sur votre serveur
  • Modifiez la première ligne de keyring.php (bon, la deuxième en fait, la première étant <?php) et faites pointer le dossier vers un endroit où PHP peut écrire. Je vous conseille de le mettre hors de la racine du serveur web, sait-on-jamais-on-est-jamais-trop-parano
  • HTTPS est indispensable, sinon WKR sera inutilisable sur les sites en HTTPS

Création du keyring (attention, interface utilisateur très poussée ici !) :

Côté client :
- Installez autofill.js en tant que script GreaseMonkey. Ce dernier va vous demander l’adresse de WKR, vous devez donner l’adresse de autofill.htm. Faites Control-X pour invoquer WKR : il va vous demander le mot de passe de votre ring si celui-ci n’est pas enregistré. Il cherchera ensuite les informations associés au site courant. S’il y en a, il remplira le premier formulaire contenant un mot de passe, ou le formulaire courant si vous aviez appuyé sur C-x en ayant un élément de formulaire sélectionné. S’il n’y en a pas, il va vous proposer d’ajouter une entrée. S’il y en a plusieurs, ça utilise la première
- Si vous vous plantez dans l’adresse de WKR, l’information est stockée dans about:config

TODO

Tant d’idées, et si peu de temps. Voici ma liste de choses à faire, dans l’ordre de priorités :
- Gérer les sites qui ont plusieurs entrées (je suis inscrit sur amazon.fr à la fois de maniière perso et pro)
- Interface d’administration pour ajouter, supprimer et modifier des entrées
- Interface d’administration pour ajouter, supprimer et modifier des rings
- Bookmarklets & OTP
- Interface de création/suppression de compte/export

Comme j’avance sur ce projet quand j’ai le temps ET l’envie, je ne vous donnerai aucune autre réponse que « when it’s ready ». Disons que les deux premiers points sont assez importants pour moi et devraient arriver pas trop lentement (quoique le second est un gros morceau niveau UI, et l’UI et moi ça fait deux), pour les autres je mourrai peut-être de ma belle mort avant qu’ils soient faits (et non, je ne suis pas nonagénaire). J’accepte les contributions sur github si le code n’est pas encore plus crade que le mien (mais si c’est le cas, vous avez d’autres problèmes plus urgent à régler) et les motivations en nature si vous êtes rousse à forte poitrine (ha, on me souffle dans l’oreillette qu’on est pas encore vendredi). Une contribution qui me motiverait beaucoup à travailler, c’est un jolie interface en HTML/CSS (parce que pour ceux qui ont eu la folie de tester verront que c’est loin de mon domaine de compétences : je peux même pas dire les goûts et les couleurs toussa : il n’y a aucune couleur), y compris (et surtout en fait) pour les fonctionnalités pas encore implémentées.

  • # Chouette projet.

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

    Tout est dans le titre.
    Je pense de plus en plus à passer sur un système de ce genre. je vais regarder et suivre WKR avec attention.

    La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

  • # TeamPass

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

    Merci pour ton travail.

    J'utilise TeamPass depuis un certain temps.
    http://www.teampass.net/

    Il est libre, multi-utilisateur, hiérarchique, PHP donc s'(auto)héberge facilement.
    Je l'aime bien mais il est juste un peu lourd pour une utilisation personnelle.

    Vu que Teampass est un projet pas mal avancé, comment le tien se différencie ?

    • [^] # Re: TeamPass

      Posté par  . Évalué à 8. Dernière modification le 30 janvier 2014 à 01:00.

      Je suis totalement passé à côté lorsque j’ai fait WKR, je ne l’ai vu qu’il y a quelques jours. Je n’ai pas étudié la chose (utilisation + lisage de code) pendant plus de quelques heures, donc ce que je dis est à prendre avec des pincettes, mais voilà ce que j’en retire :

      • On a pas vraiment le même usage en tête. TeamPass se veut une version intranet de KeePassX, dans lequel la gestion multi-utilisateur des mots de passe est au centre du système. Dans WKR la seule gestion multi-utilisateur est « on s’échange le mot de passe ». Ça peut paraître secondaire comme différence au premier coup d’œil mais ça implique des choix assez différents

      • À l’usage WKR est pensé pour s’intégrer le plus aisément possible dans le workflow d’un internaute (je me met sur la page de login du site, j’appuie sur C-x, WKR apparaît et me remplit le formulaire) ; TeamPass ne l’est pas du tout (je me met sur la page de login du site, j’ouvre un nouvel onglet, je me connecte sur TeamPass, je cherche le site associé, je copie le mot de passe, je repasse sur le premier onglet, je colle). Rien de fondamental mais ça montre la priorité de chacun des projets (qu’on s’entende : ce n’est pas une critique de TeamPass, j’utilise KeePass au boulot, ce n’est juste pas le même usage)

      • TeamPass n’a pas de gestion hiérarchique telle que pensée dans WKR. TeamPass peut organiser hiérarchiquement les entrées dans plusieurs dossiers, il est vrai, mais il est impossible de définir un mot de passe spécifique à un dossier qui permettrait d’ouvrir un dossier fils avec son propre mot de passe ou le mot de passe du dossier père. En fait, dans TeamPass, à toute entrée est associée au plus un et un seul mot de passe permettant de la chiffrer/déchiffrer, parfois 0

      • TeamPass possède deux systèmes de chiffrement des mots de passe. Le premier, pour les dossiers dits « personnels » (c’est à dire limités à 1 utilisateur et non partageables) est un simple AES dont la clé est dérivée du mot de passe de l’utilisateur, très exactement comme gPass, WKR ou (en tout cas c’est ce qu’ils disent) LastPass.

      • On en arrive au gros point noir (de mon point de vue) de TeamPass. Le second système de chiffrement des mots de passe est utilisé pour tous les dossiers partageables. C’est aussi de l’AES… avec une clé stockée dans un .php sur le même serveur, clé générée à l’installation et utilisée pour absolument tous les mots de passe excepté les mots de passe personnels. Autrement dit, toute personne qui a pu accéder en lecture à ce fichier est en mesure de déchiffrer la grande majorité des mots de passe. Dans WKR, la seule manière pour l’administrateur du service d’accéder aux mots de passe des utilisateurs est de modifier le javascript envoyé au navigateur pour y insérer un keylogger.

  • # pbkdf2

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

    Salut!

    Super idée, mais j'ai un petit souci.. et je pense qu'il est difficilement réparable: je n'ai accès qu'à PHP 5.3 et la fonction hash_pbkdf2 n'existe pas :(

    Est-ce qu'il y a une raison technique pour utiliser ça au lieu de crypt?

    • [^] # Re: pbkdf2

      Posté par  . Évalué à 5. Dernière modification le 30 janvier 2014 à 11:20.

      J’ai une bonne nouvelle et une mauvaise nouvelle :)

      La bonne nouvelle est que la prochaine version ne nécessitera plus hash_pbkdf2. Le but est de ne faire aucune opération cryptographique sur le serveur ; ce but n’est pas encore atteint à cause du manque d’une interface HTML+JS pour créer un compte (je dois donc créer le ring root sur le serveur, d’où hash_pbkdf2), mais c’est le prochain point sur la todo-list.

      La mauvaise nouvelle c’est qu’il faudra quand même une version récente de PHP pour l’interface jsonSerialize (5.4 si j’en crois la documentation).

      Sur le pourquoi de AES+PBKDF2 au lieu de crypt, plein de réponses :
      - La page Wikipedia sur [DES] explique très bien que ce dernier est déconseillé
      - La version PHP est très récente, avant c’était du Python. Et c’était AES+PKBDF2.
      - http://fr2.php.net/manual/en/function.crypt.php indique : crypt() will return a hashed string using the standard Unix DES-based algorithm or alternative algorithms that may be available on the system.. Pas envie de faire de la rétro-ingénierie par savoir dans quels cas crypt utilise quels algorithmes.

      • [^] # Re: pbkdf2

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

        Aie aie aie.. dommage donc.
        Je vais voir s'il existe des implémentations de jsonSerialize autre que natives..

      • [^] # Re: pbkdf2

        Posté par  . Évalué à 2.

        Si tu vas sur la page de la doc de hash_pbkdf2 tu verras qu'il est recommandé d'utilisé à la place la fonction password_hash.
        L'avantage de password_hash sur crypt ou hash_pbkdf2 c'est que c'est plus une interface de génération de hash prévu pour être compatible avec des changements de primitive de hash dans le futur (pour plus de sécurité).

        Même si tu prévois de ne plus utilisé le hachage coté serveur, c'est une alternative bien meilleure.
        Et la beauté de la chose veut qu'une âme généreuse et fait une implémentation en php de cette lib pour la rendre accessible sur php 5.3 et 5.4.
        Çà ne devrait pas vous dispenser de faire la mise à jour mais c'est toujours mieux qu'utiliser autre chose.

  • # Python -> Php

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

    Bonjour,

    pourquoi être passé de Python à Php pour le projet?

    C'est sympa python sur un serveur, et on le trouve disponible sur beaucoup d'hébergements mutualisés.

    A+

    Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

    • [^] # Re: Python -> Php

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

      pourquoi être passé de Python à Php pour le projet?

      Parce que lorsque tu es confronté à la vraie vie avec de vrais utilisateurs qui veulent juste que ça marche sans appeler 30 fois leur hébergeur parce qu'il manque telle extension ou parce qu'ils n'ont pas la bonne version,…, tu laisses tomber python.

      p.s: Et mince j'ai marché dedans ! :-)

    • [^] # Re: Python -> Php

      Posté par  . Évalué à 3.

      J’avais laissé un appeau à troll pour les féministes du site et c’est un troll sur les langages qui part. Je suis déçu :(

      Déjà, la version Python n’était pas une application web, c’était une application en ligne de commande que j’utilisais sous ssh pour ajouter/modifier des entrées (côté navigateur internet je ne pouvais qu’invoquer l’auto-filler avec du pur javascript, 0 ligne de code côté serveur)

      De suis passé sur PHP parce que Python côté serveur je ne connais pas, et j’ai un apriori assez négatif. Disons que la dernière fois que j’avais regardé (il y a des années), le Python sur le web se divisait en deux catégories :
      - des frameworks gargantuesques à la django
      - des libs très très bas niveau (apache mod_python, cgi, fastcgi…)

      Aucun des deux ne m’intéressent, je veux une abstraction simple de la communication au serveur web (bref, je m’en tape que derrière ce soit un mod apache, du cgi ou du fastcgi) mais pas de framework complet.

      Pour finir, la partie serveur (et pas web) en Python que j’avais et la partie PHP que je fais n’ont strictement rien à voir niveau fonctionnel, je n’aurais rien pu récupérer. Tout ce qui était fait en Python est soit déjà fait côté JS soit sera fait côté JS.

  • # GUI

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

    Ce projet me semble très intéressant. L'intégration avec le navigateur a l'air bien poussée, du coup je me dit que je pourrais peut être l'utiliser. Parce que bon, la sécurité c'est cool, mais le confort d'utilisation l'emporte encore chez moi (sinon je n'aurais plus d'Android/GMail/…).

    Le seul truc qui me chagrine, c'est le manque de GUI pour la création des ring/mots de passe/…. Du coup je vais mettre ce projet de côté et attendre que ça arrive :)

    Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

  • # gPass

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

    C'est marrant de voir qu'on a eu exactement les même problématiques !

    Pour le coup, gPass est pas mal en avance sur WKR (interface graphique au top ;), multi comptes, chiffrement uniquement sur le client). Les seules différences sont donc :

    • WKR est un script multi-navigateur
    • Gestion hiérarchique des mots de passes

    Pour le dernier point, on peut faire "presque" la même chose avec gPass en utilisant plusieurs clés maîtres.

    Néanmoins, il reste un point important qui n'est pas traité par WKR : la force des mots de passe. Vu la puissance de calcul disponible sur nos machines, il est important d'inciter les utilisateurs à générer des mots de passes forts (et différents pour chaque compte) autant pour la clé de déverrouillage du trousseau que pour les mots de passes stockés. Pour cela, gPass dispose d'un générateur de mot de passe et de l'affichage de la force de la clé maître (dernier commit en date).

    Enfin, il faut trouver le bon compromis entre sécurité et utilisabilité, ce qui n'est jamais évident.

    Bonne continuation.

    • [^] # Re: gPass

      Posté par  . Évalué à 2. Dernière modification le 04 février 2014 à 17:57.

      Vu la puissance de calcul disponible sur nos machines, il est important d'inciter les utilisateurs à générer des mots de passes forts

      Quelqu’un qui est intéressé par gPass/LastPass/WKR est à priori déjà sensibilisé au problème je pense. En pratique je ne vois pas vraiment l’intérêt de recoder ça dans le navigateur quand un pwgen -y 15 fait la même chose.

      • [^] # Re: gPass

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

        C'est "à priori" le problème.

        De plus, tu ne vas pas utiliser pwgen (qui n'est pas forcément disponible par défaut sur toutes les plateformes) pour ta/tes clé(s) maître(s), trop compliqué à retenir.

        Le générateur intégré est juste une facilité d'utilisation. Quant à l'affichage de la force de la clé maître, c'est une indication pour ne pas avoir un faux sentiment de sécurité parce qu'on aura délégué sa gestion des mots de passes.

Suivre le flux des commentaires

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