Cisco Nexus Password Type 5: Is It the Same as IOS MD5?

The marker 5 in Nexus username ... password ? help does not identify the IOS/IOS XE MD5 implementation. The Nexus 9000 NX-OS 10.2(x) command reference describes input format, while the security guide identifies SHA-256 for local-user passwords. Interpret the marker with its OS, release, command, and stored representation. [1] [2]

1. The reported password-type options

During a local-account review on a device reported as NX-OS 10.2(5), CLI help offered 0 and 5. The question was whether Type 5 meant the same thing as in IOS.

This is a documentation investigation, not a lab reproduction or password migration. The hardware model and full release suffix were not supplied. The findings apply to Nexus 9000 documentation: Cisco names the maintenance release 10.2(5)M and maintains command guidance for 10.2(x). The release notes list no new software features in 10.2(5)M. Check other Nexus families separately. [3]

2. Input format, stored value, and algorithm

Tables scroll horizontally on narrow screens.

Layer	Question it answers	What to inspect
CLI input format	Am I supplying a readable password or an already processed value?	The specific command's help and syntax reference.
Stored representation	What credential form was written into configuration?	The account entry, including its type marker and protected value.
Hashing or encryption algorithm	How is that value created and used?	The platform's security guide, release history, and algorithm documentation.

Clear-text input may be transformed before storage; an imported hash may be retained without rehashing. A command description using "encrypted" does not necessarily mean reversible encryption. Encryption can be reversed with the right key. A password hash verifies a candidate without decrypting the stored value. Attackers can still guess passwords against it, so a one-way hash is not uncrackable.

3. What NX-OS 10.2(x) documents

The command reference defines what follows the number

For username in global configuration, Cisco defines 0 as clear-text input and 5 as already-encrypted input. Clear text is also accepted without an explicit number. The reference does not define 5 as an MD5 instruction for plaintext. [1]

username <user> password 0 <clear-text-password>
username <user> password 5 <existing-supported-hash>

These placeholder examples require release-supported input. The second line needs a valid existing hash, not an ordinary password; IOS hash portability is not established.

The security guide identifies the storage algorithm

The 10.2(x) account guide states that clear-text passwords are processed before storage in running configuration, while already-encrypted input is retained without another step. It identifies 5 as SHA-256-hashed input. [2]

The Nexus 9000 7.x guide dates SHA-256 support to 7.0(3)I2(1) and describes a 64-bit salt and 5,000 iterations. That history does not establish the representation of an upgraded account from its current software version alone. [6]

The reported device's password database, full hash, and sanitized configuration were unavailable. Its account representation and legacy-import behavior remain unverified. The cited 10.2(x) passages do not specify every accepted legacy serialization.

4. IOS / IOS XE password types

IOS/IOS XE separates username ... password from username ... secret. The Catalyst 9500 IOS XE 16.11 reference maps secret markers 5, 8, and 9 to MD5, PBKDF2, and scrypt. Password syntax separately includes 0, 6, and 7. Check the command as well as the OS. [4]

Type	Protection	Reversible?	Typical configuration context	Security position
0	Plain text; no algorithm	Not applicable: readable	Clear-text input; storage depends on command and settings	Avoid exposed credentials in saved configuration
5	MD5-based hash	No	Legacy username secret / enable secret	Weak; migrate where supported
6	AES-128 encryption with a primary/master key	Yes	Supported shared secrets and password fields	Strong reversible protection; key management matters
7	Weak Vigenère-based obfuscation	Yes	Legacy password fields / service password-encryption	Insufficient protection
8	PBKDF2-HMAC-SHA-256	No	Supported username secret / enable secret	Strong password hashing
9	scrypt	No	Supported username secret / enable secret	Strong password hashing

The classifications follow Cisco's Protecting Secrets; confirm syntax and feature support on the target. Cisco generally favors Type 9 over Type 8, subject to requirements such as regulatory constraints. [4] [5]

For Catalyst 9200, the IOS XE 17.18.x guide dates Type 6 username-password support to 16.10.1 and automatic conversion to 16.11.1. Enable and VTY support have separate dates. These are platform-specific examples, not universal IOS/IOS XE introduction dates. Check older images individually. [10]

On supported IOS XE releases, generate a new scrypt secret with this form. It is not NX-OS syntax:

username <lab-user> algorithm-type scrypt secret <new-lab-password>

Importing a numbered secret instead requires an existing, correctly formatted hash. Keep verifier import separate from algorithm selection for new input. [10]

5. IOS / IOS XE and NX-OS comparison

The NX-OS column covers Nexus 9000 local username syntax unless another use is named. "Not documented here" limits the comparison's scope; it does not rule out that number elsewhere in NX-OS.

Password Type	IOS / IOS XE	NX-OS	Algorithm	Reversible	Operational Notes
0	Clear-text input	Clear-text username input in 10.2(x)	No input protection; later processing depends on context	Plaintext itself is readable	Input type does not prove plaintext storage
5	MD5-based secret	Already processed username value; documented SHA-256 in 10.2(x)	Different across these contexts	No for the documented hashes	Never classify a Nexus account as MD5 from the marker alone
6	Supported reversible password/shared-secret fields	10.2(x) AAA guide documents RADIUS/TACACS+ secret protection; not this username selector	AES-128	Yes	Preserve the required encryption key
7	Legacy reversible password protection	Not a local username option in the cited 10.2(x) syntax	IOS/XE: weak Vigenère-based scheme; NX local context: not applicable	IOS/XE: yes	Do not import the IOS meaning into unrelated NX commands
8	PBKDF2 secret on supported releases	Nexus 9000 support added in 10.3(1)F	IOS/XE: PBKDF2-HMAC-SHA-256; NX guide names PBKDF2	No	Not a documented 10.2(x) username option
9	scrypt secret on supported releases	Nexus 9000 support added in 10.3(1)F	scrypt	No	Check downgrade compatibility

Sources: command-specific IOS XE definitions [4], NX-OS input and storage definitions [1] [2], NX-OS AAA encryption [9], and the Nexus 9000 feature history [7]. Identical algorithm names also do not prove cross-platform hash portability or identical parameters.

6. What the 0 and 5 options cover

Context help lists arguments for the current command position, not every cryptographic capability on the device.

The 10.2(x) AAA guide supports AES-128 Type 6 encryption for certain RADIUS/TACACS+ passwords after enabling it and configuring a primary key. That shared-secret use does not make username ... password 6 valid for the cited local-account command. [9]

SNMPv3 SHA choices describe protocol authentication. They do not establish the local CLI password-storage algorithm. [11]

7. Support for newer hash formats

Nexus 9000 Type 8/9 support begins at 10.3(1)F. The 10.3(x) guide separates hash import from generation using pbkdf2 or scrypt and warns that unsupported downgrade images cannot use these formats. [7] [8]

The later 10.5(x) command reference shows:

username <lab-user> password 0 <new-lab-password> scrypt
username <lab-user> password 9 <existing-supported-scrypt-hash>

These examples apply to later releases, not NX-OS 10.2(5). The first generates a verifier from plaintext; the second imports an existing one. [13]

Combine the hardening guide's SHA-256 and Type 8/9 guidance with release-specific support. It does not establish scrypt availability on an older image. [12]

8. Security and compatibility

Flagging every password 5 as MD5 can misclassify Nexus 9000 accounts. Record the platform, image, command context, storage format, and matching documentation.

Cisco's Catalyst 9200 guide calls for migrating Type 5 username and enable secrets to Type 8 or 9. It also warns of downgrade lockout when an image cannot read converted Type 9 values. Check both authentication and recovery compatibility. [10]

Treat a Nexus hash-format change as a compatibility change. The integers 5 and 9 alone cannot justify a production upgrade. Review the algorithm, password quality, configuration access, release suitability, and dependent systems.

9. Device verification

Begin with read-only checks. This fictional hostname illustrates commands, not captured output.

LAB-N9K-01# show version
LAB-N9K-01# show user-account
LAB-N9K-01# show running-config security
LAB-N9K-01# show startup-config security
LAB-N9K-01# show snmp user
LAB-N9K-01# show running-config snmp

The account guide documents the security configuration and user-account checks; the SNMP guide documents the SNMP inspection commands. [2] [11]

1. Record the precise model, NX-OS image, and release suffix.
2. Inspect the relevant account locally. Keep complete hashes and credentials out of screenshots, tickets, and this article.
3. Compare running and startup entries. Record whether they agree; do not silently save a configuration as part of inspection.
4. Identify whether the tested login is local, externally authenticated, or key-based. A successful external AAA login does not test a local password.
5. In a disposable lab on the matching image, inspect context help using the incomplete line username <unused-lab-user> password ?. Cancel the line after reading help; do not submit account creation.
6. If a controlled change is later approved, test with a separate lab account and a new login session. Record observed storage and authentication results rather than predicting them.

The interpretation is documentation-based. Verify acceptance of stored prefixes, imported hashes, and commands on the exact device.

For another example of why configuration text requires careful interpretation, see Cisco Nexus ICMP Unreachable: Why the Command Does Not Appear in Running-Config. That separate article compares configuration display with operational IP interface checks; it is not evidence for password behavior on the release discussed here.

10. Before changing accounts

NX-OS can synchronize CLI/security users and SNMP users. The 10.2(x) SNMP guide describes synchronization of passwords and roles, exceptions for localized/encrypted input, and the desynchronization option introduced in 10.2(2)F. The SSH/Telnet guide also notes that creating a user with encrypted input does not create its corresponding SNMP user. [11] [14]

For the account-review background, read Cisco Nexus SNMPv3 User Appears as a CLI Account: Before You Delete It. That separate article concerns NX-OS 10.6(1); it is not lab evidence for the 10.2(5) observation discussed here.

Proposed change-review checks, not completed tests:

• Access recovery: verify console or out-of-band access and retain a known working administrative session.
• AAA: review method selection, local-account dependencies, roles, and the circumstances under which local authentication is used.
• SNMPv3: identify the active synchronization state and NMS credentials. Plan independent polling and authPriv checks.
• Automation: inventory scripts, backup jobs, controllers, and secrets stores that use the account or parse its configuration.
• Rollback: confirm that the recovery image accepts the stored format. Keep protected backups and any required Type 6 key material under the existing secrets-management process.
• Validation: test a fresh local login, intended privileges, monitoring, and dependent jobs before closing the recovery session or persisting the approved change.

Define the intended operation: changing a password, replacing its stored verifier, and changing a RADIUS/TACACS+ shared key have different effects.

11. Review checklist

• Cisco password numbers must be interpreted in their specific OS, release, and command context.
• For the cited Nexus 9000 10.2(x) local-user documentation, 5 does not establish the IOS MD5 implementation.
• CLI input, stored representation, and cryptographic processing need separate verification.
• New password formats require an authentication, monitoring, automation, and rollback plan.

12. Official Cisco references

1. NX-OS 10.2(x) Command Reference — U Commands
2. NX-OS 10.2(x) Security Guide — User Accounts and RBAC
3. Nexus 9000 NX-OS 10.2(5)M Release Notes
4. Catalyst 9500 IOS XE 16.11 Command Reference — Security (username)
5. Cisco Trust Center — Protecting Secrets on Cisco Network Devices
6. NX-OS 7.x Security Guide — User Accounts and RBAC
7. NX-OS 10.3(x) Security Guide — New and Changed Information
8. NX-OS 10.3(x) Security Guide — User Accounts and RBAC
9. NX-OS 10.2(x) Security Guide — AAA
10. Catalyst 9200 IOS XE 17.18.x Security Guide — Passwords and Privilege Levels
11. NX-OS 10.2(x) System Management Guide — SNMP
12. Cisco NX-OS Software Hardening Guide
13. NX-OS 10.5(x) Command Reference — U Commands
14. NX-OS 10.2(x) Security Guide — SSH and Telnet

Documentation reviewed October 6, 2026. The CLI observation is separate from documented behavior. No production account change or device-level lab reproduction is claimed.