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

[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.