@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.