Force des mots de passe des comptes membre "créés" dans Cesium

Clients Cesium
1

@kimamila et qui d’autre ?..

Voilà, en participant à des Ğmarchés et apéros, je me rends compte que bon nombre de personnes créent leur compte membre sans avoir aucune notion de sécurité informatique, ou ont des croyances erronées. Cela aboutit a des comptes membres dont le couple identifiant / mot de passe est vulnérables aux attaques, force brute, dictionnaire, ou autres que je ne connais pas.

Étant donné que les comptes membres sont des comptes sensibles, puisqu’ils permettent via Duniter d’écrire dans la blockchain, je me dis qu’il y a un enjeu majeur à communiquer de façon à ce que les comptes membres ne soient plus créés à la légère, mais c’est pas facile de faire le grand écart entre simplicité d’utilisation / accessibilité au néophite d’une part, et rigueur / sécurité d’autre part.
Et quand je vois que pour crééer un compte membre dans Cesium, les infos qui sont données (si on clique sur le tout petit point d’interrogation) sont :

  • un bon identifiant secret doit être suffisamment long (au moins 8 caractères) et le plus original possible
  • un bon mot de passe contient (idéalement) au moins 8 caractères, dont au moins une majuscule et un chiffre.

Je trouve que c’est vraiment très light pour un compte membre (pour un compte simple-portefeuille quelque part on s’en fout, au pire la personne perd ses Ğ1, mais ça n’a pas d’incidence pour la communauté, hormis la déception/colère et perte de confiance qui peut s’en suivre).

Sur le site de l’ANSSI il est écrit :
« Une taille de clé cryptographique de 64 bits est aujourd’hui considérée comme non sûre. Les règles édictées par l’ANSSI en matière de mécanismes cryptographiques imposent par exemple une taille de clé minimale de 100 bits. Il est même recommandé une taille de clé de 128 bits pour des clés dont l’usage présumé est de longue durée. Il est par ailleurs communément admis que des tailles de clé de 80 bits sont désormais exposées à des attaques utilisant des moyens techniques conséquents. »

8 caractères dont au moins une majuscule et un chiffre, comme recommandé dans Cesium, ça fait une entropie de combien ? Même pas 40 bits ?!!..

Bon, du coup, serait-il possible d’intégrer, et peut-être d’en imposer l’usage, un générateur de mots de passe dans Cesium, forts pour les comptes membres, et plus libre pour les simple-portefeuille ?
Recommander l’usage d’un gestionnaire de mots de passe comme KeepassXC, de stocker la base de données dans un cloud et d’en faire régulièrement des sauvegardes… etc… Il n’y a plus alors à retenir qu’un seul mot de passe, certes très fort, style phrase Diceware à 8 mots, mais facile à taper et à retenir.

Pour ma part en tout cas, quand qqn me demande une certif, je lui pose la question, et si je trouve que ses identifiants et mot de passe sont trop faibles, je ne certifie pas, et je recommander de révoquer le compte pour en créer un autre plus sérieusement.

On pourrait aussi ajouter des recommandations de sécurité, ou un lien, dans la licence, non ?

Il pourrait par ailleurs être nécessaire de brider les versions de Césium pour smartphone de façon à ce que la création et l’usage de comptes membres sur smartphones ne soient plus possibles que sur ordinateurs (même si certains sur Windows sont aussi problématiques).

Qu’en pensez vous ?..

3 Likes
2

J’avais justement rédigé des recommandations de sécurité officielles pour éviter ça :

Cesium devrait pointer vers ses recommandations et donner des conseils cohérents avec leur contenu, cc @kimamila

C’est pour cela qu’a terme ce ne sera plus le cas : Proposition d’identités forgerons − solution user-friendly au problème de sécurité des instances cesium web

2 Likes
3

Je fais exactement pareil et je pense d’ailleurs que la licence devrait être amendée sur ce point. Un certificateur devrait s’assurer que la personne certifiée à bien conscience des enjeux de sécurité. Mais comme je sais que ce n’est pas réaliste pour rester accessible, il me semble inévitable d’avoir une licence spécifique pour le droit de forger, cf proposition citée dans mon post précédent.

3 Likes
4

Pourquoi laisser les utilisateurs generer leur mdp ?
Je pense qu’il faut tout simplement generer les mdp avec diceware sans laisser a l’utilisateur le choix, non?

5

Soit on fait ça dans le protocole, et ce n’est pas propre, spécifique à un lexique précis (qui n’est partagé ni dans le temps ni dans l’espace), soit dans le client, et alors le client ne permet plus d’utiliser certains comptes, par exemple ceux créés par d’autres clients, avec des identifiants aléatoires très longs.

Et si on l’oblige, alors il n’aura pas besoin d’apprendre que c’est mal de faire autrement.

3 Likes
6

Merci pour ces points de vue. J’aime bien que tu soulignes le fait que contraindre à faire d’une certaine façon, c’est du même coup néfaste à l’autonomie et la responsabilisation. On pourrait donner le choix, de s’en remettre ou non à un générateur de mot passe, ou de générer les nôtres. Comme ça l’utilisateur est averti, mais il reste libre. Voulons nous accepter de lui laisser la liberté d’avoir un comportement risqué pour la communauté ?.. je sais pas. Peut-être, car ce type de comportement deviendrait alors tout de même plus marginal je pense, car une fois informés, les gens à qui je parle de ça sont quasiment tous d’accord de révoquer leur compte pour que je les aide à créer un autre compte avec plus de sérieux.

7

Si je comprends bien les clefs sont genere a partir de ce que donne l’utilisateur ?

Dans tout les logiciels les clefs sont generees aleatoirement.
Ce n’est pas parceque on ne choisit pas soit meme sa clef PGP, mais qu’on laisse l’ordinateur le faire aleatoirement qu’on perd en autonomie et responsabilite.
Le seul bon choix c’est d’utiliser des mdp aleatoires de toute facon.

Une conf pertinente : https://www.youtube.com/watch?v=foil0hzl4Pg

8

Éduquer et avertir est nécessaire, mais pas suffisant. Le syndrome de TL;DR (trop long; pas lu) est le principal problème.

Des solutions de sécurité côté serveurs sont en cours, comme expliqué par @elois.

Côté clients, @tykayn nous prépare une génération automatique de mots de passe dans Cesium.

De mon côté, je propose de créer des phrases de passe pour les deux secrets, ou une génération forte par un gestionnaire de mot de passe.

Les utilisateurs vous rétorquent immédiatement : c’est pas pratique quand un effort se pointe.

Je montre alors le remplissage automatique des gestionnaires de mot de passe et la sauvegarde du trousseau dans Cesium (authentification par fichier).

J’insiste aussi sur l’unicité des identifiants. Cela laisse l’utilisateur perplexe quand je lui dit que ses identifiants doivent être uniques au monde. Comment faire pour le savoir. Je leur répond : à vous de juger…

Et je leur dit que les gestionnaires de mots de passe donne un bon indice avec le calcul de l’entropie.

1 Like
9

Scrypt est une bonne sécurité contre la force brute : j’ai testé les 122500 premières possibilités. (350 possibilités pour chaque identifiant) avec les lettres minuscules, majuscules et les chiffres. (donc je n’ai même pas pu tester toutes les possibilités pour des identifiants de 2 caractères) Ça a pris environ 10 minutes, pour obtenir 2 comptes non membres totalisant 29,11 Ğ1. (Intel core i5 7300HQ, avec du Rust utilisant les 4 cœurs)

Ce sont les comptes ("", "") et ("1", "2"), probablement utilisés par des devs pour le test…

Il faudrait utiliser un dictionnaire pour arriver à quelque chose. 1024 combinaisons me prennent déjà 6s, c’est énorme.

Le programme teste pour chaque combinaison si la clé publique est dans la liste des clés ayant un montant non nul ou étant membre. Je publie le dépôt si ça intéresse quelqu’un…

2 Likes
10

A tu par hasard utilisé mon implémentation optimisée de scrypt dans dup-crypto ? Sur mon laptop ça prend en moyenne 10ms pour générer une seed avec scrypt, soit environ 100 tests/seconde/cœur.

Bon évidemment dans la pratique c’est plus lent car il y d’autres traitements a faire (vérifier si la clé publique obtenu fait partie ou non des clés publiques ciblées).
Si tu précharge toutes les clés publiques ciblées dans un HashSet y a moyen de bourriner :laughing:

11

Oui !

Il y a toujours 13000 G1 à débloquer par attaque dictionnaire

1 Like
12

J’ai utilisé ton KeyPairFromSaltedPasswordGenerator. Il y a mieux ?

Sur les 4 cœurs j’ai ~160 test/s. Mais je ne génère pas que la seed, il me faut la clé publique, et je la cherche dans une HashMap (HashSet n’a pas été significativement plus rapide).

13

Ça c’est l’API que j’expose, l’implémentation de scrypt derrière a changée depuis dup-crypto 0.17 : feat (crypto): create custom scrypt impl that use ring pbkdf2 (e2606021) · Commits · libs / dubp-rs-libs · GitLab

Par contre, dup-crypto va “zéroisée”(réécrire la valeur en mémoire avec des zéros) le salt et le password une fois la seed générée (par mesure de sécurité), mais pour un bruteforce c’est des opérations inutiles donc une perte de perf.

Donc pour gagner en perf il faudrait forker dup-crypto en supprimant zeroize, ou que je rajoute une feature “unsafe_bruteforce” avec une doc qui explique bien qu’il NE FAUT PAS utiliser cette feature en dehors d’un contexte de bruteforce.

1 Like
14

Bonjour, Elois.
Besoin d’infos plus précises concernant la sécurité.
Il semblerait qu’on puisse se connecter sur son compte directement avec sa clé publique.
Comment renforcer tout cela ?

15

Dans Cesium il n’y a pas vraiment de « connexion ».
Si tu entres tes identifiants, alors Cesium dispose de ta clef privée et peut signer des documents à envoyer à la blockchain (faire un paiement, une certification, etc).
Si tu n’entres pas tes identifiants, tu peux faire toute actions de lecture sur tous les comptes (la blockchain est publique), mais aucune action nécessitant la clef privée.
Il n’y a donc rien à renforcer de ce côté là.

16

J’ai eu l’impression que je pouvais réaliser des virement d’un compte à un autre. Si ce n’est pas le cas, c’est plutôt rassurant.
Merci pour cette réponse