Gérer enfin sérieusement la question des mots de passe…

Bon, il est temps de devenir sérieux sur les questions de sécurité informatique et, bien sûr, ça commence par avoir des passwords qui ressemblent à quelque chose (genre ed022f4f8ba5fa88c7d7e87d34a plutôt que nom-de-mon-chat…).

Mais, tout de suite, se pose la question cruciale : comment faire pour se souvenir de mots de passe aussi compliqués ?

Je pense qu’une solution est d’utiliser une application qui va gérer cela à notre place et nous demander de nous souvenir d’un seul password maitre… Et je crois avoir trouver une application de ce goût-là !

Il s’agit de YPassword développée par Yann Esposito. YPassword est un Widget à intégrer au sein de votre Mac OS… Ah, vous n’avez pas de Mac mais plutôt un truc sous Windaube ?
Dans ce cas, vous pouvez regarder du côté de 1Password mais je n’en sais pas plus sur ce produit… Alors que pour ce qui est de YPassword, j’ai plus à dire !

Tout d’abord, l’auteur explique très bien sur cette page les principes et la méthode qui sont à la base de son logiciel. Il explique aussi pourquoi vous devriez avoir recours à un gestionnaire de mots de passe comme YPassword.

J’en ai profité pour poser quelques questions à l’auteur qui a répondu vite et bien, jugez plutôt :

Oui, c’est le problème majeur avec tous les outils de gestion de mots de passe. Une fausse réponse serait de dire « faite moi confiance ». Non, je ne ferai pas celle là, ou plutôt pas que celle là :- pour la confiance, je suis une personne sérieuse, avec une vie stable. Je n’irai jamais essayer de voler des informations à des tiers. Celà va à l’encontre de mes idées et aussi de mes intérêts. Sans parler des problèmes de légalité. Évidemment, ça, n’importe qui peut le dire, mais j’ai un blog avec pas mal de détails sur mon identité, un CV, etc.

Ça veut simplement direque je ne suis pas un « script kiddie », ni un scammeur 🙂 Bon, ensuite pour l’étape de confiance suivante. Les seules vérifications quasi-absolues que vous pouvez faire sont : 1ère solution : regarder les traces réseaux, et vérifier qu’il n’y apas de paquet réseau qui sort lors de l’utilisation de mesapplications. C’est, je pense, assez facilement vérifiable, surtoutpour vous ;-). C’est même vrai pour l’application iPhone sauf si vouscliquez sur les liens vers le site officiel bien entendu. On peut rajouter à celà que toutes les applications fonctionnent sansréseaux. Par exemple le widget. Mais aussi les applications web. Une fois téléchargées sur votre client si vous coupez le réseau, ellescontinuent de calculer correctement les mots de passe. 2ème solution : regarder le code source. C’est souvent un argument refuge, mais cette fois ce n’est pas une pirouette. Tous mes outils (à part pour l’application iPhone) ont leur code source ouverts et endomaine public. Souvent le code est assez court pour être vérifier _vraiment_. Je pense que je peux vous aider pour ça.

Partons du plus simple au plus compliqué :0. Le dashboard widget, je suis presque certain qu’il existe unendroit où on peut vérifier les autorisations demandées par chaque widget. Il est facile de constater que le mien ne demande pas d’accès au réseaux. Seulement un accès à un fichier qui enregistre les préférences. De ce coté là, pas de soucis, Apple à fait le travail. En plus le widget est un ensemble de fichiers, html/css/js que l’on peut facilement regarder. Le code est dans les js, et je pense qu’il est très lisible. Il est donc vérifiable si vous vous en sentez le courage. Notez de plus qu’à chaque redémarrage de Dashboard, vous devez entrez à nouveau votre mot de passe principal parce que je ne le sauvegarde jamais sur le disque. Même pas dans le keychain.

1. le script ypassword (http://github.com/yogsototh/getpass), le code est disponible ici :https://github.com/yogsototh/getpass/blob/master/ypasswordIl fait 30 lignes, il est clair qu’il n’y a aucune tentative d’envoi à un serveur centralisé.

2. les applications web. L’application faite avec Cappuccino est un peu plus jolie, mais par contre le code doit être compliqué. Cappuccino est un générateur de javascript (en gros). Le plus simple à vérifier c’est l’application jQuery. Vous pouvez vérifier le code source, le copier et l’héberger sur un serveur à vous. Il ne s’agit que de fichier javascripts, html et css. Toutes les opérations se font coté client. Là aussi, le code source est je pense assez lisible. Ça demande un peu plus d’effort que précédemment, mais je pense que c’est réalisable.

3. Pour l’appli iPhone, c’est par contre un problème de confiance. Jene vois pas comment, sans vous donner accès au code source, vous prouvez que l’appli ne fait pas des choses bizarres. Le plus simple serait de trouver un moyen de mettre l’application dans une _sandbox_ qui ne peut pas se connecter au net. Mais je ne pensepas qu’iOS propose ça avant un petit moment. Si vous avez le moyen je pense aussi que vous pouvez vérifier que l’application ne fait pas appel à des librairies qui font appel au web. Mais ça veut dire, décrypter l’exécutable de mon application, lancer la commande string dessus pour vérifier les librairies utilisées. Mais, il y a toujours le risque qu’Apple enregistre tout ce que vous tapiez sur votre iPhone. C’est le même genre de confiance qui est enjeu. À noter, je sauvegarde le mot de passe principal dans le keychain, parce que je considère que sur iPhone l’exigence va plus du coté de la simplicité d’utilisation que de la sécurité à tout prix. keychain reste un endroît très sûr pour enregistrer les mots de passes. J’espère au moins que ça a pu vous prouvez que j’étais de bonne foi :-).

le forcePaste ne sert que dans les cas où le copier/coller ne marchepas pour certains champs.Dans ce cas, il faut copier le mot de passe, lancer « forcePaste » etpositionner son curseur dans le champs récalcitrant. « forcePaste »simule des tapes sur le clavier qui reviennent à faire un copier/coller. Personnellement je copie/colle à chaque fois. Et en fait je laisse Safari enregistrer mes mots de passes générés dans keychain. Donc en général je n’utilise le widget que lorsque je veux changer de mot de passe ou que je n’ai pas enregistrer le mot de passe avec Safari. Jem’en sers aussi pour les application qui demande des mots passes comme l’application twitter.

> # Pourquoi avoir réalisé YPassword ?

Je suis un grand testeur de nouveau services web. Au moment detwitter, il en fleurissait des dizaines. Et chaque service demandaitun nouveau mot de passe. De plus, j’ai réalisé que le mot de passe que j’avais donné pour accéder aux mails de mon entreprise (petite) était le même que pour mon gmail. Rajouté à celà, j’avais dans mon entourage quelqu’un qui en créant sa petite entreprise voulais (contre toute déontologie) regarder certaines informations privés que ses clients lui fournissaient. En recherchant un peu partout, il s’est avéré que la méthode d’YPassword est certainement à la fois la plus sûre et la plus simple que j’ai trouvé. C’est le bon compromis entre très bonne sécurité et simplicité d’utilisation. J’ai commencé à faire des sha1 à la main, en ligne de commande. Puis j’ai réalisé le script. Ensuite, pour me simplifier la vie, j’aicommencer à faire de petits outils autour de la méthode.

Je n’ai pas l’historique sous la main, je vous donnerez plus dedétails dans la soirée si vous le souhaitez. Mais de mémoire, les version 1.0 à 1.4 étaient des corrections de bug mineurs d’interface graphique.Pour la version 1.5 j’ai ajouté la possibilité de changer de mot de passe. J’ai fait l’expérience de compromettre un d’entre eux sur un forum :-(, gasp… La version 1.6 était une correction rapide d’un bug (d’interface) de la 1.5.

En réalité, la méthode est disponible partout, sur le web. Par contre, c’est la partie préférence (liste des sites web, login, longueur du motde passe, etc…) qui eux ne sont disponible que localement. Il y a peu de risque de publier ces données sur une page web, survotre blog ou autre. Un attaquant ne disposant que de ces informations ne pourra pas retrouvez vos mots de passe sans votre mot de passe principal. Cependant, ça n’est pas complètement satisfaisant. C’est pourquoi je suis en train de travailler à un moyen de synchroniser ces informations Le mode opératoire devant nécessairement être :
– Chaque client (iPhone, web),  doit encrypter le blocs d’informations (nom de login, longueur des mots de passes, etc.) dans un « blob ».
– Ce « blob » est alors envoyé sur un serveur que chaque client doitêtre capable de récupérer. Je comptais faire moi même le serveur qui devait héberger des blobs encryptés, mais avec l’annonce d’iCloud, je vais attendre d’avoir plus de détails pour savoir si je peux utiliser ça directement. Au moins, ça sera peut-être encore plus sûr que d’héberger moi-même les « blobs ». Sans compter que je pense que la législation française n’est pas très souple avec l’hébergement de données et en particulier de données encryptées. Par exemple, ça ne m’étonnerai pas que l’on me demande d’avoir la capacité de pouvoir décrypter tous les « blobs » que j’héberge. Ce qui est évidemment hors de question. Le seul moyen d’avoir quelque chose de sûr c’est que je ne puisse en aucun cas savoir ce que les « blobs »contiennent.

Si vous êtes séduit comme je l’ai été, vous pourrez trouver YPassword ici…