Dans le ticket #177 je décris un scénario d’attaque permettant de récupérer des certifications que l’on pourrait mitiger en distinguant add_cert et renew_cert. Qu’en pensez-vous ?
1 Like
Côté client c’est plus simple en soit de n’avoir à gérer qu’un extrinsic add_cert quelque soit le scénario.
Le reste c’est de l’affichage en fonction du context, dans tous les cas l’affichage sera adapté si c’est une nouvelle certification ou un renouvellement, que le call soit différencié ou non.
Cependant pour les événements en effet ça peut être judicieux de les distinguer. Je n’ai pas lu le code à ce sujet, mais je ne pense pas qu’il soit nécessaire de distinguer les calls pour distinguer les events en fonction du context ?
En revanche l’argument de la sur-estimation du benchmark pour le renouvellement reste valable. A voir si ça en vaut vraiment la peine.
2 Likes
En effet ça réduit le risque d’erreur en plaçant l’intelligence dans le client plutôt que dans Duniter, et en rendant le call explicite sans contexte. Le client est alors obligé de différencier les deux cas dans l’UI.
1 Like
De mon côté je trouve que distinguer les extrinsics add et renew serait plus clair, dans la mesure où les évènements sont déjà différents. Il me semble étrange en effet de lancer un ‘add’ et d’attendre ensuite un évènement ‘renew’ pour avertir de la prise en compte.
3 Likes
Tout à fait d’accord : add_cert a un comportement ambigu, et comme tu le montre Hugo l’extrinsic peut agir contre la volonté de l’utilisateur. C’est un vrai bug fonctionnel.
2 Likes
Bon, tant que j’y suis, parlons aussi de #178. Je propose de remplacer add_cert(origin, issuer, receiver) par add_cert(origin, target), puisque de toute façon l’émetteur doit être le signataire. Elois avait peut-être une idée en tête, mais sauf erreur il ne nous l’a pas transmise.
Je me suis déjà posé la question, je suppose que l’intérêt est que si l’identité source n’est pas dans l’extrinsic, alors est est déterminée par le contexte, ce qui augmente le risque d’erreur.
Cependant puisque chaque compte n’a qu’une seule identité simultanément, et qu’en cas de multiples identités dans le temps il y a forcément des calls entre elles, une erreur ou attaque par rejeu devrait être très improbable (grâce au nonce).
Donc ça ne me choque pas de retirer cet argument.
2 Likes
Le contexte en l’occurrence, c’est la signature de l’émetteur, donc normalement il est responsable de ses clés. Et les interfaces afficheront bien l’identité de l’émetteur de la certification.
J’ai fait un petit paquet de modifications dans !230, je soumettrai à relecture et à discussion pour voir si la solution finale convient
1 Like
Par contexte j’entendais le storage, qui seul permet de récupérer l’identité correspondante.
1 Like
Ah oui, en effet, si un bug permet de modifier le storage et qu’un accountid redirige vers le mauvais idtyindex, on est fichu !
Il faudra juste faire attention aux règles concernant les identités sur des comptes ayant déjà eu une identité avant, qui a été révoquée ou changée de compte (ces deux cas pouvant être légitimes).
- A devient membre avec l’identité 1.
- Au choix :
2.1. A révoque l’identité 1.
2.2. A déplace l’identité 1 sur B puis B révoque l’identité 1.
2.3. L’identité 1 expire. - A redevient membre avec l’identité 2.
Une certification est créée en connaissance du storage effectif au temps entre 1 et 2 (soit la certification est créée et stockée hors-ligne à ce moment, soit elle est créée plus tard par un client buggé ou désynchronisé).
Elle est publiée après le temps 3.
Des calls ont forcément été faits par A entre temps donc la certif ne passe que si son nonce a mal été choisi (incrément >1).
Il n’est pas inenvisageable que des clients utilisent des incréments de nonce très grands pour contourner salement des problèmes de concurrence et de problèmes réseau. Ce bug reste très peu probable (il faut soit conserver hors-ligne une vieille transaction pendant des mois, soit être désynchro sur un client après avoir créé une nouvelle identité sur un autre client, et que le client désynchro fonctionne suffisamment pour envoyer une certif) et très marginal (situation probablement assez rare).
2 Likes