Понимание различий между типами паролей и секретных кодов Cisco

[ndemers]

Пытаюсь найти историю внедрения типов 6, 8, 9 в IOS и IOS-XE. Основной вопрос: в какой момент тип 8 был введен в код IOS/IOS-XE? Некоторые из этих функций не поддерживают типы 8 или 9. Функция
Тип пароля 6
Пароль типа 7
Пароль типа 8
Пароль типа 9
линия con
линия vty
сосед bgp
сервер группы aaa
tacacs-сервер
радиус-сервер
имя пользователя
сосед ldp
сосед ISIS
строка сообщества snmpv3?
keychain Для справки: команда enable algorithm-type имеет историю, но не поддерживаемые алгоритмы: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/security/d1/sec-d1-cr-book/sec-cr-e1.html#wp3884449514 enable algorithm-type To set the algorithm type to hash a user password configured using the enable secret command, use the enable algorithm-type command in global configuration mode. To remove the algorithm type, use the no form of this command. enable algorithm-type {md5 | scrypt | sha256} no enable algorithm-type {md5 | scrypt | sha256}
Syntax Description
md5 Selects the message digest algorithm 5 (MD5) as the hashing algorithm.
scrypt Selects scrypt as the hashing algorithm.
sha256 Selects Password-Based Key Derivation Function 2 (PBKDF2) with Secure Hash Algorithm, 26-bits (SHA-256) as the hashing algorithm.
Command Default No algorithm type is defined.
Command Modes Global configuration (config)
Command History
Release Modification 15.3(3)M3
This command was introduced. 15.5(1)S
This command was integrated into the Cisco IOS Release 15.5(1)S.

[g748437]

Здравствуйте
[, @Тим Глен] Вопрос по этой части: В:
Какие типы паролей можно переносить между устройствами? О:
Вы можете копировать и вставлять типы 0, 5, 7, 8 и 9 между устройствами. Я попытался скопировать хэш для типов 5 и 8 с одного коммутатора 2960X и использовать его на другом 2960X. В результате пользователь не смог войти в систему. Поэтому мой вопрос: есть ли какие-либо ограничения или требования, чтобы это работало? Возможно, это связано с конфигурацией, которая влияет на то, как устройства интерпретируют скопированный хэш с другого устройства? Спасибо.

[Tim Glen]

Привет
[, @g748437] Это очень странное поведение. Я уже много лет копирую и вставляю секретные коды, зашифрованные с помощью хэша типа 5. Это всегда работало. Я протестировал копирование и вставку комбинации имени пользователя и секретного кода типа 8 на нескольких устройствах, и, похоже, все работает нормально. Я не знаю о каких-либо ограничениях. К сожалению, я не могу больше помочь, я бы открыл заявку в TAC. Тим

[bim87]

В чем заключается существенное различие между хэшем «стандартного типа 9» и хэшем «сложного типа 9»? Каков конкретный метод определения сложного типа 9 и/или переключения между этими двумя типами? Обновление Нашел свой собственный ответ в
Руководстве по безопасности сетевой инфраструктуры АНБ
: «Если пароль хранится с использованием сложного секрета типа 9, где секретный хеш пароля типа
9 начинается с $14$, это означает, что пароль не менялся в
последнее время. Хеш пароля был преобразован из типа 5 во время предыдущего обновления операционной
системы. Сложный секрет типа 9 следует удалить, изменив пароль
на секрет типа 8 с ключевыми словами алгоритма sha256».

[toormehdi]

Конфигурация переноса, содержащая пароли типа 6 для миграций/обновлений Спасибо,
@Tim Glen
, за предоставление этого полезного ресурса и ответы на мои вопросы ранее. Я хочу поделиться тем, что мы с коллегой сочли очень интересным, и надеюсь, что мы сможем получить от вас или TAC дополнительную информацию/обоснование по этому поводу. Мы находимся в процессе миграции служб IPSEC с
ASR на CSRv У нас были PSK, определенные на ASR, и они были зашифрованы с помощью AES с использованием главного ключа. После того, как мы перенесли конфигурацию, содержащую много зашифрованных PSK типа 6, в CSR, ряд IPSec VPN-туннелей не заработал, и мы задались вопросом, почему. Вот некоторые наблюдения: - Как вы упомянули ранее, не имело значения, определили ли мы главный ключ до копирования и вставки конфигурации. Мы можем определить главный ключ на новом устройстве до вставки конфигурации или после. - Оказалось, что ключи, которые продолжают работать на ASR, но не работают на CSR, — это те, которые были определены на исходных устройствах (т. е. ASR) администратором, введя ключевое слово «key 6» при определении ключей. Это те ключи, о которых я упоминал в предыдущем комментарии, которые по какой-то странной причине остаются в виде открытого текста, хотя и являются типа 6. Таким образом, на ASR с включенным
шифрованием паролей aes Любые пароли / PSK или другие учетные данные для аутентификации, если они введены администратором явным вводом «ключ 0», коробка преобразует их в ключ 6, зашифрует и отобразит с хэшем в рабочей конфигурации
Любые пароли / PSK или другие учетные данные для аутентификации, если они введены администратором путем явного ввода «ключ 6», как понятно, не будут дополнительно шифроваться и сохраняться в рабочей конфигурации в том виде, в котором они есть. Теперь вот что странно, когда речь заходит о коде ASR по сравнению с кодом CSR IOS XR На ASR VPN-узлы могут аутентифицироваться с помощью введенных «ключей 6» PSK, и фактический ключ можно увидеть в рабочей конфигурации, так как они были введены
На CSR VPN-узлы не могли пройти аутентификацию с помощью введенных PSK «ключ 6», как будто CSR пытаются расшифровать эти пароли с помощью главного ключа, поскольку они имеют тип 6, но они были сохранены в рабочей конфигурации в том виде, в котором были введены, как и в ASR
Чтобы это заработало, нам пришлось взять ранее определенные/введенные PSK ключа 6 и вставить их в CSR как PSK ключа 0, чтобы CSR мог выполнить свое волшебное шифрование типа 6, и, к нашему удивлению, это сработало и решило нашу проблему. Таким образом, в заключение, как ASR, так и CSR работают одинаково, когда речь идет о реализации определенных/введенных пользователем учетных данных ключа 6, и они не будут выполнять двойное шифрование/хеширование, но когда дело доходит до фактической аутентификации/верификации, ASR работают с тем, что было введено, и не пытаются расшифровать его, но CSR не работают, поскольку мы предполагаем, что это расшифровка, даже если они никогда не шифровались в первую очередь. Мы задаемся вопросом, имеет ли это какое-либо отношение к версиям IOS XR, является ли вышеуказанное наблюдение результатом изменения функций, усовершенствования или ошибки.

[Rich R]

@toormehdi

«
Мы задаемся вопросом, имеет ли это какое-либо отношение к версиям IOS XR, является ли вышеуказанное наблюдение результатом изменения функций, усовершенствования или ошибки».
На этот вопрос невозможно ответить, не указав точно, какие версии IOS-XE/IOS-XR вы использовали на ASR и CSR. Вы не указали полные номера моделей, поэтому вы могли иметь в виду продукты, на которых работает IOS-XE или IOS-XR, поэтому было бы полезно уточнить, о каких именно продуктах вы говорили. Другая возможность заключается в том, что вы могли скопировать пробелы или специальные символы в конце некоторых зашифрованных ключей, что привело к их недействительности — такая ошибка, которую я неоднократно встречал в прошлом с паролями и ключами.

[nayzaw.win]

Могу ли я проверить, поддерживает ли NEXUS 7710 создание секретного пароля типа 9 при создании имени пользователя? В настоящее время все наши имена пользователей имеют пароль типа 5.

[RAHCDPBC]

Я хотел бы получить разъяснения по поводу этой статьи. В ней говорится, что тип 6 использует AES-128, а тип 8 — SHA-256. Указано, что тип 8 поддается дешифрованию, но SHA-256 — это алгоритм хеширования, который является односторонним. Не следовало ли это указать в типе 6, который использует метод шифрования AES-128?

[Rich R]

@RAHCDPBC
на самом деле там сказано: «
Я не доказал это, но считаю, что популярный инструмент HashCat может расшифровать эти файлы
». В данном контексте термин
«взломан»
может быть более точным, чем «расшифрован».
https://hashcat.net/hashcat/
очень хорошо справляется с взломом хэшей методом перебора — что фактически равносильно расшифровке пароля, поскольку он вычисляет, какая строка дает нужный хэш. Хэши, как вы говорите, являются односторонними, но при наличии достаточного времени, мощности процессора и правильных методов их можно взломать. Напротив, зашифрованный пароль (тип 6) можно мгновенно расшифровать со 100% уверенностью с помощью мастер-ключа AES.

[Ingram-Hu]

Я столкнулся со странным явлением: одна и та же команда «crypto isakmp key 6 701100 address 172.254.5.113», скопированная и вставленная из Cisco 1921 в устройство cisco4321, приводит к сбою установления соседства ipsec. Когда «6» удаляется в Cisco 4321, соседство может быть установлено.

[Rich R]

@Ingram-Hu
701100
не
является зашифрованным ключом типа 6, поэтому это вполне ожидаемо. Учитывая, что вы копируете с 1921, я предполагаю, что это очень старая IOS? Так что либо это было скопировано неверно, либо в очень старой IOS, с которой вы копировали, есть проблема/ошибка. В любом случае, я бы назвал это нормальным, ожидаемым поведением, потому что это не действительный ключ типа 6. Обратите внимание, что ключи типа 6 могут передаваться только между устройствами, которые настроены с идентичным мастер-ключом AES.