Кратко

  • Текущая HTML-страница AFRINIC WHOIS Crypt объявляет POST-форму на тот же источник. Поле с подписью «Password» имеет тип type="text" и имя отправки plaintextpassword. В ходе исследования в него ничего не вводили и форму не отправляли.
  • Руководство для участников говорит, что AFRINIC следует передавать только хеш, а открытый пароль участник должен хранить у себя. Удалённому этапу между вводом и хешем нужна проверяемая схема обработки, а не недоказанное обвинение в утечке.

У хорошего хеша есть неприятное свойство: он выглядит как завершённое доказательство. Строка BCRYPT может быть пригодна для атрибута auth: и не раскрывать исходный пароль при обычном просмотре базы. Но по ней невозможно восстановить маршрут исходного значения. Итог ничего не сообщает о том, где пароль существовал за мгновение до вычисления и какие компоненты имели к нему доступ.

Публичная страница инструментов WHOIS у AFRINIC направляет участника в отдельное приложение WHOIS Crypt для получения BCRYPT-PW. Исходный HTML приложения, сохранённый 14 сентября 2026 года, достаточно откровенен. У формы идентификатор myForm, метод POST и относительное действие ?lang=en#cli. Подпись «Password» связана не с HTML-полем пароля, а с input type="text". Идентификатор и имя отправляемого параметра совпадают: plaintextpassword. Кнопка называется «Generate hash».

Мы не проверяли работу формы. В поле не вводили ни настоящий пароль, ни синтетическое значение. Кнопку не нажимали, сетевую транзакцию не перехватывали, серверный обработчик не вызывали и объекты WHOIS не меняли. Доказательство относится к опубликованной инструкции для браузера, а не к выполненной операции.

Стандарт HTML позволяет точно прочитать эту инструкцию. Форма содержит элементы управления, данные которых могут быть отправлены серверу для дальнейшей обработки. В версии стандарта для разработчиков параметры в теле HTTP POST приводятся как обычная схема серверной обработки. Относительный адрес на странице разрешается в том же источнике whois-web.afrinic.net. Значит, при работе в соответствии с разметкой браузер передаст AFRINIC прикладное значение поля с говорящим именем до того, как появится хеш.

Это доказанная поверхность приёма, но не доказанное хранение. Сервер может держать значение только в памяти, немедленно вычислять BCRYPT, исключать его из журналов и трассировки и уничтожать до ответа. В иной конфигурации универсальный прокси, сборщик ошибок или система наблюдаемости может копировать тело запроса, если поле не исключено отдельно. Мы не видели серверного кода, конфигурации прокси, логов, памяти, трасс или материалов об инцидентах. Выбирать один сценарий как факт нельзя.

Не менее важно правильно употреблять слово «открытый». URL инструмента использует HTTPS. TLS предназначен для защиты от прослушивания и изменения данных между конечными точками. Ни один сохранённый источник не показывает пароль, читаемый посторонним наблюдателем в сети. Здесь открытым называется прикладное значение до хеширования, а не незашифрованный сетевой пакет. Защищённый канал доставляет значение получателю; он не превращает удалённого получателя в локальную функцию на устройстве участника.

Именно поэтому значок замка отвечает лишь на часть вопроса. Он важен как положительное свидетельство транспортной защиты. Однако он не определяет срок жизни значения на конечной точке, правила журналирования или круг исполняемого в документе кода. Транспорт, обработка и сохранение — последовательные, но самостоятельные границы.

Главный противовес содержится в собственном справочнике AFRINIC для участников. В разделе о maintainer-объекте рекомендуется создать BCRYPT-хеш открытого пароля. Далее сказано, что с AFRINIC нужно делиться только значением хеша, а открытый пароль участники должны безопасно хранить у себя. Это похоже на распределение владения: секрет остаётся у участника, проверочное значение получает реестр.

Справедливое толкование может согласовать руководство с серверным генератором. Возможно, «передавать только хеш» означает лишь окончательное содержимое WHOIS-объекта: исходный пароль не должен попасть в auth:, хотя вспомогательный сервер кратковременно принимает его для расчёта. Такой смысл реален, и статья не превращает неоднозначность в обвинение.

Но читатель вправе понять ту же фразу шире: исходное значение вообще не покидает его устройство. Тогда удалённая POST-форма реализует другую модель. Публичные материалы не указывают, какое обещание имелось в виду. Руководство описывает конечный артефакт, форма — промежуточный поток, а связующего пояснения у поля нет.

Это не доказательство правового нарушения, инцидента с персональными данными или ложного заявления. Обнаружен более узкий недостаток: слово «делиться» не имеет операционного масштаба. Оно может означать «не записывать в WHOIS», «не сохранять после вычисления» либо «не отправлять с устройства». Для каждой формулировки нужен свой контроль.

Тип поля показывает ещё одно решение. В HTML состояние type="password" предназначено для чувствительного текста и создаёт элемент, скрывающий ввод. type="text" — обычное текстовое поле. Зафиксированная страница использует второе. Это не значит, что кто-то подсмотрел пароль, что значение утекло или что параметры BCRYPT слабы. Известно только, что браузеру не задан режим маскирования.

Замена типа была бы полезной, но недостаточной. Она уменьшила бы случайную видимость и точнее сообщила браузеру назначение поля. Получатель POST остался бы прежним. Не появились бы ни правило удаления, ни запрет на логи, ни изоляция скриптов. Исправление интерфейса нельзя выдавать за доказательство всего жизненного цикла.

В тот же документ загружается исполняемый код. Страница получает Cloudflare Turnstile с challenges.cloudflare.com, а также jQuery, Mustache и main.js по локальным путям. Рекомендации OWASP рассматривают сторонний JavaScript как границу управления изменениями и чувствительными данными: код в контексте страницы потенциально взаимодействует с документом, а поставщик способен менять доставляемую версию.

Это общая модель риска, а не находка о Cloudflare. Наличие тега Turnstile не доказывает, что компания читала, принимала, сохраняла или передавала plaintextpassword. Фактическое выполнение не исследовалось. Обоснованный вывод лишь в том, что права стороннего скрипта и его отделение от чувствительного поля должны войти в проверяемое описание.

Статический анализ связанного локального main.js убирает другую удобную догадку. В сохранённой версии нет myForm, plaintextpassword, BCRYPT или обработчика генератора Crypt. Файл инициализирует другую панель при наличии create-container, загружает шаблоны WHOIS, редактирует атрибуты и отправляет объект вместе с отдельным паролем редактора на функцию сохранения.

Этот код относится к иному интерфейсу. Он не показывает клиентское хеширование поля Crypt перед отправкой. В то же время молчание одной программы не сертифицирует jQuery, Mustache, Turnstile, расширения браузера, динамический ответ, будущую версию или сервер. Отрицательный результат имеет ровно тот охват, который был проверен.

Действующая политика конфиденциальности AFRINIC даёт положительный институциональный контекст. Она называет AFRINIC контролёром данных, включает услуги WHOIS в перечень каналов сбора, ограничивает доступ назначенными сотрудниками, возлагает защитные обязанности на третьи стороны и связывает срок хранения с организационными или правовыми целями. Неверно было бы утверждать, что публичных обязательств нет.

Но общая политика не является квитанцией для конкретного поля Crypt. Она не отвечает, исключает ли обратный прокси тело POST, захватывает ли обработчик ошибок параметры, берёт ли система трассировки образцы, содержит ли диагностический пакет ввод и сколько исходное значение живёт в памяти. Принцип управления и доказательство конкретного пути дополняют друг друга, но не взаимозаменяемы.

Журналирование превращает вопрос в понятный тест. OWASP относит пароли аутентификации к данным, которые обычно не следует записывать напрямую. Если событие всё же необходимо сохранить, чувствительное содержимое предлагается удалить, замаскировать, очистить, хешировать или шифровать. Мы не читали ни одного журнала AFRINIC, поэтому не заявляем, что пароль где-либо записывается.

Вместо этого публичное имя поля создаёт проверяемое условие: значение plaintextpassword не должно встречаться в журналах приложения и прокси, распределённых трассах, аналитических событиях, отчётах об ошибках и материалах поддержки. Ответ «используется HTTPS» этого не подтверждает: TLS ограничивает наблюдателей на пути, но не копии внутри принимающей стороны.

Нужна проверка и путей отказа. При удачном ответе значение может корректно удаляться, а при тайм-ауте, неверном вводе, отклонении Turnstile или исключении может включиться общий диагностический механизм. Нет доказательств, что у AFRINIC происходит именно так. Это причина требовать охват нормальных и аварийных ветвей, а не основание приписать сбой.

Правильный формат BCRYPT тоже не закрывает вопрос. Он подтверждает часть вычисления, но не показывает, копировалась ли строка системой аналитики, оставалась ли в очереди повтора, была ли доступна скрипту или вошла в поддержку. Криптографическая корректность проверочного значения и минимизация исходного пути — разные свойства.

Существуют по меньшей мере две последовательные архитектуры. Первая вычисляет хеш в браузере. Ей нужны обозримый код, контролируемые зависимости, проверка целостности, изоляция чувствительного элемента от стороннего кода и подтверждение, что исходное значение не входит в исходящие запросы. Надпись «локально» сама по себе ничего не докажет.

Вторая сохраняет серверное вычисление. Тогда страница до ввода сообщает, что endpoint AFRINIC получает по HTTPS новый, нигде не повторяемый пароль, использует его лишь для хеширования, исключает из логов и трасс, не удерживает открытое значение и ограничивает доступ обработчиков. Удалённая служба не является недостатком по определению. Необозначенные получатель, срок и копии — вот измеримый пробел.

Руководство должно следовать выбранной архитектуре. Если «только хеш» относится лишь к WHOIS-объекту, это стоит написать. Если фраза охватывает весь путь создания, удалённый POST ей не соответствует. При любом варианте нельзя вводить действующий или повторно используемый пароль ради проверки генератора. В этом исследовании так не поступали.

Полезная квитанция должна иметь версию и дату. Форма, Turnstile, обратный прокси, сборщик исключений и аналитическая платформа меняются независимо. Проверка старой цепочки не подтверждает новую. После существенного изменения достаточно повторить разрешённый опыт с синтетическим значением, перечислить охваченные компоненты и зафиксировать исключения. Публиковать сам маркер или внутреннюю конфигурацию не требуется: участнику нужны границы, а не секреты защиты.

Такой документ соединит три уровня, которые сейчас можно прочитать лишь по отдельности. Политика конфиденциальности задаёт цели и ответственность, руководство объясняет обращение с maintainer-объектом, а техническая квитанция описывает жизнь конкретного поля. Когда они ссылаются на одну и ту же архитектуру, слова «хранить пароль у себя» становятся не интуицией пользователя, а проверяемым свойством услуги.

Стоит также разделять заверение и наблюдение. «Мы не журналируем пароли» — заверение учреждения. Отсутствие разрешённого синтетического маркера в каждом названном хранилище — контролируемое наблюдение для конкретной версии. Первое распределяет ответственность, второе связывает её с реализацией. Ни одно не сертифицирует все будущие изменения, но вместе они дают участнику основание сильнее, чем итоговый хеш без истории происхождения.

Квитанция должна перечислять и пробелы. Проверка только успешного ответа не охватывает тайм-ауты; изучение журнала приложения не говорит о прокси; статический просмотр нынешнего main.js не отвечает за другие скрипты. Такая оговорка не ослабляет доказательство. Она не позволяет ограниченному результату превратиться при пересказе в широкое обещание безопасности всей системы.

Источники