Bonjour à tous,
Récemment j'ai eu l'envie d'écrire un gestionnaire de mot de passe. Les gestionnaires existants sur le marché ne me convenant pas (et aussi ayant envie d'écrire le mien).
Le gestionnaire de mots de passe est relativement simple. On peut créer un utilisateur avec son mot de passe et tous les enregistrements (mot de passe, carte bancaire, autres) sont enregistrés cryptés.
L'application (le client, et le serveur) est écrite en javascript et propose une API REST (afin de pouvoir écrire une application Android par la suite).
Une clé maître est utilisée pour chiffrer les mots de passe (à l'aide de la méthode AES-256-CTR). Cette clé est elle-même chiffrée avec le mot de passe de l'utilisateur et le sel, ainsi seul l'utilisateur peut dévérouiller ses propres données.
Le chiffrage et le déchiffrage est fait côté serveur pour des raisons de performances. Cela nécessite d'avoir un minimum de confiance au serveur et d'avoir une connection HTTPS. C'est pas grave, le serveur peut être auto-hebergé.
Un peu plus d'explication par ici et vous pouvez tester l'application ici et enfin les sources.
Que pensez-vous de ce projet ? De son utilité ? De sa sécurité ?
Merci
# Correction
Posté par ptit_poulet . Évalué à 8.
Chiffrement/déchiffrement et non chiffrage/déchiffrage ;)
[^] # Re: Correction
Posté par RyDroid . Évalué à 10.
Il faut aussi remplacer crypter par chiffrer. http://www.bortzmeyer.org/cryptage-n-existe-pas.html https://chiffrer.info/
[^] # Re: Correction
Posté par n0wic . Évalué à -10.
Et la science de chiffrer c'est la chiffrologie :)
# Performances
Posté par GG (site web personnel) . Évalué à 10.
Je ne comprends pas pourquoi les opérations de chiffrements et de déchiffrements sont effectués côté serveur?
Soit disant pour des raisons de performances.
Les smartphones de nos jours sont très puissants.
Mon smartphone, vieux de 5 ans, est plus puissant que 3 de mes serveurs par exemple.
Et, la nécessité d'avoir une connexion vers un serveur va poser problème dans certains pays, comme la Chine, où les connexions à des serveurs étrangers sont souvent aléatoires.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Performances
Posté par phoenix (site web personnel) . Évalué à 2.
Par rapport à la question des performances, la librairies crypto de nodejs est écris en C si je ne me trompe.
Si le chiffrement et déchiffrement est fait coté navigateur, la librairies devra être écrite en JavaScript. Ce qui risque d'être beaucoup moins performant. J'avoue je n'ai pas fais de test de performance. Mon téléphone étant un haut de gamme, il est très puissant, et mon PC étant lui aussi relativement puissant. Je me suis dit que hébergé chez moi cela ne posera pas de problème.
De plus pour le coté besoin d'un serveur WEB, actuellement l'application ne gère pas de mode offline (C'est une web application / single page app). Elle pourrait gérer le mode offline, mais actuellement même si le chiffrement/déchiffrement était fait coté client, l'application aurait tout de même besoin de télécharger les éléments du serveur.
Par contre je compte écrire une application android qui se synchroniserai avec le serveur et permettrai de sauvegarder les mots de passe offline. Sur cette application je pourrais envisager de faire le chiffrage coté application.
Mon but est de pouvoir regarder mes mots de passes de n'importe où, que j'ai ou non mon téléphone sur moi. D'où l'idée d'un client léger (application web) et non d'un client lourd qu'il faut installer.
Je regarderai quand même à l'occasion quels sont les performances des librairies cryptographiques coté navigateur (donc en javascript) pour me faire une idée des performances et voir si je ne peux pas faire le chiffrement coté client uniquement, ou optionellement.
[^] # Re: Performances
Posté par phoenix (site web personnel) . Évalué à 3.
Je viens de faire un simple benchmark (sur mon PC i7 à 3.60GHz) :
Pour effectuer un chiffrement d'une chaîne de caractère depuis nodejs avec la lib crypto il faut 0,13896 ms
Le même benchmark depuis le navigateur me donne 5.685ms, soit 40x plus lent.
Bon 5ms pour une opération c'est raisonnable sur un navigateur. Il faudrait que je fasse le même test navigateur sur un navigateur mobile d'un mobile bas de gamme.
[^] # Re: Performances
Posté par n0wic . Évalué à -10.
S'agit il de Openssl ?
[^] # Re: Performances
Posté par phoenix (site web personnel) . Évalué à 2.
La lib crypto de nodejs coté serveur est basé sur openssl.
Par contre, si je ne me trompe, la lib crypto utilisable coté navigateur et une réécriture en full-javascript.
[^] # Re: Performances
Posté par ckiller . Évalué à 3.
5ms c'est largement acceptable, même 1 seconde ca reste acceptable, surtout quand ca assure un surcroit de sécurité qui est de ne pas faire totalement confiance au serveur, ni au réseau de transport.
[^] # Re: Performances
Posté par Larry Cow . Évalué à 5.
Faut quand même leur faire confiance pour t'envoyer le bon code JS, non?
[^] # Re: Performances
Posté par jigso . Évalué à 3.
Regarde du coté de clipperz : tout est chiffré coté serveur, et le déchiffrement se fait coté navigateur avec une lib js. Et ça reste acceptable en temps d'execution.
# Crypto pas crypto
Posté par Aeris (site web personnel) . Évalué à 8. Dernière modification le 03 octobre 2016 à 10:41.
Hello !
J’ai regardé rapidement ta crypto, elle n’est pas correcte du tout (key/iv reusage, password as key, no HMAC…) :P
Je vais t’ouvrir tout plein de petits tickets sur Bitbucket du coup.
Cf https://blog.imirhil.fr/2016/03/03/chiffrement-donnees.html
[^] # Re: Crypto pas crypto
Posté par phoenix (site web personnel) . Évalué à 1.
Pas de soucis pour faire des rapports de bug.
Je ne suis malheureusement pas cryptolog.
De ce que je comprend l'un des problèmes est que je me sert de la clé maître pour chiffrer tout les mots de passes. Si chaque mots de passe à sa clé et son IV, je ne vais pas stocker en claire ces derniers. Il faut donc que je l'ai chiffre à leur tour. Et si je les chiffres avec la clé maître, je retombe sur le même problème.
Du coup comment faire ?
La clé maitre est quant à elle chiffrer en effet avec le mot de passe. Du coup que proposes-tu ? Chiffrer la clé maitre avec un hash du mot de passe ?
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . Évalué à 4. Dernière modification le 03 octobre 2016 à 13:04.
En théorie, tu n’as même pas besoin de clef maître, puisque tu pourrais la baser sur le mot de passe via une dérivation de clef.
Tu en as besoin en pratique pour permettre le changement de mot de passe et d’éviter de le stocker au login.
La subtilité est d’arriver à obtenir une clef et un iv (même si c’est moins grave pour le 2nd) unique pour chaque chiffrement à réaliser. Réutiliser une clef de chiffrement est une erreur grave en crypto (on est potentiellement capable de deviner des choses sur les textes en clair à partir des données chiffrées uniquement).
À la création de l’utilisateur :
Au login utilisateur :
Pour chiffrer une donnée :
Pour déchiffrer une donnée :
[^] # Re: Crypto pas crypto
Posté par syl . Évalué à 1.
Réutiliser une clé n'est pas une erreur grave, tant que le service est le même (par exemple, une clé utilisée pour chiffrer toutes les autres).
Par contre réutiliser un IV est une erreur grave. Tous les couples (clé,IV) doivent être différents. On peut donc utiliser une IV I une fois avec la clé K1 et une fois avec la clé K2 mais jamais deux fois avec la même clé.
Une autre chose importante : toujours utiliser un chiffrement intègre. Par exemple CBC + HMAC, ou mieux un mode combiné comme CCM ou GCM. Attention cependant dans le premier cas (utilisation d'un mode de confidentialité et un mode d'intégrité) : les clés doivent être différentes (services différents), et l'intégrité doit être calculée sur le chiffré, et non sur le clair.
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . Évalué à 1. Dernière modification le 03 octobre 2016 à 14:28.
C’est complètement faux. Et c’est même l’inverse.
L’IV peut être une donnée publique (qu’on peut par exemple générer de la même manière qu’un sel) et peut être réutilisée sans problème tant qu’on changera la clef de chiffrement (c’est le couple clef+iv qui doit être unique lors du chiffrement).
C’est juste emmerder encore plus un attaquant que de le générer via un moyen cryptographique sûr et de ne pas le communiquer (clef de 256 bits + iv privé de 256 bits peut donner jusqu’à 512 bits de sécurité totale si ils sont générés de manière indépendante).
La clef de chiffrement, elle, doit bien être unique, d’autant plus que certains algos ne nécessitent pas d’IV (RC4, le mode ECB ou CTR de AES, …).
Ça évite en prime de voir l’intégralité des messages qui tombent en cas de compromission de la clef unique (d’autant plus si l’IV est public).
La règle générale est donc clef à usage unique par défaut.
Et tu ne réutilises jamais une clef, sauf à RÉELLEMENT savoir ce que tu fais (et même dans ce cas, ne la réutilise pas, la probabilité est importante que tu ais raté quelque chose dans ton étude).
[^] # Re: Crypto pas crypto
Posté par Moonz . Évalué à 3.
Si si, il y a bien un IV dans CTR : https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_.28CTR.29
Je vois pas ce que ça change. Dans ton schéma plus haut, si MK tombe tes clés uniques tombent aussi.
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . Évalué à 2.
Ah oui, j’avais zappé le nounce effectivement /o\
Oui, mais à la différence d’une clef réutilisée, elle n’a pas vocation à être transporté sur le réseau, de manière directe ou indirecte (via un chiffré).
Ça la rend beaucoup plus robuste en pratique (des attaques ne sont plus possibles, comme une attaque en known-plain-text ou une par oracle par exemple).
Il y a donc un gros fossé en terme de robustesse entre une clef maîtresse réutilisé (inaccessible sans hack de la bdd) et une clef secondaire réutilisée (accessible au moins indirectement par les chiffrés).
[^] # Re: Crypto pas crypto
Posté par syl . Évalué à 2.
Merci. Ça fait plus de 10 ans que je travaille dans le domaine, il va donc me falloir tout revoir à la base :)
Où ai-je dis l'inverse ? Par définition il est publique puisqu'il est nécessaire pour déchiffrer. Il doit donc être transmis sur la ligne avec le message (dans le cas général, ici il n'y a pas de ligne puisque l'on protège des mots de passe).
C'est bien ce que j'ai dit ci-dessus.
Effectivement, on peut parler de vieux algorithmes (RC4) ou encore de modes à bannir (ECB)…
Plus sérieusement, la même clé peut être utilisée pour chiffrer différent messages tant que l'IV pour un message donné n'a pas déjà été utilisé par un autre message chiffré avec la même clé.
Cela signifie donc que TLS, IPsec et la plupart des protocoles de sécurité ne sont pas sûr, c'est bien ça ?
Parce que ces protocoles chiffrent bien plusieurs messages avec la même clé, qui est mise à jour régulièrement mais pas à chaque message. Par exemple, IPsec permet de chiffrer jusqu'à 264 messages avec la même clé. Et cette borne est sûre.
[^] # Re: Crypto pas crypto
Posté par syl . Évalué à 2.
Oups, je préfère préciser : cette borne est sûre avec des algorithmes et des modes à l'état de l'art (AES-CBC + HMAC-SHA256 ou AES-CCM, par exemple).
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . Évalué à 2. Dernière modification le 03 octobre 2016 à 21:49.
Tout à fait. C’est même pour ça qu’on a inventé PFS et qu’on demande de faire TRÈS attention à ses configurations IPSec.
Et encore, même en version de base non PFS de TLS, la clef privée ne sert qu’à s’assurer de l’identité de la machine, une clef de session unique est négociée lors du handshake et est utilisée par la suite lors du chiffrement.
PFS a justement fait en plus en sorte que cette clef de session ne soit pas chiffrée par la clef privée mais par une nouvelle clef de session unique négociée de manière fiable par un protocole à 0 knowledge (DHE ou ECDHE).
Pas nécessaire de le transmettre. Il peut être recalculé au déchiffrement, par exemple par une dérivation PBKDF2.
[^] # Re: Crypto pas crypto
Posté par syl . Évalué à 1.
Je répond rapidement et dans le désordre.
IPsec c'est du pur symétrique. Pour la PFS, il faut de l'asymétrique (un échange Diffie-Hellman en l'occurence).
En ce qui concerne les clés IPsec, la PFS est apportée par IKE qui permet de négocier et mettre à jour les clés IPsec (quoiqu'une gestion manuelle est possible, bien qu'hardue). Il n'empêche qu'entre deux négociations IKE, plusieurs messages sont chiffrés avec la même clé dans une SA IPsec.
La clé privée ne chiffre rien du tout : DH et ses variantes sont des protocoles pour se mettre d'accord sur un secret commun. J'ai l'impression que tu mélanges un peu tout.
Ceci est mon dernier message sur le sujet, vu que ça commence à partir dans tous les sens.
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . Évalué à 0. Dernière modification le 04 octobre 2016 à 00:27.
Pas quand on utilise un algo non PFS.
Dans le cas du non PFS (donc sans DHE ni ECDHE), le client et le serveur s’échange un nounce random, l’un des 2 en déduit une pre-master-key (généralement le client) qui est chiffré avec la clef publique de l’autre et est envoyé sur le réseau.
Le récepteur déchiffre cette pre-master-key avec sa clef privée, et les 2 peuvent alors calculer la master-key de session à partir de cette pre-master-key commune (l’un des côtés l’a calculé, l’autre l’a recu).
Sans PFS
Avec PFS
Ça a été tout le drame de Heartbleed et du key reusage : si la NSA a intercepté et stocké l’intégralité des communications entre X clients et un serveur, l’accès à la clef privée du serveur via Heartbleed leurs permettait alors de déchiffrer toutes les pre-master-key et d’en déduire les clefs de session permettant de déchiffrer tout le reste de toutes les communications.
Ce n’est plus du tout le cas avec PFS puisque cette pre-master-key ne circule pas sur le réseau mais est calculée des 2 côtés via un mécanisme en 0-knowledge (Diffie Hellman en version nombre premier pour DHE ou courbe elliptique pour ECDHE).
Et la NSA doit alors casser chaque clef de session indépendament les unes des autres, il n’y a plus de moyen de les casser toutes en une seul fois.
[^] # Re: Crypto pas crypto
Posté par Moonz . Évalué à 4. Dernière modification le 03 octobre 2016 à 13:38.
Huh… source ? De mémoire de mes cours de crypto, c’est le couple (clé, IV) qui ne doit pas être réutilisé.
Edit : stackoverflow confirme mes souvenirs : http://crypto.stackexchange.com/questions/33751/aes-key-reuse-and-guessing-the-key/33757
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . Évalué à 2.
Oui, pardon pour l’abus de langage, il faut comprendre clef par « clef + iv » effectivement. Tant que le couple est unique, on est tranquille (en tout cas dans le cas de AES).
[^] # Re: Crypto pas crypto
Posté par phoenix (site web personnel) . Évalué à 1.
Bonjour,
Je suis en train de retravailler sur la partie crypto avec les informations que vous m'avez données.
Je me pose quelques questions :
sur la partie authentification de l'utilisateur, si je veux faire de la crypto coté client, il est raisonnable d'envoyer les informations S, T, et C que je possède à l'utilisateur authentifié ? Est-ce que j'ai un autre choix ?
sur la partie session : si les opérations se font côtés serveur, je dois maintenir un certain temps les informations me permettant de déchiffrer les messages dans la session. Je peux garder soit le mot de passe de l'utilisateur, soit la clé de chiffrement K. Quel est la meilleur solution ?
Actuellement je chiffre à l'aide d'une clé de session propre à l'utilisateur un token JWT contenant la clé maître (K).
Merci
[^] # Re: Crypto pas crypto
Posté par Aeris (site web personnel) . Évalué à 1. Dernière modification le 06 octobre 2016 à 10:20.
S, T et C sont publiables sur un lien non fiable. C’est même tout le but recherché par le chiffrement :D
Par contre si tu fais de la crypto côté client, le mieux serait de ne jamais avoir à envoyer ces données sur le réseau.
Tu calcules et conserves S,T,C uniquement côté client, et tu mets juste en place un moyen de transférer la clef maîtresse sur un autre périphérique (par exemple avec un QR code ou une chaîne mnémotechnique).
Les 2 solutions sont équivalentes en terme de sécurité (si tu as le pass, tu as la clef K de toute façon).
J’aurais tendance à conserver la clef en mémoire, ça évite d’avoir à redériver le pass et à déchiffrer la clef à chaque fois qu’on en a besoin.
[^] # Re: Crypto pas crypto
Posté par phoenix (site web personnel) . Évalué à 3.
Je viens de mettre à jour https://passprotect.shadoware.org avec un chiffrage pour chaque clé. De plus je chiffre maintenant coté client, et non plus coté serveur.
Par contre j'utilise le serveur pour stocker les données.
Pour moi, et mon utilisation personnelle, le fait de stocké les valeurs S, T, et C coté client est un risque en cas de cache navigateur vidé. Et le fait de pouvoir en faire une sauvegarde par QR code, ou fichier texte est intéressant mais trop compliqué pour l'utilisation que j'ai envie d'en faire.
[^] # Re: Crypto pas crypto
Posté par Buf (Mastodon) . Évalué à 4.
Sur la réutilisation du couple key/iv, c'est effectivement toujours une erreur, mais en mode CTR, c'est absolument catastrophique. Ça signifie par exemple que si je connais un couple cleartext/ciphertext, je peux déchiffrer absolument tous les autres messages chiffrés avec le même couple key/iv d'une taille inférieure ou égale à mon message ! (et les autres, je peux déchiffrer le début)
Utiliser des algorithmes connus et réputés, c'est bien, mais c'est la partie facile. Concevoir un système complet qui soit sécurisé, c'est très difficile, et même les pros et spécialistes dans le domaine font des erreurs. Pour un débutant (et à te lire, je pense que c'est ton cas), c'est quasiment impossible d'y arriver du premier coup, tellement il y a de pièges à éviter et d'erreurs à ne pas commettre.
Il n'y a aucun mal à essayer et développer son propre système (c'est une façon d'apprendre), par contre, il faut bien être conscient que ce n'est en l'état qu'un jouet, et ça ne devrait en aucun cas être utilisé pour stocker quoi que ce soit d'important. Le numéro de version 1.0.0 est trompeur, ça donne l'impression qu'on a quelque chose qui est prêt à être utilisé, or ce n'est pas le cas du tout. Tu devrais mettre un avertissement clair sur le site, histoire d'éviter que quelqu'un n'utilise ça en pensant être en sécurité.
# Crypto & Modules externes
Posté par Grégory Soutadé (site web personnel) . Évalué à 4.
Remarque supplémentaire concernant la crypto : faire transiter les données en clair (même via un canal HTTPS) rend le logiciel inefficace d'une point de vue sécurité, et ce quelle que soit la force de la crypto côté serveur. Il est trop facile de détourner/abuser d'une connexion serveur.
Il serait également intéressant de développer des modules/applications pour les navigateurs ainsi que pour la ligne de commande.
[^] # Re: Crypto & Modules externes
Posté par phoenix (site web personnel) . Évalué à 2.
J'ai l'intention de développer une application android, voir une extension chrome.
Par contre le choix de faire le chiffrage coté serveur a été fait pour des raisons de performances (peut-être mauvaise). Par contre, pour le faire coté client je me pose la question de la fiabilité de librairies cryptographique écris en pure Javascript (https://github.com/crypto-browserify/crypto-browserify).
Je souhaite que mon application puisse aussi fonctionner sans devoir installer quoique ce soit sur le poste client.
[^] # Re: Crypto & Modules externes
Posté par Moonz . Évalué à 2.
Tu peux faire de la crypto en js sur les navigateurs récents : https://developer.mozilla.org/en/docs/Web/API/SubtleCrypto
[^] # Re: Crypto & Modules externes
Posté par Grégory Soutadé (site web personnel) . Évalué à 3.
Si tu fais de la crypto côté serveur, ça veut dire transmission de la clé (maître) et/ou mot de passe en clair sur le réseau, ce qui rend le système très fragile car ces données peuvent être interceptées de manière plus ou moins facile. Surtout que la masse de données à traiter est plutôt faible.
# Liste des autres outils
Posté par GG (site web personnel) . Évalué à 5. Dernière modification le 03 octobre 2016 à 12:20.
Bonjour,
tu nous dis avoir essayé d'autres outils.
Je suis curieux de savoir lesquels, et éventuellement pourquoi tu les as rejetés.
Cela nous fera une liste intéressante d'alternatives.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Liste des autres outils
Posté par phoenix (site web personnel) . Évalué à 3.
Ensuite j'avais envie de le développer moi-même.
[^] # Re: Liste des autres outils
Posté par Grégory Soutadé (site web personnel) . Évalué à 1.
As-tu testé gPass ? Je viens de rajouter récemment l'interface en ligne de commande.
[^] # Re: Liste des autres outils
Posté par paco81 . Évalué à 3. Dernière modification le 06 octobre 2016 à 15:16.
Pour compléter la liste:
- Keepass2Android: application android
- KeeWeb
Ils utilisent tous les deux le format kdbx de keepass v2, fonctionnent offline ou online (avec synchro vers dropbox ou autre). Et ils sont tous les deux libres et ont des fonctionnalités de saisie automatique et de génération de mot de passe.
Donc ils me semblent couvrir tes besoins. Mais l'envie de développer soi-même est suffisante ;)
Sinon, le stockage local avec synchro me semble indispensable, non seulement pour un côté pratique (accès offline) mais aussi car c'est un moyen d'avoir des sauvegardes multiples plutôt que de devoir compter sur la sauvegarde sôté serveur.
[^] # Re: Liste des autres outils
Posté par kna . Évalué à 3.
Ça ne te dispense pas de la sauvegarde non plus. Si jamais ta base keepass est en vrac (ça m'est arrivé une fois), il faudra que tu puisses revenir à une version antérieure, ce qui ne sera pas possible si la dernière version a été synchronisée partout (sauf si tu synchronises avec un gestionnaire de versions).
[^] # Re: Liste des autres outils
Posté par paco81 . Évalué à 1. Dernière modification le 06 octobre 2016 à 20:21.
Tout à fait, et dans ce cas dropbox me permettrait de revenir aux versions antérieures :) (ça ne m'est jamais arrivé)
[^] # Re: Liste des autres outils
Posté par paco81 . Évalué à 1. Dernière modification le 06 octobre 2016 à 20:33.
Ah et puis, je n'ouvre jamais directement le fichier qui est sur dropbox, je travaille avec une copie locale qui est synchronisée par keepass/keepass2android avec la version qui est sur dropbox.
Comme expliqué sur http://keepass.info/help/kb/trigger_examples.html#dbsync
Donc il est impossible qu'une copie locale et la version dropbox partent en vrac toutes les deux.
[^] # Re: Liste des autres outils
Posté par Larry Cow . Évalué à 3.
Il y a notamment une appli {own,next}cloud pour lire ces fichiers kdbx. Très pratique.
[^] # Re: Liste des autres outils
Posté par Benoît Laurent (site web personnel) . Évalué à 1.
Pour android j'utilise KeePassDroid un avis par rapport à Keepass2Android pour ceux qui connaîtraient les deux?
[^] # Re: Liste des autres outils
Posté par paco81 . Évalué à 1. Dernière modification le 07 octobre 2016 à 20:50.
# Et sodium alors ?
Posté par srm . Évalué à 0.
Tu devrais utiliser la lib sodium : https://download.libsodium.org/doc/bindings_for_other_languages/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.