Das verschlüsselte Verzeichnis für Zugangsdaten

Wo Passwörter liegen, wie sie in ein Formular gelangen, ohne durch Ihre Shell zu gehen, und der Fehler, der sie im Klartext schreibt.

Ihre Zugangsdaten liegen in einem verschlüsselten Verzeichnis, das Sie einhängen, einem gocryptfs-Volume. Darin stehen sie in einfachen JSON-Dateien, lesbar nur, solange das Volume eingehängt ist. Dinoer liest sie im Prozess, der den Browser steuert, in dem Moment, in dem ein Feld ausgefüllt wird. Der Wert geht nie durch Ihre Shell, Ihren Befehlsverlauf oder Dinoers Protokolle.

Anlegen, dann einhängen

Bei einer Installation per Git-Klon legt das Einrichtungsskript den verschlüsselten Speicher und einen leeren Einhängepunkt an, unter den Pfaden, die secrets_crypt_dir und secrets_dir in dinoer.conf festlegen. --sans-chiffrement legt stattdessen ein unverschlüsseltes Verzeichnis an (Modus 700), für einen Rechner ohne gocryptfs:

bash scripts/configurer-repertoire-chiffre.sh    # im Klon

Das .deb-Paket liefert dieses Skript nicht mit: Legen Sie das gocryptfs-Volume selbst an und tragen Sie seinen Einhängepunkt in secrets_dir ein. Danach hängen Sie es, auf beiden Wegen, vor einem Lauf ein, der es braucht:

dinoer-monter-secrets                                     # .deb-Paket
bash /opt/dinoer/scripts/monter-repertoire-chiffre.sh     # Git-Klon

Solange das Volume nicht eingehängt ist, ist auf der Festplatte nichts lesbar.

Zugangsdaten hineinlegen

Eine JSON-Datei pro Website, benannt nach ihrer Domain (target.local.json, oder target.local_8443.json für einen bestimmten Port), an beliebiger Stelle unter dem eingehängten Verzeichnis:

{
  "username": "operator",
  "password": "…",
  "totp_cle": "BASE32SEED",
  "ntfy_topic": "…",
  "origines_autorisees": ["target.local"]
}

Nur die Schlüssel, die Ihre Szenarien verwenden, müssen vorhanden sein. totp_cle ist der Base32-Schlüssel für Zwei-Faktor-Codes; ntfy_topic ist der Kanal, über den ein Code, den Sie erhalten, weitergegeben werden kann. Ohne --secrets wählt Dinoer die Datei nach der Domain der tatsächlich geladenen Seite: Eine Weiterleitung auf eine andere Website findet keine Zugangsdaten. Mit --secrets wird die Datei ausdrücklich benannt: Sie muss dann in origines_autorisees die Domains aufführen, auf denen sie verwendet werden darf, und nur für ihren Besitzer lesbar sein (chmod 600), sonst lehnt Dinoer sie ab.

In einem Szenario verwenden

{"type": "remplir", "selecteur": "input[name=\"username\"]",
 "valeur": "depuis_secrets", "secret_cle": "username"},
{"type": "remplir", "selecteur": "input[name=\"password\"]",
 "valeur": "depuis_secrets", "secret_cle": "password"}

secret_cle ist der Schlüssel in der Datei. Das Szenario nennt einen Schlüssel, nie ein Geheimnis, und kann deshalb in einem öffentlichen Repository liegen, ohne dass etwas geschwärzt werden muss.

Tun Sie das nie PASS=$(jq -r ‘.password’ ~/Vaults/…/creds.json): Zugangsdaten in einer Shell-Variablen stehen in der Umgebung Ihres Prozesses, in /proc und womöglich in Ihrem Verlauf. Genau das soll das verschlüsselte Verzeichnis verhindern.

Ein Verzeichnis pro Projekt

Zwei Wege, für einen einmaligen Lauf oder als Gewohnheit.

# Einmalig
DINOER_SECRETS_DIR=~/Vaults/MyProject /opt/dinoer/venv/bin/python3 /opt/dinoer/shot.py \
  --url … --guide-version 1.6

# Dauerhaft: eine Konfigurationsdatei im Stammverzeichnis des Projekts
echo '{"secrets_dir": "../MyProject-secrets"}' > ~/git/MyProject/.dinoer.conf
export DINOER_CONF=~/git/MyProject/.dinoer.conf

Ein relatives secrets_dir wird vom Ort der Konfigurationsdatei aus aufgelöst; die Einstellung wandert also mit dem Projekt.

--secrets <Datei> benennt eine Datei mit Zugangsdaten für einen einzigen Lauf, ohne die Konfiguration zu ändern, etwa wenn dasselbe Szenario mehreren Konten dient.

Wenn das Verzeichnis geschlossen ist

Dinoer hält mit einem klaren Fehler an:

SecretsFermesError — exit code 42 (encrypted directory not mounted)
SecretsNonConfigureError — exit code 43 (no credential directory configured)

Wenn Sie ein Agent sind: Versuchen Sie nicht, es selbst einzuhängen. Fragen Sie den Betreiber.

Dinoer schützt auch seine eigenen Schreibvorgänge: Liegt sein Betriebsjournal im verschlüsselten Verzeichnis und ist dieses geschlossen, schreibt es in eine lokale Ersatzdatei, statt im Klartext dorthin zu schreiben, wo der verschlüsselte Speicher sein sollte.

Der Fehler, der am meisten kostet

Ein nicht eingehängtes Verzeichnis existiert trotzdem. Es ist nur leer, und unverschlüsselt.

Dinoers Schutz gilt für seine eigenen Schreibvorgänge. Er gilt nicht für eine Datei mit Zugangsdaten, die Sie selbst mit einem Befehl oder einem Editor anlegen, während das Verzeichnis gerade nicht eingehängt ist. Sie schreiben dann neben den verschlüsselten Speicher, im Klartext, in ein Verzeichnis, das genau richtig aussieht.

Bevor Sie eine Datei mit Zugangsdaten anlegen oder ändern, prüfen Sie, ob das Verzeichnis eingehängt ist: Es darf nicht leer sein. Dieser Fehler lässt sich nicht rückgängig machen.

Kurz gesagt

Die Datei wird im Browser-Prozess gelesen, nie über Ihre Shell.
Szenarien nennen einen Schlüssel, nie ein Geheimnis, und lassen sich daher committen.
DINOER_CONF, DINOER_SECRETS_DIR oder --secrets für Zugangsdaten pro Projekt und pro Konto.
Code 42 heißt geschlossen, Code 43 nie eingerichtet: Fragen Sie den Betreiber, hängen Sie nicht selbst ein.
Ein nicht eingehängtes Verzeichnis ist ein leeres, unverschlüsseltes Verzeichnis. Prüfen Sie vor dem Schreiben.