Bonjour !

Je me pose une question.

Est-ce que la valeur de l'option d'authentification peut apparaître en claire sans risque ?

Mon idée est de crypter l'identifiant de connexion et le mot de passe. Je les enregistre dans un fichier de données accessible seulement pour l'administrateur du routeur.
J'essaye de suivre le même principe que pour la sauvegarde d'un mot de passe dans le fichier /etc/shadow. Je pensais crypter cela avec une clé, puis décrypter à
nouveau (à la volée) dans un script afin de générer l'option d'authentification, et finir par détruire la clé immédiatement après.

Le micrologiciel de mon routeur est une image OpenWrt personnalisable (assemblée à partir des sources OpenWrt). Je comptais intégrer le script de @zoc remanié par @nivek1612.
Je me complique éventuellement la vie... mais j'essaye d'incorporer des scripts Shell pour composer automatiquement ma configuration plutôt que de le faire avec un éditeur de texte.
Ça me lasse parce que je manque d'idées. Faire quelque chose de modulable et évanescent pour devenir modulaire.

Ça ne fonctionnera pas : les secrets ainsi hashés ne peuvent pas être extraits (sauf bruteforce, mais ça va faire un peu cher la requête DHCP...).

Tu utilises une clef, pour crypter un login/password plutôt que de stocker ce login/password dans un fichier. Ce que tu fais niveau sécurité revient au même que de simplement mettre le login/password dans un fichier.
Si quelqu'un arrive a lire ton fichier, alors il arrive à utiliser la clef, si il utilise la clef alors il décrypte le login/password. Il n'y a qu'une étape en plus.


Personnellement j'utilise:
- https://akhamar.github.io/orange-bypass-debian/30_interfaces/33_configuration_wan.html#dhcp-orange-option-generator
- https://akhamar.github.io/orange-bypass-debian/30_interfaces/33_configuration_wan.html#dhcp-client-ipv4
- https://akhamar.github.io/orange-bypass-debian/30_interfaces/33_configuration_wan.html#dhcp-client-ipv6

Je me demande si on peut retrouver l'identifiant et le mot de passe en analysant l'option d'authentification.

Idem : on peut retrouver :
- le nom d'utilisateur par simple extraction
- le mot de passe par bruteforce du MD5 (à grands coups de GPUs -- pas de rainbow tables vu qu'il y a un salt)

Ca pourrait avoir un intérêt sur un serveur qui fait aussi routeur d’accès et sur lequel de multiples utilisateurs ont un compte (mais du coup autant changer les droits d’accès au fichier, voir utiliser les ACLs si vraiment parano), mais sur un routeur franchement utilité zéro, car s’il est compromis l’attaquant aura quoi qu’il arrive accès au mécanisme de déchiffrement, soit pourra directement utiliser tcpdump pour avoir le contenu de l’option 90 en clair sur le port WAN.

@xavierg : J'en déduis que ce n'est pas vraiment sécurisé.

Tout à fait. Le MD5 avec salt est un enjoliveur pour dire que le mot de passe ne transite pas en clair, mais ça s'arrête là.

Plus globalement, le chiffrement n'est réellement utile que lorsque le déchiffrement est un processus interactif, c-à-d quand un humain confirme (par la saisie d'un secret) qu'il est bien possible d'accéder au secret chiffré à un instant t. Si tu automatises, par un moyen ou un autre, le déchiffrement du secret (par exemple en stockant la clé et éventuellement la passphrase de la clé), alors ta sécurité ne dépend que des permissions Unix des fichiers concernés.

Et puisqu'on parle de permissions Unix : rappelons que les permissions Unix sont LA première bonne pratique à mettre en place. Typiquement, en supposant que ton client DHCP tourne en root, le ou les fichiers contenant le mot de passe Orange et/ou l'option 90 doivent appartenir à root, sans permission aucune pour le groupe et les autres utilisateurs. Cela permet de garantir que, pour accéder à ce secret, un attaquant devra réussir à obtenir un accès root, autrement dit le contrôle de toute la machine. À ajuster si le client DHCP tourne avec un utilisateur non-privilégié (root:user, 0640).

@Mastah : Je pensais qu'on pouvait crypter des fragments de données avec une clé. Il semblerait qu'une clé cryptographique serve à crypter l'intégralité d'un fichier.

On peut, oui. On utilise une clé pour chiffrer des données. On peut stocker ces données dans un fichier, entourées ou non d'autres données, chiffrées ou non. Il n'existe pas de réelle contrainte liant chiffrement et fichiers.
Par contre, pour revenir sur tes essais, le format shadow ne chiffre pas les mots de passe, il les hash. C'est donc un format qui donne l'impression de contenir de petits bouts de données chiffrées alors qu'en fait il ne contient que des hashs de mots de passe. L'accès au contenu de ce fichier reste protégé par des permissions Unix car un accès libre à ces hashs ouvre la porte à des attaques par bruteforce.