Le répertoire des informations d'identification chiffrées

Où les mots de passe sont stockés, comment ils parviennent à un formulaire sans jamais passer par votre terminal, et l'erreur silencieuse qui les enregistre en texte clair.

Vos identifiants se trouvent dans un répertoire chiffré que vous montez, un volume gocryptfs. Ils sont stockés dans un fichier JSON simple à l’intérieur de ce répertoire, et ce fichier n’est lisible que lorsque le volume est monté. Dinoer le lit dans le processus qui contrôle le navigateur, au moment où un champ est rempli. La valeur ne transite jamais par votre shell, votre historique de commandes ou les propres journaux de Dinoer.

La distinction est importante, et le mot cause des dommages : un fichier JSON n’est pas sécurisé, et l’appeler ainsi promet une garantie que le fichier ne fournit pas. Ce qui protège les informations d’identification, c’est le chiffrement du répertoire qui les entoure, et le fait que Dinoer ne sort jamais la valeur du processus qui en a besoin.

C’est tout le mécanisme. Le reste de cette page explique comment l’installer, et une façon de faire une erreur.

Créez-le une fois

bash /opt/dinoer/scripts/monter-repertoire-chiffre.sh    # mount an existing encrypted directory

Pour en créer un, le script de configuration gère les deux modes : un répertoire simple ou un répertoire chiffré par gocryptfs :

bash ~/git/Dinoer/Dinoer/scripts/configurer-repertoire-chiffre.sh

Le mode crypté crée un espace de stockage chiffré et un point de montage vide. Rien n’est lisible sur le disque tant que vous ne l’avez pas monté.

Incluez les informations d’identification ici

Un fichier JSON simple à l’intérieur du répertoire monté :

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

Seules les clés effectivement référencées par votre scénario doivent exister, à l’exception d’origines_autorisees — obligatoire, sans exception. Elle liste les noms d’hôte contre lesquels ce fichier peut être utilisé ; une lecture visant tout autre domaine est refusée avant même que le fichier ne soit ouvert. totp_cle est la graine base32 des codes à deux facteurs ; ntfy_topic sert aux codes qui vous sont poussés.

Utilisez-le dans un scénario

{"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 est la clé contenue dans le fichier déchiffré. Le scénario reste exécutable — il mentionne une clé, jamais un secret. C’est pourquoi un scénario peut être stocké dans un dépôt public sans que quoi que ce soit ne soit censuré.

Ne faites jamais ceci PASS=$(jq -r ‘.password’ ~/Vaults/…/creds.json) — une information d’identification dans une variable de shell se trouve dans votre environnement de processus, dans /proc, et éventuellement dans votre historique. Le répertoire chiffré existe précisément pour éviter cela.

Un répertoire par projet

Deux manières de faire, selon que ce soit une action ponctuelle ou une habitude.

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

# Recurring — a config file at the project root
echo '{"secrets_dir": "../MyProject-secrets"}' > ~/git/MyProject/.dinoer.conf
export DINOER_CONF=~/git/MyProject/.dinoer.conf

Un chemin relatif secrets_dir est résolu par rapport à l’emplacement du fichier de configuration, donc l’ensemble est transporté avec le projet.

--secrets <file> désigne un fichier d’informations d’identification spécifique pour une exécution sans modifier aucune configuration ; cela est utile lorsque le même scénario sert plusieurs clients.

Lorsque le répertoire est fermé

Dinoer s’arrête avec un échec explicite plutôt que de faire semblant :

SecretsFermesError — exit code 42
SecretsNonConfigureError — exit code 43 (no encrypted directory configured at all)

Si vous êtes un technicien : n’essayez pas de le monter vous-même. Demandez à l’opérateur.

Dinoer protège également ses propres écritures. Son journal des opérations détecte un répertoire fermé et redirige vers une solution de secours locale au lieu d’écrire en texte clair là où le stockage chiffré devrait se trouver.

L’erreur qui coûte le plus cher

Un répertoire non monté existe toujours. Il est simplement vide et non chiffré.

La protection interne de Dinoer couvre uniquement les écritures effectuées par Dinoer lui-même. Elle ne protège pas un fichier d’informations d’identification que vous créez vous-même, à l’aide d’une commande shell ou d’un éditeur, alors que le répertoire est démonté. Dans ce cas, vous n’écrivez pas à l’intérieur du répertoire : vous écrivez à côté de celui-ci, en texte clair, dans un répertoire qui semble parfaitement correct.

Avant de créer ou de mettre à jour un fichier d’informations d’identification, vérifiez que le répertoire est monté ; il doit être non vide. En cas de doute, arrêtez et vérifiez. Cette opération ne peut pas être annulée.

En bref

Le fichier est lu dans le processus du navigateur, et jamais via votre shell.
Les scénarios nomment une clé, et non un secret — ils restent donc commitables.
DINOER_CONF ou --secrets pour les répertoires par projet et par locataire.
La sortie 42 signifie fermé, la sortie 43 signifie qu’il n’a jamais été configuré — demandez à l’administrateur, ne le configurez pas vous-même.
Un répertoire non monté est un répertoire vide et non chiffré. Vérifiez avant d’écrire.