L'apparence à l'écran du célèbre couple "login-password" n'a pas changé depuis bien longtemps, mais il n'en est pas de même pour l'implémentation sous-jacente [30]. Dans un premier temps en effet, la base de données /etc/passwd qui contient entre autres le moyen de vérifier ces couples a d'abord été stockée en clair, la protection reposant uniquement sur les privilèges du super-utilisateur. Avec le défaut supplémentaire qu'un logiciel ordinaire ne pouvait pas utiliser la base /etc/passwd pour récupérer d'autres champ, comme user.
Depuis, le fichier /etc/passwd est laissé accessible en lecture, mais bien entendu, le champ key (correspondant au mot_de_passe) n'est plus en clair. Il n'est pas chiffré non plus, car il suffirait, comme précédemment, de subvertir les privilèges du super-user pour s'approprier la clef de chiffrement et, de là, déchiffrer tranquillement les champs keys pour récupérer les mots_de_passe.
Au contraire, c'est le mot_de_passe qui est pris comme clef pour chiffrer une suite immuable de bits, par un procédé supposé non-inversible : la routine de login n'a donc pas à déchiffrer le champ key pour le comparer au mot_de_passe tapé à la console, mais au contraire à rechiffrer le vecteur initial (fixe) à l'aide du mot_de_passe proposé.
Une amélioration supplémentaire consiste à stocker à part, dans un fichier à accès réservé, les couples login-key, en ne laissant qu'une étoile dans le champ key de /etc/passwd pour affirmer l'existence d'un password.
Cela semble solide, et cela ne l'est pas. Parce que les utilisateurs passent outre toutes les incantations des administrateurs système [42], et continuent à choisir des mots_de_passe transparents : le nom de login doublé (quand ce n'est pas le nom lui-même), un prénom, un nom commun (très commun) ou un héros de Tolkien. Il suffirait d'en dresser la traduction une fois pour toutes à l'aide d'un circuit-DES, et de comparer.
Par ailleurs, les utilisateurs ont l'habitude d'utiliser le même mot de passe sur toutes les machines où ils ont un compte : en casser un, c'est les avoir tous.
Quelques petites plaisanteries (=salt) ont alors été ajoutées à l'implémentation pour gêner les attaques.
Dans la version usuelle de /bin/passwd, le champ key est composé de 13 caractères prenant leur valeur dans un alphabet de 64 signes (chiffres, '.', '/', majuscules, minuscules). Les 11 derniers caractères du champ key, codant pour 66 bits, permettent de stocker les 64 bits résultant du chiffrement de la chaîne fixe (de 64 bits) par une clef DES (de 56 bits) composée des 8 premiers caractères (ascii) entrés au clavier.
Mais le codage ne se fait pas exactement selon les tables du DES-ECB, mais selon une parmi 4096 (=64*64) variantes, déterminée selon la valeur d'un nombre aléatoire (le grain de sel). Celui-ci est stocké dans les deux premiers caractères du champ key, pour savoir comment reproduire le chiffrement pour les tests ultérieurs.
Un attaquant ne peut donc pas utiliser une implémentation hardware du DES pour accélérer ses essais, et chaque fois qu'il essaye un mot_de_passe, le résultat n'est utilisable que pour les comptes qui auraient le même salt. Un exemple est donné dans la Table 15.
Il serait intéressant d'examiner si les 4096 machines DES-like engendrées par les différents "salts" sont cryptographiquement fiables, c'est à dire ne sont pas nettement plus faibles que le DES standard.
Une option de la routine /bin/passwd permet de proposer à l'utilisateur des mots_de_passe générés aléatoirement, et qui seront donc plus difficiles à deviner. Ceci appelle deux remarques. Il faut commencer par être certain de ce que le générateur aléatoire balaye un espace plus vaste que les mots_de_passe choisis par les gens eux-mêmes : il serait particulièrement absurde d'utiliser un générateur initialisé par un mot de 16 bits, car il n'y aurait alors que 64.000 mots de passe différents !
Et d'autre part, il est essentiel que les mots de passe restent aisément mémorisables : sinon, les utilisateurs les écriront sur des bouts de papier qu'ils perdront ... ou qu'ils colleront directement sur la console!
