IOS: « enable password » vs « enable secret »

Petite piqûre de rappel, cela ne fait jamais de tort … Au cours des formations dont je m’occupe, je m’aperçois souvent que l’utilité et l’existence de ces deux commandes reste assez floues malgré leur apparente simplicité. Voici donc en quelques lignes ce dont il s’agit…

Tout d’abord, rappelons que ces eux commandes, à savoir « enable password » et « enable secret », ont toute deux la même fonction: définir le mot de passe pour accéder au mode privilégié du CLI.

R1>enable
Password:
R1#

La question qui en découle est donc la suivante: « Pourquoi deux commandes pour faire la même chose ? ». La réponse est simple et réside dans la manière ou l’IOS encode le mot de passe dans la config de l’équipement.
Avec « enable password » le mot de passe défini est encodé en clair dans la config.

R1(config)#enable password cisco

R1#show running-config
Building configuration...
Current configuration : 470 bytes
!
version 12.4
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
!
hostname R1
!
!
!
enable password cisco
!
!

Tandis qu’avec la commande « enable secret » le mot de passe est stocké sous forme de hashage MD5, ce qui rend cette version beaucoup plus sécurisée…

R1(config)#enable secret cisco

R1#sh running-config
Building configuration...
Current configuration : 517 bytes
!
version 12.4
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
!
hostname R1
!
!
!
enable secret 5 $1$mERr$hx5rVt7rPNoS4wqbXKX7m0
!

Notez que dans la config le chiffre « 5 » précède la version « cryptée » du mot de passe. Le but ici est de permettre de copier la commande telle qu’elle apparaît dans la config sur un autre équipement. Ainsi l’autre équipement saura que le mot passe donné dans la commande est en fait une version cryptée et qu’il ne doit pas la repasser par le hashage MD5.
Reste maintenant à savoir pourquoi ces deux commandes existent … He bien rien de plus banal, c’est tout simplement pour assurer une rétro-compatibilité des config. De sorte que si vous copiez la config d’un équipement qui ne supporte pas la version « enable secret » vers un nouvel équipement, ce dernier puisse quand même accepter l’ancienne version.