Ответ на вопрос легко получается из понимания как работает данный механизм. Вот ссылка на
rfc. Из него мы понимаем, что механизм крайне примитивен, логин и пароль конкатенируются как строки и получившуюся строку мы кодируем с помощью алгоритма base64, потом устанавливает http header с этой строкой и отправляем на сервер. Далее мы можем взять технологию ssl для http протокола и согласно его механизму, можем узнать, что кроме имени сервера ( если взять технологию eSNI, то имя сервера так же шифруется), все данные http протокола шифруются более надёжно (но зависит от настроек клиента/браузера и сервера), этот механизм позволит уберечь от перехвата данных по пути к серверу. Следующая проблема в хранении в открытом виде логинов и паролей на сервере, чтобы защитить их есть несколько способов, мы используем https сервис который ходит по ssl в ad/ldap и там проверяет нашу пару. Количество обращений к серверу у нас ограничено с одного ip адреса на веб сервере, количество обращений с одним логином у нас ограничено нашим ad/ldap из одного источника. Сервис который ходит в ad/ldap отделён от веб сервера. Сервис который ходит в ldap имеет реквизиты доступа только в рантайме и в случае падения он перезапускается оокестратором который забирает реквизиты доступа к ldap из vault сервиса, для которого так же установлено ограничение на количество запусков.
Так же у нас есть hsts для предотвращения подмены ssl сертификата на клиенте, и на стороне сервера мы ограничиваем алгоритмы ssl оставляя только максимально надёжные. Это не идеально всё и есть более продвинутые методы, которые например сейчас внедряет фейсбук ( есть ещё аналогичный сервис от русскоязычных разработчиков ).