Journal Où mettre son archive de mots de passe ?

26
25
jan.
2016

Bonjour Nal,

Depuis peu, j'utilise des gestionnaires de mots de passe qui utilisent un format de fichier commun, et qui me permettent donc de partager la même archive aussi bien à la maison qu'au travail. Maintenant, le problème, c'est que cette archive des mots de passe, je dois la partager. J'ai pour l'instant quelques solutions en tête, et j'aimerais savoir ce que vous, mes moules paranoïaques préférées, vous faites ou feriez…

Les solutions actuelles sont :

  1. Stocker l'archive de mots de passe sur un clef USB, et la brancher/débrancher de l'ordi que j'utilise dès que j'ai besoin de me logguer quelque part.
  2. Stocker l'archive de mots de passe dans le cloud (eg, dropbox), et faire confiance au chiffrement de l'archive. C'est une solution courante je crois, mais des méchants pourraient cibler dropbox pour voler ces fichiers et attendre qu'une faille dans la crypto soit publiée pour casser les archives. Ca me fait un peu peur de laisser tous mes mots de passes, même chiffrés, dans le cloud.
  3. La même chose, mais avec du rot13 (ou autre) en plus, juste pour cacher un peu plus l'identité de l'archive.
  4. Stocker l'archive de mots de passe sur une machine accessible du net, mais qui n'est pas un stockage dans cloud, et coder mon petit client pour la synchro (avec rot13 au cas où). Je pense par exemple à un hébergeur quelconque, ou à une machine à la maison (mais ça ne me botte pas trop de me mettre un serveur à la maison 24/7 de nouveau…).

Alors, quelle est votre opinion ?

  • # Parano?

    Posté par . Évalué à 4.

    Mouais, alors je comprendrais que tu hésites à mettre tes mdp en clair sur une Dropbox (au cas où la protection de la Dropbox serait cassée, ou que tu ne fasses pas confiance à Microsoft (quelle drôle d'idée)). Je comprendrais aussi que ça te fairait flippper d'avoir tes md chiffrées en téléchargement libre (HTTP?), même si le chiffrage est de bonne qualité, tu n'es pas à l'abri d'une faille. Honnêtement, le trouve que l'idée de péter la protection de la Dropbox puis de casser l'algo de chiffrage, c'est quand même se donner un mal de chien pour pouvoir troller à ta place sur Linuxfr… S'ils veulent tes mots de passe, les méchants vont venir te péter les genoux ou accéder physiquement à ta machine, c'est beaucoup plus facile et ça laisse moins de traces.

    Je trouve que la solution impliquant un serveur perso est plus dangereuse que le cloud grand public, parce que les ressources dont tu disposes pour sécuriser ce serveur sont des milliers de fois moins importantes que celles des services de cloud (certes, tu es aussi moins une cible, mais quand même).

    • [^] # Re: Parano?

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

      S'ils veulent tes mots de passe, les méchants vont venir te péter les genoux

      Ça dépend de la carrure des méchants;
      parce que la bande à jean-kevin , ils ne sont pas près de venir me péter quoi que ce soit.

      ou accéder physiquement à ta machine,

      J'ai un chat de garde.

      Je trouve que la solution impliquant un serveur perso est plus dangereuse que le cloud grand public,

      Bof.

      parce que les ressources dont tu disposes pour sécuriser ce serveur sont des milliers de fois moins
      importantes que celles des services de cloud (certes, tu es aussi moins une cible, mais quand même)

      Je ne vois pas pourquoi. Sur mon serveur, je peux fermer les ports que je veux, n'autoriser que certaines zones ou IP, verrouiller les options des logiciels que j'installe, entre autre.

      • [^] # Re: Parano?

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

        Sur mon serveur, je peux fermer les ports que je veux, n'autoriser que certaines zones ou IP, verrouiller les options des logiciels que j'installe, entre autre.

        Un bon parano sait que le filtrage IP peut être bogué ou mal configuré, que le firmware de la carte réseau peut avoir une faille, que le firmware du modem/de la box peut avoir une faille, que le serveur est connecté au réseau électrique, que les papillons peuvent reconfigurer des serveurs en battant des ailes et que la mécanique quantique peut convertir ta distribution GNU/Linux en un Windows 3.11 for Workgroups même si c'est peu probable statistiquement. Sans parler des attaques par EMP. L'informatique c'est mort. Autant avoir un pont-levis et une lourde barre d'acier en travers la porte.

        • [^] # Re: Parano?

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

          Autant avoir un pont-levis et une lourde barre d'acier en travers la porte.
          

          Et encore…

          • [^] # Re: Parano?

            Posté par (page perso) . Évalué à 5. Dernière modification le 26/01/16 à 11:54.

            Autant avoir un pont-levis et une lourde barre d'acier en travers la porte.

            Et encore…

            Ouaip, la barre, mieux vaut l'avoir dans la main pour la foutre en travers de la gueule des meuchants.

            Faites gaffe quand même, les monsieurs vêtus de kevlar noir qui défonce la dite porte en pleine nuit, c'est des gentils, en fait.

        • [^] # Re: Parano?

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

          Plus sérieusement l'argument de "au moins je suis sûr de la sécu" est un peu léger pour l'autohébergement…

          Dropbox et les autres sont ptêtre pas parfaits, mais je leur fais confiance pour avoir une équipe payée pour ça, alors que le barbu qui veut me faire croire qu'il suit les CVE avec alertes en temps réel et procédure de mise à jour fiable, un Snort et pas juste un script qui ping…

      • [^] # Re: Parano?

        Posté par . Évalué à 2.

        parce que la bande à jean-kevin , ils ne sont pas près de venir me péter quoi que ce soit.

        OK, c'est vachement plus crédible que la bande à Jean-Kévin vienne te péter ton chiffrement.

        À mon avis, la bande à Jean-Kévin, si elle arrive à casser un chiffrement considéré comme sûr, c'est elle qui se fera péter les genoux par la NSA avant de pouvoir poster des photos de teub avec ton compte Twitter.

        Après, tu peux ajouter des contraintes, style autohébergement. Ça peut se justifier pour plein de raisons, y compris pour ne pas être tributaire d'un service externe, avoir le contrôle de tes données, ou simplement pour jouer à l'Anonymous et à se fair peur tout seul. Mais il faut reformuler ta question, parce qu'elle avait l'air de demander une solution pragmatique.

  • # Solution 1

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

    Bonjour !

    Personnellement j'ai opté pour la solution 1 doublée d'un cryptage LUKS de toute la partition du disque dur externe.
    Ça oblige à transporter le support sur soi régulièrement ceci dit, sur tous mes PC j'ai également une partition cryptée dans laquelle je copie l'archive de temps en temps pour essayer d'avoir tout à disposition même sans le disque. C'est très gérable.

  • # SyncThings ?

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

    Je prends mon exemple :
    - J'ai un keepass file que j'utilise pour ballader quelques comptes.
    - SyncThings sur différentes machines dont certaines natées.
    - SyncThings sur le téléphone (android).

    Voilà, quand je change un compte dans le keepass file, ça le change partout.

    Si tu en as le courage tu peux aussi changer/installer ton propre relay.

    Pour ce qui est un peu plus sécure, seul le fichier chiffré est partagé par mon propre relay.

    • [^] # Re: SyncThings ?

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

      J'utilise aussi Syncthing pour ça. Je ne sais pas si c'est vraiment "sécu" (mon serveur local est probablement moins bien défendu que Dropbox, mais ensuite le fichier qui stocke les mots de passe est aussi chiffré). Mais c'est pratique et je garde le contrôle d'où ça traîne.

      La difficulté est de trouver le compromis entre sécurité et confort d'utilisation : si ça devient trop contraignant, la flemmardise naturelle fait qu'on zappe et on finit par revenir aux post-it sur le bureau…

      Les quelques mots de passe vraiment importants sont dans ma tête ; au final, si un jour mon fichier est cracké, ça servira surtout à troller sur divers services. Mais vu ma mémoire, les mots de passes importants ne sont sans doute pas suffisamment forts, et probablement pas changés assez régulièrement. Je ne suis pas sûre qu'une solution parfaite existe…

    • [^] # Re: SyncThings ?

      Posté par . Évalué à 2.

      Même solution ici. Syncthing fait le boulot et bien. Pour l'instant c'est mon smartphone qui hébèrge la seule copie à peu près toujours en ligne et à jour quand je suis là physiquement (et que je pense à en activer le wifi) mais j'envisage d'installer la version arm sur mon NAS.

      Étant donné que je ramène mon laptop pro au minimum 4-5 fois par mois à la maison je ne prends même pas la peine de brancher mon smartphone au wifi pro quand je suis au bureau.

  • # pass

    Posté par . Évalué à 7.

    Pour ma part, pass, qui est un wrapper léger à GPG (pour le chiffrement des mots de passe) + git (pour la synchro). Et il y a même une extension Firefox pour les MdP web.

    • [^] # Re: pass

      Posté par . Évalué à 3.

      Et une application sur Android

    • [^] # Re: pass

      Posté par . Évalué à 2.

      Sur mon ordinateur personnel, j'utilise pass git push qui pousse sur un serveur accessible en SSH. Et qui a la clé GPG.
      Au boulot, ou ailleurs, je fais un SSH vers ce serveur, et je fais des copier/coller. J'ai pas trouvé comment dire à l'extension Firefox de demander au serveur distant via un SSH déjà ouvert de récupérer le mot de passe, parce que justement, je veux éviter d'avoir des fichiers, même chiffrés, sur mon disque de boulot.

      Y aurait moyen je pense, mais vu mon utilisation, j'ai pas pris le temps de le faire :)

      • [^] # Re: pass

        Posté par (page perso) . Évalué à 2. Dernière modification le 26/01/16 à 11:38.

        J'ai pas étudié ta solution, mais peut-être avec sshfs ? Comme ça ton extension firefox croit que les fichiers sont locaux et tu ne stockes rien.

        • [^] # Re: pass

          Posté par . Évalué à 1.

          C'est pas bête :) Et c'est plus simple que de transférer les autorisations de GPG par des sockets ;)

          • [^] # Re: pass

            Posté par . Évalué à 3.

            Fait gaffe à vraiment être parano, il faut s'assurer que tu n'utilise pas un éditeur de texte, un explorateur ou un navigateur qui stocke tout ou parti de ce fichier sur une partition en clair.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # EnPass

    Posté par . Évalué à 1.

    Bonsoir,

    Personnellement, j'utilise EnPass sur mon serveur Owncloud auto-hébergé. Par contre, il faut l'application cliente sur chaque PC/tablette, … à partir duquel on ve se connecter à la base de données.

    Xuo.

  • # autohebergement

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

    Pas besoin de réinventer la roue pour la synchro vers un serveur, des solutions comme seafile ou btsync sont excellentes.
    Sinon, un NAS type Synology propose le stockage et le client de synchro (cloudstation)

  • # why not ?

    Posté par . Évalué à 10.

    Pour ma pars c'est une archive keepass synchronisé par webdav sur un owncloud.
    pour déverrouiller l'archive j'utilise une clef de cryptage que je transporte uniquement sur clef USB…

    Si mon site est compromis, mon archive reste difficilement accessible… car sans la clef, l'archive ne s'ouvre pas.

  • # fichier chiffré comme a la maison

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

    J'utilise pour ma part un fichier chiffré par mes soins.
    J'avais décrit la procédure dans un article sur feu diablotins.org.Je l'ai exhumée ci.

    Sans entrer dans les détails, j'associe dans un fichier de type «csv» les identifiants à une localisation;
    puis je chiffre le tout.
    Pour le déchiffrer, j'utilise des alias tcsh et/ou des scripts shell.

    En général, j'accède au fichier ( et aux commandes) depuis un serveur distant.
    Pour être sûr de ne pas le paumer, il se trouve aussi stocké dans un cloud.

    L'avantage est qu'il n'y a rien à installer, les scripts fonctionne de base sous un Linux ou un BSD.

    Et, comme j'utilise i3 en tant que gestionnaire de fenêtre, j'ai juste une petite fenêtre en bande horizontale sous Firefox qui ne me sert qu'à chercher un mot de passe.

  • # code 128

    Posté par . Évalué à 2.

    Je les imprime en code 128 sur des post it, du coup ce n est pas lisible sans lecteur de code barre, et cela n eveil pas les soupcon. J hesite avec du data matrix qui largement plus répandu et plus difficile a généré

    • [^] # Re: code 128

      Posté par . Évalué à 1.

      pas mal, mais n'importe quel smartphone doit savoir lire du code 128, non?

      • [^] # Re: code 128

        Posté par . Évalué à 2.

        oui toutafé, le but n'est pas de le chiffrer mais de me le rendre dispo pour moi facilement, c'est une petite cachette :). après je n'ai pas écrit :

        mots de passe banque : ÑXLPÌTyjÍ1bÓ

        • [^] # Re: code 128

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

          c'est une petite cachette

          un peu de (re)lecture
          http://www.ebooksgratuits.com/pdf/edgar_poe_la_lettre_volee.pdf

          • [^] # Re: code 128

            Posté par . Évalué à 1.

            La nouvelle est amusante, mais la fin m'a surpris. Le ministre D… est assurément plus rusé que le préfet G…, mais il n'a pas été assez finaud : la lettre, il aurait du la détruire. Foi de logicien !

            Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

        • [^] # Re: code 128

          Posté par . Évalué à 4.

          après je n'ai pas écrit :

          mots de passe banque : ÑXLPÌTyjÍ1bÓ

          Je confirme: ça n'ouvre pas son compte en banque!
          ----->[ ]

  • # Dropbox

    Posté par . Évalué à 0.

    Je fais du 1Password (Mac OS X, iOS, Windows®) et synchronisé via Dropbox et je sers les fesses.

    Aussi je fais attention de ne pas ouvrir trop souvent l'app sur Windows® (1P à prévu la saisie dans un bureau sécurisé)
    Je suis sidéré qu'il n'y ait pas un vrai champ mot du passe sur Windows®. J'ai un outil de remplissage de texte et ce con vois ce que je tape dans les champs mot de passe.
    Sur Mac OS X, j'ai le même genre d'outils et ils n’ont aucun accès à ce type de champs.
    "L'icône avec deux points noirs apparaît lorsque Typinator ne peut pas voir ce que vous saisissez parce que votre ordinateur travaille en "mode clavier sécurisé". Typinator utilise un "contrôle des événements" qui permet de surveiller votre saisie. Pour des raisons de sécurité, Mac OS X désactive ce contrôle lorsque vous saisissez du texte dans un champ de recherche. Cependant, il existe quelques programmes qui activent le mode "clavier sécurisé" et ne le désactivent pas lorsqu'il n'y a plus de risque concernant la sécurité. Dans cette situation particulière, le mode "clavier sécurisé" a été activé par Safari."
    Je ne sais pas si ce mode existe sur Linux. Je ne vais sous Linux qu'en mode commande. ;)

    • [^] # Mode clavier sécurisé

      Posté par . Évalué à 3.

      Je ne sais pas si ce mode existe sur Linux.

      Oui, typiquement les gestionnaires de connexion l’utilisent, et xterm permet de l’utiliser aussi (il est activable depuis le menu obtenu avec Ctrl-bouton gauche), notamment pour le cas où l’on aurait besoin de taper des mots de passe depuis le terminal.

      Les autres terminaux et applications ne le proposent pas, en comptant sur la sécurité qui empêche d’accéder à la session X du voisin (de nos jours, elle tient la route, mais il y a longtemps, elle n’était pas aussi avancée ni même en place, d’où l’utilité sur xterm), ou sous prétexte que certains keyloggers sont capables de l’outrepasser (je suppose que c’est le cas uniquement s’ils tournent sous le même utilisateur, en root ou peut-être depuis un utilisateur autorisé à accéder à la session X, par exemple par ssh -X, mais je n’ai pas plus d’info à ce sujet).

      Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

    • [^] # Re: Dropbox

      Posté par (page perso) . Évalué à 3. Dernière modification le 26/01/16 à 07:02.

      Je crois bien que sous X11 tu es vraiment tout nu… :/
      Après si t’es direct sur le tty, ça devrait le faire. ;-)

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: Dropbox

        Posté par . Évalué à 2.

        Ici on ne parle que de solutions basées sur des fichiers encryptés. Existe-il une appli libre comme 1Password que l'on puisse auto-héberger ?

        • [^] # Re: Dropbox

          Posté par . Évalué à 4.

          Rien de pleinement satisfaisant à mon goût.

          En appli bureau, la référence c’est KeepassX. Mais il s’intègre très mal avec le reste du monde, en particulier le navigateur, et c’est un fichier sur le disque, donc pas accessible de partout à moins de mettre en place une synchro avec un serveur web (ou un dropbox) à la main.

          En appli Web, la référence c’est plutôt Teampass. Son interface est vraiment pourrie, il ne s’intègre pas dans le navigateur, et il ne chiffre pas les mots de passe dans tous les cas (et c’est pas vraiment clairement affiché/documenté quand il chiffre ou pas).

          En moins connu mais supérieur à Teampass (AMHA), tu as gPass et (attention, auto-promotion éhontée) WKR. Dans les deux cas c’est stocké côté serveur, chiffré, et avec intégration dans le navigateur possible (extension Chrome/FF pour gPass, Greasemonkey pour WKR). Par contre t’as pas d’appli desktop à la 1Password.

          • [^] # Re: Dropbox

            Posté par . Évalué à 0.

            Je dirais que la référence c'est plutôt keepass. Je parle là de la version 2 utilisant les fichiers kdbx (format xml), qui est plus flexible que la version 1 (fichiers kdb binaires). La version 2 de keepassx supportant les fichiers kdbx est très récente et pas aussi avancée que keepass 2.
            Son seul inconvénient me semble être la dépendance à mono sous linux et osx. En contrepartie, le même exécutable fonctionne partout. Pratique, sur une clé usb.

            Il a des fonctionnalités très utiles qui ne sont pas inclues dans keepassx :
            - synchronisation de fichiers
            - plugins ! Pour ma part j'utilise KeeCloud pour synchroniser sur dropbox sans utiliser de client dropbox et KeeAgent (agent d'authentification ssh).
            - système de triggers, qui permet par exemple de synchroniser sur dropbox à chaque enregistrement.

            En termes de sécurité, keepass est aussi plus avancé.

            À noter aussi, le projet keeweb (web app pour les fichiers kdbx) très jeune mais qui semble prometteur. Les fichiers sont hébergés en local ou sur dropbox.

  • # Git + keepassx

    Posté par . Évalué à 4. Dernière modification le 26/01/16 à 09:32.

    Ma solution: un git privé qui partage qq fichiers dont un fichier keepassx protégé par une masterkey.

    Inconvénients:
    - Bien sûr, les mécanismes de merge de git sont sans intérêt sur un fichier chiffré: penser à bien synchroniser avant et après chaque modif.
    - Git se fout des droits (lecture pour tout le monde): bien penser à protéger les répertoires en amont en cas d'attaque locale
    - Il me faut un serveur accessible 24/7

    Intérêts:
    - J'utilise déjà pas mal Git pour de la synchro/sauvegarde, du coup pas un outil de plus à maintenir
    - J'ai relativement confiance en Git pour la sécurité. Au pire, si mon Git est compromis, il me reste la masterkey.
    - Même si le diff n'a aucun sens sur ma base de mots de passes, je bénéficie quand même de la possibilité de remonter une ancienne version de mes mots de passe (y compris si mon dépot local si l'origin n'est pas accessible).
    - Je ne pose pas mes données sensibles sur la machine de quelqu'un d'autre.

    ps: Comme notifié plus haut, keepass, c'est pas un champion de l'intégration automatique dans toutes les applis. Mais en pratique, ça ne me gêne pas trop (surtout des pass web et des accès via SSH avec des authorized key (pas besoin du pass)).

    • [^] # Re: Git + keepassx

      Posté par . Évalué à 1.

      Pour l'interaction Web/Keepass, il existe Keefox, un module firefox pour s'interfacer avec Keepass. Je n'ai jamais essayé.

      PS: Je me réponds parce que je ne peux plus modifier le post: j'ai un joli logo de Gandalf qui m'interdit de passer en me prenant pour un Balrog alors que le bouton "Modifier" est présent. On a une limite du nombre de modifs / unité de temps sous LinuxFr?

  • # pour moi

    Posté par . Évalué à 2.

    Perso, j'utilise Keepass et Dropbox.
    Le coté Dropbox n'est pas le plus sécurisant philosophiquement mais c'est le plus pratique que j'ai trouvé.
    Car j'ai la synchro sur plusieurs PCs et sur mon téléphone et ça marche très bien en faisant de la synchro dans tous les sens.

    Je n'ai pas retesté depuis avec hubic mais à l'époque le client de synchro était pas top.
    Je pense qu’aujourd’hui la maturité est bien meilleure.
    Si l'on considère OVH comme plus sécuritaire car pas au US cela me parait une bonne alternative.

    Peu importe le cloud qui héberge (même owncloud aurait pu faire l'affaire) le tout pour moi est la facilité et fiabilité d'utilisation.
    La sécurité étant assurée principalement par le gestionnaire de mot de passe et mon mot de passe unique suffisamment fort.

  • # SuperGenPass

    Posté par . Évalué à 3. Dernière modification le 26/01/16 à 11:18.

    J'aime vraiment pas l'idée d'avoir des mots de passes tellement nombreux/complexes/variés qu'il faut les écrire quelque part.

    Alors je me tente une migration vers SuperGenPass.

    Pour ceux qui connaissent pas, l'idée est d'avoir un mot de passe (plusieurs si ça vous chante, c'est un détail) commun entre les sites. Mais un algo "sale" le mot de passe avec l'URL du site. Ainsi, chaque site a un mot de passe unique, et qui ne permet pas de rmeonter au mot de passe original.

    Exemple : j'ai le mot de passe "jaimelatartiflette" commun à tous les sites. Appliqué au site "linuxfr.org", ça donne : x3PMxKe0AV

    linuxfr.org ne verra donc comme mot de passe que x3PMxKe0AV. Si il a la mauvaise idée de le stocker en clair et qu'il se fait hacker, pas de pb, on n'ira pas avec ce mot de passe sur mon compte mail ni sur PayPal.

    SGP existe principalement sous forme d'une applet java qu'on bookmarke (très pratique: elle remplit l'URL automatiquement, et une fois le mot de passe généré, elle sait remplir automatiquement le formulaire) qui garantit que tous les calculs sont fait en local, mais aussi application Android etc. De toutes façons l'algo est ouvert : https://github.com/chriszarate/supergenpass

    Utilisez-vous ça ? Trouvez-vous des inconvénients ?

    Je suis en train de migrer, je veux pas partir sur une solution bancal.

    • [^] # Re: SuperGenPass

      Posté par . Évalué à 0.

      C'est une bonne idée à la condition que l'information sur le fait que tu utilises supergenpass reste secrète.

      Nous sommes là dans un cas de sécurité par l'obscurité.

      Essayons d'évaluer qui pourrait être au courant de cette information.
      - Ton FAI qui ont accès à ton historique, donc potentiellement l'ensemble des services de polices/espionnage…
      - Utilise-tu un smartphone ? Si oui, quelques applications pourraient avoir accès à cette information.
      - Les lecteurs de linuxfr. Ben oui, tu viens de nous le dire :-)

      Ca commence à en faire du monde.

      Mais c'est un peu mieux que de mettre le même mot de passe partout, mais pas beaucoup.

      • [^] # Re: SuperGenPass

        Posté par . Évalué à 1.

        | C'est une bonne idée à la condition que l'information sur le fait que tu utilises supergenpass reste secrète.

        Non, c'est pas juste un hachage du nom du site : c'est un chiffrement du nom du site avec une clé (commune à tous les sites) si j'ai bien compris les explications. Tant qu'ils n'ont pas la clé, l'algo ne suffit pas.

        • [^] # Re: SuperGenPass

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

          Non, c'est pas juste un hachage du nom du site : c'est un chiffrement du nom du site avec une clé (commune à tous les sites)

          C’est une condensation ré-itérée x fois (avec x = 10 par défaut) d’un mot de passe principal suivi du nom du site. Rien à voir avec un chiffrement.

          C’est plus ou moins analogue à un HMAC, à ceci près que la clé est ici le mot de passe principal de l’utilisateur, qui à presque tous les coups ne fournit pas une sécurité suffisante (comparé par exemple à une clef aléatoire de 128 bits).

          Tant qu'ils n'ont pas la clé, l'algo ne suffit pas.

          Le problème est que la « clé » n’est pas si difficile que ça à retrouver (sauf si le mot de passe est très complexe). Pas forcément à la portée du premier venu, mais rien de comparable avec la difficulté de craquer un chiffrement digne de ce nom.

          • [^] # Re: SuperGenPass

            Posté par . Évalué à 3.

            Merci pour les infos:

            J'ai mal utilisé le terme chiffrement: je pensais à une injection de clé, avec en plus un "key streching" (désolé, pas d'idée de traduction) histoire d'augmenter l'entropie et de ralentir le hachage (pas besoin de vitesse en utilisation normale dans ce cas) pour limiter le bruteforce, le tout itéré avec une bonne fonction de hachage (Keccak?). C'est un peu ce que tu décris, sauf qu'il y a peu d'itérations (10 me semble bien faible mais c'est bien leur défaut, tu as raison!) et que, par défaut, ils se contentent d'un hash MD5 (voir leur code) alors qu'ils utilisent crypto-js qui supporte du sha3 (donc du Kekkac).

            Dommage, je trouvais l'idée sympa. Enfin, ça reste toujours mieux que du mot de passe identique partout…

            Sinon, qq'un a une idée de comment le navigateur assure qu'un "processus" (pas au sens système) javascript ne peut jamais accéder à la mémoire d'un autre "processus"? C'est threadé et laissé à l'OS? Je pensais au mot de passe maître qui réside en mémoire et ça ne m'inspire pas confiance (à tort?).

            • [^] # Re: SuperGenPass

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

              le tout itéré avec une bonne fonction de hachage (Keccak?)

              Le problème avec les fonctions de hachage, même les bonnes comme Keccak, est qu’elles sont conçues (entre autres) pour être rapides, ce qui n’est pas idéal pour ce genre d’utilisation.

              Ici, on a besoin au contraire d’une fonction « lente ». S’il fallait, par exemple, 100 ms pour hacher le mot de passe maître, ça n’aurait pas beaucoup d’impact pour l’utilisateur en conditions normales (100 ms, c’est suffisamment rapide pour que l’utilisateur perçoive à peine le délai), mais ça rendrait la recherche exhaustive beaucoup plus coûteuse pour l’attaquant.

              Et mieux encore, il faudrait une fonction coûteuse en temps et en mémoire. Des fonctions comme scrypt ou Argon2, spécialement conçues pour le « hachage » de mot de passe.

              Exécuter n fois une fonction de condensation sur un mot de passe est un « hack », qu’on devrait laisser de côté maintenant qu’on a des fonctions étudiées pour.

    • [^] # Re: SuperGenPass

      Posté par . Évalué à 4.

      hash("pass:domaine.tld")
      Un hash ça reste un hash. Si tu connais la méthode de hash utilisée et que t'as le resultat, tu peux faire un brute force pour avoir la valeur d'entrée.
      T'as juste a brute forcer uniquement sur la partie "pass", tu connais déjà la fin qui est le tld: Une fois pass trouvé, t'as les mots de passe pour tous les autres tls que tu veux.

      On recommande un mot de passe différent par site, et ici c'est l'effet contraire.

    • [^] # Re: SuperGenPass

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

      Trouvez-vous des inconvénients ?

      « Attention, paranoïaque en approche à 11 heures ! Feu à volonté ! »

      Ahem.

      Un (rapide, certes) coup d’œil au code ne m’inspire pas beaucoup confiance. Deux petites choses me gènent particulièrement.

      D’abord, même si l’auteur met en avant le fait qu’il s’agisse d’un bookmarklet qui s’exécute localement, je vois que le code télécharge une version de jQuery depuis les serveurs de Google. Donc, même si j’installe le bookmarklet une fois pour toute (après avoir vérifié qu’il fait bien ce qu’il est censé faire), a priori chaque fois que je l’exécute je récupère un bout de code arbitraire depuis l’Internet. Merci, sans façon.

      Ensuite, j’ai de grosses réserves sur l’algorithme de génération de mots de passe. Par défaut, c’est simplement une concaténation du mot de passe « maître » et de l’URL du site cible, passé dix fois de suite à la moulinette de MD5.

      La fonction MD5 est à mon avis beaucoup trop faible pour être encore utilisée de cette façon. Faire dix passages au lieu d’un seul n’y change pas grand’chose. Pour peu que le mot de passe maître ne soit pas suffisamment complexe, quelqu’un qui sait que tu génères tes mots de passe de cette façon pourrait probablement remonter jusqu’au mot de passe maître (et là, c’est jackpot, il connaît tous tes mots de passes pour tous les sites que tu visites).

      Il est possible d’utiliser SHA512 au lieu de MD5, ce qui est certes nettement mieux mais ce n’est toujours pas une fonction appropriée pour ce genre de tâche.

      • [^] # Re: SuperGenPass

        Posté par . Évalué à 1.

        Arg. J'aurais du relire tout le thread avant de répondre :)
        On a les mêmes inquiétudes…

    • [^] # Re: SuperGenPass

      Posté par . Évalué à 4.

      Merci pour vos retours, mais je comprends pas trop les contre arguments. J'essaie surtout de comprendre, je ne suis pas particulièrement partisan de quel camp que ce soit.

      • Il suffit de brute forcer : merci, mais pour n'importe quel site il "suffit" de brute forcer. Je ne vois pas en quoi ça change ce paramètre. Au passage, il est plus facile d'utiliser un mot de passe de 20 caractères unique avec SGP, que avoir des mots de passe de 20 caractères sur chaque site
      • MD5 est trop faible. Trop faible pour quoi ? Je te donne un hash MD5, on n'est toujours pas capable de créer le contenu correspondant sur commande
      • Si on craque le mot de passe, on a accès à tout : de ce que je vois, vous stockez vos mots de passe qque part. Si je craque cet accès j'ai donc également accès à tous les mots de passe.

      Par contre je vois quelque chose de vos retours : SGP va nécessairement avec un mot de passe fort, très fort, voire très très fort :D

      • [^] # Re: SuperGenPass

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

        Il suffit de brute forcer : merci, mais pour n'importe quel site il "suffit" de brute forcer. Je ne vois pas en quoi ça change ce paramètre.

        Si l’attaquant sait que tu utilises SGP, il lui suffit de craquer un seul des mots de passe générés pour retrouver ton mot de passe maître, et à partir de là obtenir les mots de passe pour tous les sites.

        MD5 est trop faible. Trop faible pour quoi ? Je te donne un hash MD5, on n'est toujours pas capable de créer le contenu correspondant sur commande

        Nul besoin d’inverser la fonction de condensation si

        • le mot de passe est trop faible, et
        • l’attaquant peut tester rapidement toutes les combinaisons.

        Ma pauvre machine de bureau est capable, sans forcer (pas d’utilisation de plusieurs cœurs, du GPU, ou d’autres optimisations de ce genre) de calculer environ dix millions de MD5 par seconde.

        Note que même un mot de passe d’apparence complexe peut être « faible » s’il est dans un dictionnaire, ou s’il peut être construit à partir d’un dictionnaire.

        Ce n’est pas une faiblesse propre à MD5. Comme je le disais plus haut, toutes les fonctions de condensation conçues pour être rapide ont le même problème (SHA-512 ? Je peux en calculer environ six millions par seconde, les doigts dans le nez). C’est pour ça qu’elles ne sont pas adaptées à la condensation de mots de passe.

        Si on craque le mot de passe, on a accès à tout : de ce que je vois, vous stockez vos mots de passe qque part. Si je craque cet accès j'ai donc également accès à tous les mots de passe.

        Pas comparable.

        Dans ton cas, il suffit à l’attaquant d’obtenir un seul de tes mots de passe (de quelque façon que ce soit : via un keylogger sur ta machine, en sniffant le réseau — il y a encore des sites dont les formulaires de login ne sont pas protégés par TLS… —, en obtenant un dump de la base de données d’un site — non, je ne suis pas parano, renseignez-vous, il ne se passe pas une semaine sans qu’un site ne se fasse pas pirater sa BD —, etc.) pour pouvoir ensuite tenter de le craquer à loisir, totalement « offline », en y mettant autant de ressources que possible et sans que tu ne te doutes rien.

        De mon côté (avec un fichier de mots de passe chiffré par GnuPG, mais ce serait à peu près pareil avec un gestionnaire de mots de passe comme KeePassX ou assimilé), si l’attaquant obtient un de mes mots de passe, ben… il a un de mes mots de passe. Chouette pour lui mais ça ne lui permettra jamais d’obtenir les autres.

        S’il veut tous mes mots de passe, il lui faut impérativement mettre la main sur mon fichier de mots de passe, et casser la protection dudit fichier¹. Pas impossible certes, mais la grosse différence par rapport à ton schéma est que l’attaquant n’a plus le choix du point d’attaque. Il doit s’en prendre à ma machine, il ne peut pas choisir de sniffer un point quelconque du réseau ou s’en prendre à un site mal protégé.


        ¹ Ce qui chez moi implique de devoir

        • casser la clef AES protégeant le fichier lui-même, ou
        • factoriser ma clef OpenPGP publique (la voilà, si tu veux essayer), ou
        • obtenir ma clef OpenPGP privée et casser la phrase de passe qui la protège.
        • [^] # Re: SuperGenPass

          Posté par (page perso) . Évalué à 3. Dernière modification le 28/01/16 à 19:09.

          Pour enfoncer le clou (et peut-être être plus clair), les deux gros points faibles du principe de SGP sont :

          • le fait que tous les mots de passe générés soient liés entre eux (en craquer un seul fait tomber tous les autres) ;
          • le fait que c’est, indirectement (via la fonction de condensation), le mot de passe maître qui se retrouve sur le réseau et sur les sites visités.
        • [^] # Re: SuperGenPass

          Posté par . Évalué à 2.

          Dans ton cas, il suffit à l’attaquant d’obtenir un seul de tes mots de passe

          C'est là que je comprends pas.

          Exemple : sur linuxfr.org, mon mot de passe est xFe8q0Lksf. Si d'une manière quelconque tu arrives à le choper, ok, tu as donc accès à linuxfr.org. Mais pour aller sur un autre site, il va te falloir retrouver mon master password.

          Et tu me dis qu'à coup de qques millions de tentatives par secondes tu vas arriver à retrouver mon master password "facilement" ?

          C'est là que tout se joue je pense. SI c'est réellement le cas, en effet, SGP ne sert strictement à rien. On peut calculer une espérance théorique ? Concrètement, ça prend 1h ou 1 million d'années à le trouver ?

          • [^] # Re: SuperGenPass

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

            Mais pour aller sur un autre site, il va te falloir retrouver mon master password.

            Oui, et le problème est que c’est possible, vu que ton mot de passe pour linuxfr.org est directement dérivé de ton master password.

            Je ne dis pas que c’est facile (ça peut même être tellement difficile que ça cera, concrètement, infaisable si ton mot de passe maître est suffisamment complexe), mais c’est possible.

            Et tu me dis qu'à coup de qques millions de tentatives par secondes tu vas arriver à retrouver mon master password "facilement" ?

            S’il est trop simple ou s’il est dans un dictionnaire, oui, définitivement.

            Il faut noter qu’un « dictionnaire », aujourd’hui, ce n’est plus une simple liste de mots sortis d’un « Robert » ou d’un « Larousse » (ou de /usr/share/dict). les craqueurs élaborent aujourd’hui des dictionnaires très riches, alimentés notamment par de vrais mots de passe issus des innombrables bases de données de sites piratés (par exemple, le dictionnaire utilisé pour craquer les mots de passe de LinkedIn comportait plus de 500 millions de mots et a permis de retrouver des mots de passe de plus de vingt caractères).

            On peut calculer une espérance théorique ? Concrètement, ça prend 1h ou 1 million d'années à le trouver ?

            Dis-moi quel est ton mot de passe, je te dirai s’il est suffisamment fort. :D

            Plus sérieusement, c’est justement parce que je ne peux pas répondre à cette question que je préfère éviter d’utiliser une méthode où la sécurité de tous mes mots de passe dépend de la réponse à cette question…

            • [^] # Re: SuperGenPass

              Posté par . Évalué à 2.

              Ok, donc ça me conforte dans ce que j'ai appris de vos remarques : le master password doit être un mot de passe fort. Quand je dis fort, c'est style 20 caractères.

              Le mien actuel est pas ridicule (strictement aucun rapport avec le dictionnaire, mais seulement 8 caractères).

              Bon, je le note… et je change mes passwords :)

              • [^] # Re: SuperGenPass

                Posté par (page perso) . Évalué à 2. Dernière modification le 31/01/16 à 21:02.

                Le mien actuel est pas ridicule (strictement aucun rapport avec le dictionnaire, mais seulement 8 caractères).

                Désolé, mais 8 caractères, aujourd’hui, c’est ridicule.

                Dans le meilleur des cas (utilisation de lettres minuscules et majuscules, de chiffres, et plus généralement de toute la plage de caractères ASCII imprimables), il y 895 = 6 634 204 312 890 625 combinaisons à tester.

                C’est certes hors de portée de ma machine (il me faudrait environ 21 ans), mais largement à la portée de beaucoup trop de monde (en gros, quiconque peut investir dans quelques cartes graphiques) pour que je sois à l’aise.

                Je dirais que 12 caractères, c’est vraiment le strict minimum de nos jours. Et pour un « master password » dont dérivent tous les autres, je pense que je ne descendrai pas en-deçà de 18.

                • [^] # Re: SuperGenPass

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

                  il y 895 = 6 634 204 312 890 625 combinaisons à tester.

                  J’ai écrit ça trop vite, grossière erreur, c’est 958 combinaisons, pas 895…

  • # À l'ancienne

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

    Sur une feuille cachée sous le matelas, entre deux magazines coquins.

  • # Algo en tête maison

    Posté par . Évalué à 2.

    Depuis que j'utilise un algo en tête maison plus de soucis. C'est à dire un petit algo perso qui transforme le nom du service en un mot de passe, par exemple la première lettre + 1, la deuxième + 2, le nombre de lettre x l'année de naissance de ma fille etc…
    Pour les cas un peu particulier où ça ne marche pas directement (pas assez de lettre ou autre) je l'écris sur un fichier qui lui n'a aucun besoin d'être crypté.
    Pour les mots de passes ou codes que je ne peux pas modifier moi-même, je les écris avec une erreur. Par exemple si c'est un numéro j'inverse systématiquement le premier et le dernier caractère ou je lui ajoute mon année de naissance etc… Donc là aussi ça permet de l'écrire n'importe où.
    N'importe où c'est généralement un fichier qui n'a l'air de rien genre test.py dans un répertoire build par ex.

  • # dans ton c ?

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

    dsl…
    -> []

  • # Vive le mail

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

    Je stocke mes mots de passe sous forme de messages cryptés dans un répertoire de ma boite mail. J'ai rarement besoin d'être mobile mais si le besoin s'en faisait sentir, un petit coup de gpg + imap pourrait résoudre le problème.

    Comme quoi les vieux trucs, ça marche très bien.

    • [^] # Re: Vive le mail

      Posté par . Évalué à 3.

      J'ai toujours adoré les solutions comme celle-ci basées sur Imap. Malheureusement, ça ne courent pas les rues.

      Imap est parfait/assez courant/suffisant pour stocker et rendre accessible de petites informations comme celle-ci.

  • # Cryptographie, mon oeil !

    Posté par . Évalué à -7.

    Bonjour,

    Bon, en gros, si je comprends bien, vivement la reconnaissance oculaire, faciale, et testiculaire, pour échapper à nos futurs terroristes/gouvernements tout plein méchants qui n'en veulent qu'à nos données personnelles, qui, si elles étaient connues, renverseraient d'elles-mêmes une bonne partie de l'Univers pas très bien étoilée.

    Et ben, "Ils" ont raison de se faire du souci, rien qu'en les regardant en face, on va bientôt "les" renverser.

    Ouf, vive les dernières technologies !

    E-Gwen.

    • [^] # Re: Cryptographie, mon oeil !

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

      Bon, en gros, si je comprends bien, vivement la reconnaissance oculaire, faciale, et testiculaire,

      Si j'en crois les films y en a qui coupent le doigt/la main pour outrepasser la reconnaissance digitale (j'aurais sûrement dû dire reconnaissance d'empreintes mais j'avais envie de caser digital à un endroit justifié pour une fois), alors non pas vivement.

  • # Dans une clef USB

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

    Pour ma part, je viens tout juste de mettre en place un gestionnaire de mot de passe sur ma machine qui va sans doute me permettre d'avoir des mots de passe un peu plus sécurisés. J'utilise pass pour cela. Il stocke les mots de passe en chiffré via une clef GPG. Pour partager ces mots de passe entre mes différents ordinateurs, je mets le tout sur une clef USB, avec la clef GPG que j'utilise exclusivement pour mes mots de passe.

    Et je ne vais certainement pas mettre le tout sur Internet. Pas une seule seconde.

    Après, si tu préfères passer par le réseau, tu fais un joli scp :)

    • [^] # Re: Dans une clef USB

      Posté par . Évalué à 3.

      Wai. Gare à la sauvegarde quand même. Une clef USB, ça se casse, ça se petitsuicide, ça se perd.
      Donc en confidentialité, voir en intégrité, c'est plutôt bien, mais en dispo, c'est pas terrible.

Suivre le flux des commentaires

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