#dusk $DUSK @Dusk
Ich bin noch einmal durch die Sicherheitshinweise zur Wallet von Dusk und das Changelog von v0.3.0 gegangen – mit einer einfachen Annahme: Wallet-Sicherheit bedeutet, die Seed-Phrase zu schützen und ein starkes Passwort festzulegen.
Das Design der Erweiterung ist eher operativ. Ihre Merksatz-Angabe ist im Ruhezustand mit PBKDF2 und AES-GCM-256 verschlüsselt, aber ein entsperrter Merksatz liegt weiterhin im JavaScript-Speicher und kann nicht garantiert vollständig nullinitialisiert werden. Das automatische Sperren wird durch Browser-Alarme gesteuert; v0.3.0 hat den Aktivitätszeitstempel so korrigiert, dass er bei Neustarts von Background-Workern erhalten bleibt, und hat außerdem gesperrte Zustände für verbundene dApps korrekt beibehalten. Der Provider prüft zudem die Memo-Länge und lehnt Memos bei Contract-Calls ab, weil der Payload entweder ein Memo oder ein Call sein kann – nicht beides. Nicht unterstützte ältere Vault-Einträge werden gelöscht und erfordern eine erneute Merksatz-Importierung, statt stillschweigend akzeptiert zu werden.
Das hat mich dazu gebracht, es anders zu betrachten.
Meine Interpretation: Der Datenschutz kann an der Session- und Local-State-Grenze scheitern, auch wenn die verschlüsselte Transaktionskryptografie innerhalb des abgeschirmten Transaktionssystems korrekt ist.
Meine Unsicherheit betrifft den Wiederherstellungs-Trade-off. Schützt das Zurückweisen eines alten Vault-Formats Nutzer vor manipulierten oder schwachen Datensätzen – oder schafft es ein neues Betriebsrisiko, wenn ein Nutzer die Seed nicht findet? Und machen häufige Auto-Locks die echte Nutzung stärker, oder trainieren sie Menschen dazu, Bestätigungsaufforderungen zu akzeptieren, ohne zu lesen?
Ich möchte das in der Praxis beobachten.
Ich bin noch einmal durch die Sicherheitshinweise zur Wallet von Dusk und das Changelog von v0.3.0 gegangen – mit einer einfachen Annahme: Wallet-Sicherheit bedeutet, die Seed-Phrase zu schützen und ein starkes Passwort festzulegen.
Das Design der Erweiterung ist eher operativ. Ihre Merksatz-Angabe ist im Ruhezustand mit PBKDF2 und AES-GCM-256 verschlüsselt, aber ein entsperrter Merksatz liegt weiterhin im JavaScript-Speicher und kann nicht garantiert vollständig nullinitialisiert werden. Das automatische Sperren wird durch Browser-Alarme gesteuert; v0.3.0 hat den Aktivitätszeitstempel so korrigiert, dass er bei Neustarts von Background-Workern erhalten bleibt, und hat außerdem gesperrte Zustände für verbundene dApps korrekt beibehalten. Der Provider prüft zudem die Memo-Länge und lehnt Memos bei Contract-Calls ab, weil der Payload entweder ein Memo oder ein Call sein kann – nicht beides. Nicht unterstützte ältere Vault-Einträge werden gelöscht und erfordern eine erneute Merksatz-Importierung, statt stillschweigend akzeptiert zu werden.
Das hat mich dazu gebracht, es anders zu betrachten.
Meine Interpretation: Der Datenschutz kann an der Session- und Local-State-Grenze scheitern, auch wenn die verschlüsselte Transaktionskryptografie innerhalb des abgeschirmten Transaktionssystems korrekt ist.
Meine Unsicherheit betrifft den Wiederherstellungs-Trade-off. Schützt das Zurückweisen eines alten Vault-Formats Nutzer vor manipulierten oder schwachen Datensätzen – oder schafft es ein neues Betriebsrisiko, wenn ein Nutzer die Seed nicht findet? Und machen häufige Auto-Locks die echte Nutzung stärker, oder trainieren sie Menschen dazu, Bestätigungsaufforderungen zu akzeptieren, ohne zu lesen?
Ich möchte das in der Praxis beobachten.
