A bit more detail on IOS password hashes

It's no secret that the legacy "type 7" password hashes employed by older IOS devices are easily reversed. Wherever available, type 5 hashing is preferred as it generates a non-reversible MD5 hash. However, the one-way operation of MD5 isn't it's strongest benefit.

Recall that the generation of an MD5-type hash for a local user account is as simple as specifying secret instead of password:

Router(config)# username foo secret MyP4ssw0rd
Router(config)# do sh run | include username     
username foo secret 5 $1$jR5i$.HDBuKq.wIDOn2EYpCPYc0

Listed after the 5 in the above output is the resulting hash stored in the running configuration, but more than simple MD5 is at work here. Borrowed from the UNIX world, this method is referred to as a salted hash, its result composed of three elements separated by dollar signs ($):

• 1 - Denotes a salted hash
• jR5i - 24-bit randomly generated salt value
• .HDBuKq.wIDOn2EYpCPYc0 - MD5 hash

The salt and hash are binary data expressed in the configuration in Base64 encoding for readability. When the user foo needs to authenticate, the cleartext password provided by the human user is concatenated with the 24-bit salt stored in the configuration file. An MD5 hash is then generated from the entire salt+password string; if the resulting hash matches the third element of the stored string, the provided password is deemed valid.

While this may seem unnecessarily complex, the implementation of salting provides two very sizable benefits. First, two users who happen to choose the same password will virtually always receive different hashes. Consider the addition of user bar who is assigned the same password as user foo from the previous example:

Router(config)# username bar secret MyP4ssw0rd
Router(config)# do sh run | include username
username foo secret 5 $1$jR5i$.HDBuKq.wIDOn2EYpCPYc0
username bar secret 5 $1$P9XX$y9d6Aw.t81.CoKvXITCpZ/

Despite being able to authenticate with the same password, the two users were randomly assigned different salts at creation time, removing any similarity between their stored hashes.

The second, and arguably much stronger, benefit of this behavior is the crippling effect it has on space-time tradeoff cracking techniques like rainbow tables. The addition of a stored salt requires a hash to be pregenerated and stored not merely for each possible password (a very large number to begin with), but for every possible salt for every possible password. A 24-bit salt increases the resources required to generate such a hash database by 2²⁴, removing the appeal of such an attack venue.

For the curious, UNIX-like systems use the same hashing method for locally stored user accounts, though typically with a longer salt. In fact, the OpenSSL toolkit can be used to mimic the same operation performed by IOS device. By manually specifying the random salt generated by IOS for user foo, we can recreate the same MD5 hash on a separate computer:

stretch@Sandbox$ openssl passwd -1 -salt jR5i MyP4ssw0rd
$1$jR5i$.HDBuKq.wIDOn2EYpCPYc0