#dusk $DUSK @Dusk
Je suis revenu aux notes de sécurité du portefeuille de Dusk et au changelog de la version v0.3.0 avec une hypothèse simple : la sécurité du portefeuille consistait à protéger la phrase mnémonique et à définir un mot de passe solide.
La conception de l’extension est davantage opérationnelle. Son mnémonique est chiffré au repos avec PBKDF2 et AES-GCM-256, mais un mnémonique déverrouillé reste en mémoire JavaScript et il n’est pas possible de garantir qu’il est effectivement mis à zéro. Le verrouillage automatique est déclenché par des alarmes du navigateur ; la v0.3.0 a corrigé le horodatage d’activité qui survivait aux redémarrages des workers en arrière-plan et a conservé les événements d’état verrouillé pour les dApps connectées. Le fournisseur vérifie aussi la longueur du mémo et rejette les mémos lors d’appels de contrat, car la charge utile peut contenir soit un mémo, soit un appel, mais pas les deux. Les anciens enregistrements de coffre non pris en charge sont effacés et nécessitent une réimportation de la mnémonique plutôt qu’une acceptation silencieuse.
Cela m’a amené à le voir autrement.
Mon interprétation : la confidentialité peut échouer à la frontière entre la session et l’état local, même lorsque la cryptographie des transactions protégées est solide.
Mon incertitude porte sur le compromis en matière de récupération. Le fait de refuser un ancien format de coffre protège-t-il les utilisateurs contre des enregistrements falsifiés ou faibles, ou crée-t-il un nouveau risque opérationnel lorsqu’un utilisateur ne parvient pas à retrouver la graine ? Et des verrouillages automatiques fréquents renforcent-ils un usage réel, ou entraînent-ils les gens à approuver des invites sans les lire ?
Je veux observer cela en pratique.
Je suis revenu aux notes de sécurité du portefeuille de Dusk et au changelog de la version v0.3.0 avec une hypothèse simple : la sécurité du portefeuille consistait à protéger la phrase mnémonique et à définir un mot de passe solide.
La conception de l’extension est davantage opérationnelle. Son mnémonique est chiffré au repos avec PBKDF2 et AES-GCM-256, mais un mnémonique déverrouillé reste en mémoire JavaScript et il n’est pas possible de garantir qu’il est effectivement mis à zéro. Le verrouillage automatique est déclenché par des alarmes du navigateur ; la v0.3.0 a corrigé le horodatage d’activité qui survivait aux redémarrages des workers en arrière-plan et a conservé les événements d’état verrouillé pour les dApps connectées. Le fournisseur vérifie aussi la longueur du mémo et rejette les mémos lors d’appels de contrat, car la charge utile peut contenir soit un mémo, soit un appel, mais pas les deux. Les anciens enregistrements de coffre non pris en charge sont effacés et nécessitent une réimportation de la mnémonique plutôt qu’une acceptation silencieuse.
Cela m’a amené à le voir autrement.
Mon interprétation : la confidentialité peut échouer à la frontière entre la session et l’état local, même lorsque la cryptographie des transactions protégées est solide.
Mon incertitude porte sur le compromis en matière de récupération. Le fait de refuser un ancien format de coffre protège-t-il les utilisateurs contre des enregistrements falsifiés ou faibles, ou crée-t-il un nouveau risque opérationnel lorsqu’un utilisateur ne parvient pas à retrouver la graine ? Et des verrouillages automatiques fréquents renforcent-ils un usage réel, ou entraînent-ils les gens à approuver des invites sans les lire ?
Je veux observer cela en pratique.
