A bit more detail on IOS password hashes
By stretch | Wednesday, July 9, 2008 at 9:40 a.m. UTC
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
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 224, 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
About the Author
Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.
Posted in Tips and Tricks
July 9, 2008 at 12:18 p.m. UTC
I had no idea the $'s meant anything at all until now! :-)
July 9, 2008 at 1:55 p.m. UTC
Great stuff, some very handy info to know.
July 10, 2008 at 1:48 p.m. UTC
thanks a lot for your article. I translate it in French on my website. Tell me if you don't want.
Thanks again, Bye
July 11, 2008 at 5:53 p.m. UTC
nicely done. will be using this info in future classes i teach.
July 12, 2008 at 6:58 a.m. UTC
I notice that the ASA is formatted a little different:
enable password 8Ry2YjIyt7RRXU24 encrypted
any idea what's used for the ASA?
December 19, 2008 at 10:38 p.m. UTC
I'm curious about the format of the hashes on the ASA as well...
enable password xxxxxxxxx encrypted
Anybody have any idea if these are salted MD5 hashes?
December 27, 2014 at 1:57 p.m. UTC
Great info. Currently studying for CCNA Security. Much better explanation than any Cisco Press Books.