Password Handling

YANG Extensions Affecting Passwords

The YANG extension ncx:password can be used in a YANG module (leaf definition) to identify password fields.

The "obj_is_password" function will be true for these objects, and any object that uses the “crypt-hash” typedef from the iana-crypt-hash.yang module.


The "ncx:password" extension is deprecated and should not be used. It does not prevent disclosure of passwords in all cases. Use the "crypt-hash" data type instead.

The OpenConfig YANG extension oc-ext:openconfig-hashed-value can be used in a YANG module (leaf definition) to identify a password field with strict requirements for non-disclosure.

The initial cleartext password string is converted to a hash right away and only the hash is stored or displayed after that.

This extension should be used instead of "ncx:password" if the "crypt-hash" data type cannot be used.

Passwords and crypt-hash

Objects that are type “crypt-hash” will be processed by the server according to the following typedef from iana-crypt-hash.yang:

typedef crypt-hash {
  type string {
    + '|$1$[a-zA-Z0-9./]{1,8}$[a-zA-Z0-9./]{22}'
    + '|$5$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{43}'
    + '|$6$(rounds=\d+$)?[a-zA-Z0-9./]{1,16}$[a-zA-Z0-9./]{86}';
    "The crypt-hash type is used to store passwords using
     a hash function.  The algorithms for applying the hash
     function and encoding the result are implemented in
     various UNIX systems as the function crypt(3).

     A value of this type matches one of the forms:

       $0$<clear text password>
       $<id>$<salt>$<password hash>
       $<id>$<parameter>$<salt>$<password hash>

     The '$0$' prefix signals that the value is clear text.  When
     such a value is received by the server, a hash value is
     calculated, and the string '$<id>$<salt>$' or
     $<id>$<parameter>$<salt>$ is prepended to the result.  This
     value is stored in the configuration data store.
     If a value starting with '$<id>$', where <id> is not '0', is
     received, the server knows that the value already represents a
     hashed value and stores it 'as is' in the data store.

     When a server needs to verify a password given by a user, it
     finds the stored password hash string for that user, extracts
     the salt, and calculates the hash with the salt and given
     password as input.  If the calculated hash value is the same
     as the stored value, the password given by the client is

     This type defines the following hash functions:

       id | hash function | feature
        1 | MD5           | crypt-hash-md5
        5 | SHA-256       | crypt-hash-sha-256
        6 | SHA-512       | crypt-hash-sha-512

     The server indicates support for the different hash functions
     by advertising the corresponding feature.";
    "IEEE Std 1003.1-2008 - crypt() function
     RFC 1321: The MD5 Message-Digest Algorithm
     FIPS.180-4.2012: Secure Hash Standard (SHS)";

Values of this datatype that match the “$0$” format will be converted and stored as a hash, according to the typedef specification.

  • The agt_profile field "agt_min_password_len" field will be used to enforce a minimum password length for the crypt-hash data type. The default value is 8.

  • The agt_profile field "agt_crypt_hash_prefix" field will be used to select the hash function that will be used for the conversion of $0$ format strings. The default value is SHA-512 ($6$).

  • The obj_is_password() function will be true for any crypt-hash data node

Password Storage

  • The "crypt-hash" data type must be used (with mode 5 or 6) to avoid exposure of a cleartext password by the client in the initial password configuration edit request.

  • Otherwise, the "crypt-hash" data type (mode 0) or the "openconfig-hashed-value" extension should be used.

There are more details about password storage and password exposure during logging in the KnowledgeBase article Passwords Stored in YANG Data