Кратко

  • RFC 3112 разделил производное от пароля значение на scheme, сведения о схеме и authentication value. Правило могло вернуть TRUE, FALSE или Undefined, но это был результат сравнения, а не аутентификация LDAP-ассоциации.
  • Для аутентификации документ требовал Bind. Поскольку атрибут допускал несколько значений, обладатель права записи мог добавить второй действующий пароль, не отключая известный пользователю секрет.

Истина из другого автомата состояний

Клиент передаёт пароль правилу matching. Сервер находит сохранённое значение, читает scheme и salt, вычисляет результат и отвечает true. Секрет совпал. Однако клиент ещё не аутентифицирован в каталоге.

Эта граница определяет историческое значение RFC 3112. Документ «LDAP Authentication Password Schema» вышел в мае 2001 года со статусом Informational и предложил хранить производную информацию вместо самого пароля, предполагавшегося тогдашним применением userPassword. Он определил синтаксис, два правила сравнения, атрибут возможностей в root DSE и вспомогательный object class. Создав удобную проверку, RFC тут же ограничил её смысл: успешный authPasswordMatch через Compare или Search недостаточен для доступа. Для аутентификации требовался Bind.

Операции отвечали на разные вопросы. Matching выяснял, согласуется ли строка хотя бы с одним сохранённым значением по объявленному методу. Bind решал, принимает ли сервер authentication identity для этой LDAP-ассоциации. Затем access policy определяла действия authorization identity. Приложение за пределами каталога сохраняло решение о своей бизнес-операции.

Если журнал сводит всё к «успешному входу», доказательство исчезает. Match возможен без Bind. Bind может пройти, а запись — быть запрещена. Разрешённое чтение LDAP не доказывает завершение видимой пользователю операции.

Значение называло свой способ вычисления

authPasswordSyntax содержал три чувствительных к регистру компонента, разделённых знаком доллара: scheme, authInfo и authValue. Первый называл механизм, второй часто содержал salt в base64, третий — производный материал.

Так каталог мог поддерживать несколько механизмов. RFC определил MD5 и SHA1; частные имена должны были начинаться с X- или использовать OID. supportedAuthPasswordSchemes, допустимый только в root DSE, объявлял названия, которые сервер считал поддерживаемыми.

Объявление не было трассировкой. Оно не показывало, какая схема выбрана для конкретной аутентификации, кто записал значение, уникален ли salt, защищён ли канал, какие значения проверялись и завершился ли Bind. Capability не равнялась execution evidence.

Дата также существенна. Схемы MD5 и SHA-1 из RFC 3112 строили digest от конкатенации пароля и salt. Salt должен был иметь не менее 64 bit, реализации — поддерживать до 128 bit. Это описание 2001 года, а не современная рекомендация. RFC 8018 сделал salt и число итераций явными параметрами password-based cryptography; RFC 9106 определил memory-hard функцию Argon2 и предпочёл Argon2id для password hashing и derivation. Поздние документы не меняют старую норму, но объясняют, почему фраза «безопасно хешировано» без точной схемы и стоимости ничего не доказывает.

Равенство кодировки, проверка пароля и Bind

authPasswordExactMatch сравнивал уже закодированные компоненты. Одинаковые scheme, authInfo и authValue давали true; отсутствие совпадения — false; прочие случаи — undefined. Это было равенство представлений.

authPasswordMatch принимал пароль через extensible-match filter и применял scheme каждого сохранённого значения. Одного совпадения хватало для true; лишь отказ всех значений давал false; невозможность завершить тест возвращала Undefined.

Ни один ответ не устанавливал личность человека за клавиатурой. True не доказывал, кто контролирует канал и имеет ли право сравнивать. False не доказывал правильность entry или отсутствие внешнего credential store. Undefined не означал неправильный пароль: это отдельный факт, что сервер не смог решить.

Требование Bind не позволяло сравнению присвоить лишние полномочия. RFC 4511 позднее описал Bind в пересмотренном LDAP. RFC 4513 разделил authentication identity и authorization identity. Вторая могла выводиться из первой или заявляться отдельно подходящим механизмом, если сервер разрешал такое представительство.

Поэтому даже Bind не был всеобщим разрешением. Аутентификация определяла, кого сервер принял в ассоциации; авторизация — что эта identity может делать с объектом; приложение — итоговое действие.

Несколько значений — несколько возможных дверей

authPassword мог иметь несколько значений. Для выбранных schemes сервер должен был рассматривать релевантные значения, и одного совпадения могло хватить. Это помогало миграции, но превращало write access в возможность создать новый вход.

RFC прямо описал атаку: получивший запись может добавить значение, не отключая настоящий пароль пользователя. Жертва продолжает входить как обычно; нет заметного reset или lockout; дополнительная дверь остаётся.

Финальный snapshot entry не объясняет происхождение. Два значения не сообщают, кто добавил каждое, какая policy это разрешила и какое предполагалось удалить. Нужно сохранять add, replace и delete; writer и authorization identity; fingerprint; scheme; параметры; replication и retirement.

RFC 3062 уже определил Password Modify extended operation. По правилам сервера она могла определить объект, принять или создать новый пароль и выбрать хранение. RFC 3112 сочетался с ней, но один атрибут не был полным account lifecycle.

Сервер мог также объединять authPassword, userPassword и внешний store. Наблюдение или удаление одного значения не раскрывало и не отзывала все пути аутентификации.

Производное значение оставалось секретом

RFC не считал one-way функцию разрешением на публикацию. Производные значения следовало защищать как clear-text password: слабость алгоритма, ошибка реализации или offline attack могли превратить утечку в доступ. Передача без конфиденциальности настоятельно не рекомендовалась.

Assertion для authPasswordMatch также требовал защиты: он нёс пробный пароль к серверу. Открытый канал мог его раскрыть, слишком доступное сравнение — создать oracle для угадывания.

Вычислительная стоимость создавала availability risk. Дорогая схема повышает цену перебора, но позволяет клиенту тратить CPU сервера. Rate limit, concurrency budget, timeout и право сравнения входят в реальную политику. Название scheme не доказывает их наличие.

Контекст изменился, граница сохранилась

RFC 3112 сравнивал подход с userPassword в контексте RFC 2251, RFC 2252 и RFC 2256. Это не вечное утверждение. RFC 4519 позднее уточнил, что значения userPassword не обязаны быть clear text или пригодными для Bind. Реализации применяли собственные форматы.

Статус Informational не доказывает внедрение. Записи RFC Editor и IETF Datatracker подтверждают публикацию и историю. RFC 2829 и RFC 4513 задают security model; RFC 4511, RFC 4517 и RFC 4519 показывают позднюю линию протокола, matching и schema. Ни один источник не доказывает использование authPassword конкретным каталогом.

Долговечным оказался порядок доказательств. Чтобы утверждать, что пользователь «вошёл», надо отдельно сохранить entry и mutation history, scheme, salt и параметры, право на Compare/Search, канал, запрос и true/false/undefined, фактически проверенные значения, Bind request и response, authentication/authorization identities, следующую операцию, access result и outcome приложения.

Пароль мог совпасть точно. RFC 3112 понимал: эта истина не вправе говорить от имени Bind.

Источники

  1. https://www.rfc-editor.org/rfc/rfc3112.html
  2. https://www.rfc-editor.org/info/rfc3112
  3. https://datatracker.ietf.org/doc/rfc3112/
  4. https://www.rfc-editor.org/rfc/rfc2251.html
  5. https://www.rfc-editor.org/rfc/rfc2252.html
  6. https://www.rfc-editor.org/rfc/rfc2256.html
  7. https://www.rfc-editor.org/rfc/rfc2829.html
  8. https://www.rfc-editor.org/rfc/rfc3062.html
  9. https://www.rfc-editor.org/rfc/rfc4511.html
  10. https://www.rfc-editor.org/rfc/rfc4513.html
  11. https://www.rfc-editor.org/rfc/rfc4517.html
  12. https://www.rfc-editor.org/rfc/rfc4519.html
  13. https://www.rfc-editor.org/rfc/rfc8018.html
  14. https://www.rfc-editor.org/rfc/rfc9106.html