Sollte ein JSON-RPC-Benutzer aufgefordert werden, beim Sichern der Brieftasche ein Passwort zu verwenden?

Ich war überrascht, dass ich meine Wallet über JSON RPC sichern konnte, ohne das Wallet-Passwort zu benötigen (oder sogar ohne ein sekundäres Nur-Backup-Passwort).

Ich befürchte, dass dies zu einem DOS-Angriff führen könnte, wenn Folgendes eintritt

  1. Ein schreibgeschützter Wallet-Dienst wird erstellt, um Operationen mit geringem Risiko mit dem Wallet durchzuführen
  2. Dieser risikoarme Dienst wird irgendwie über ein Web-Frontend usw. ausgenutzt.
  3. Der Hintergrundprozess (der jetzt die Kontrolle über den Angreifer hat) gibt den backupwalletBefehl aus

Ich denke, das kann in Abhängigkeit von einer Reihe von Szenarien ein Risiko darstellen:

  • Der Benutzer kann die Datei mit vielen verschiedenen zufälligen Namen speichern und das Laufwerk füllen (DOS-Angriff)
  • Der Benutzer kann Systemdateien mit einer Kopie der Brieftasche überschreiben (wieder DOS)
  • Wenn vorherige Dateien nicht überschrieben werden und ein Fehler zurückgegeben wird (aufgrund einer doppelten Datei, einer gesperrten Datei usw.), kann der Angreifer Informationen über das entfernte Dateisystem ableiten
  • Wenn das System Pipes unterstützt, kann das Wallet vielleicht zu einem anderen Remote-System (/dev/???) geleitet werden.

Daher frage ich mich, ob ein separates Nur-Backup-Passwort erstellt werden sollte, um dieses Problem zu beheben. Ich möchte nämlich das Passwort "Wallet entschlüsseln" nicht verwenden.

  • Außerdem möchte ich erzwingen, dass alle Sicherungen in ein bestimmtes Verzeichnis (und nicht in ein anderes Laufwerk/einen anderen Pfad) gehen.

  • Ist dies eine gute Idee und wenn ja, wie sollte es in das Netzwerk eingebunden werden?

Wenn ich darüber nachdenke, sollte die Stop () -Methode meiner Meinung nach auch ein Passwort haben (getrennt vom JSONRPC-Konto).
Es gibt wahrscheinlich hundert Angriffsvektoren, wenn Sie ungefilterten Zugriff zum Senden von JSON-RPC-Befehlen gewähren. "backupwallet" ist wahrscheinlich nur das schnellste. Beispielsweise könnten Sie eine Verschlechterung / Denial-of-Service verursachen, indem Sie den RPC-Befehl nonstop getnewaddress ausführen.

Antworten (1)

Der JSON-RPC sollte nie für die Öffentlichkeit zugänglich sein, daher die erforderlichen rpcuserund rpcpassword. Für zusätzliche Sicherheit sollte es auch so konfiguriert werden, dass es entweder nur auf die Loopback-Schnittstelle lauscht oder die zulässigen IPs auf einige wenige vertrauenswürdige Quellen beschränkt sind.

Das Wallet-Passwort wird verwendet, um auf die verschlüsselten privaten Schlüssel zuzugreifen. Aus diesem Grund muss das Wallet für alles, was entweder das Hinzufügen neuer privater Schlüssel oder das Signieren mit den privaten Schlüsseln betrifft, entsperrt werden.

backupwalletexportiert die Schlüssel in ihrer verschlüsselten Form und benötigt daher keine Passphrase.

Wenn Sie nicht vertrauenswürdigen Benutzern den JSON-RPC-Zugriff erlauben müssen, setzen Sie einen Filter davor.

Sollte ein JSON-RPC-Benutzer aufgefordert werden, beim Sichern der Brieftasche ein Passwort zu verwenden?
AntwortenHierDatenschutz-Bestimmungen1y, 0v