Генератор htpasswd

Где htpasswd нужнее всего

Первый сценарий — закрыть служебный раздел сайта: статистика, бэкапы, админка, черновики, API с ключом. Второй — закрыть отдельный каталог на статическом хостинге, где нет ни PHP, ни панели управления, и единственный доступный механизм это .htaccess. Третий — поднять временный доступ к материалам для клиента или подрядчика на несколько дней и потом отозвать его одной правкой файла. Четвёртый — устаревшее приложение, которому нужен файл паролей в формате, который ожидает конкретная программа, а не сам Apache.

Отдельно стоит вариант с htpasswd Apache на уровне сервера, а правила для .htaccess разобраны в подробной инструкции по .htaccess: когда нужно завести учётную запись для скрипта или для CI, которая ходит на сайт по basic-аутентификации. Тогда файл паролей становится машинным секретом, и к нему предъявляются требования к хранению, как к любому паролю. В таких случаях удобнее сгенерировать файл на сервере и отдать его в менеджер секретов, а не держать в репозитории. Про генератор .htaccess — там собираются правила редиректов, HTTPS и запрета доступа, которые обычно идут в одном файле.

• Закрыть служебный каталог: статистика, бэкапы, черновики
• Защита папки на статическом хостинге, где нет других механизмов
• Временный доступ к материалам для клиента или подрядчика
• Учётные записи для скриптов, CI и мониторинга
• Совместимость со старым приложением, ждущим готовый файл паролей

Частые ошибки при настройке htpasswd

Самая частая — перенести блок из Apache 2.2 на сервер 2.4 и удивляться, что защита не работает или, наоборот, пускает всех. Второе место — указать в AuthUserFile относительный путь или путь от каталога сайта: Apache ждёт абсолютный путь от корня файловой системы. Третье — забыть про права на файл и положить его в общий каталог, доступный по HTTP, тогда файл паролей скачает кто угодно.

Дальше — попытка угадать пароль по схеме {SHA}: это безнадёжно, потому что функция односторонняя. Ещё ошибка — сгенерировать строку с паролем в открытом виде и записать её в файл: Apache её не примет. И последняя — забыть про HTTPS: при basic-аутентификации логин и пароль передаются в base64, то есть почти в открытом виде, и без шифрования канала их перехватят по дороге. Пароль по HTTPS всё равно стоит передавать, но он хотя бы не лежит на проводе.

• Перенести блок с Order и Deny на сервер Apache 2.4
• Указать в AuthUserFile относительный путь
• Положить файл паролей в каталог, доступный по HTTP
• Пытаться подобрать пароль, зная его SHA-1
• Включить basic-аутентификацию без HTTPS

Разбор примера: как собрать работающую связку

Шаг первый — пароль. Вводим его в поле и получаем строку вида admin:{SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=. Это base64 от двадцати байт хеша SHA-1, и именно в таком виде Apache ожидает увидеть пароль в файле. Логин в строке пишется ровно тот, который вводили при входе, и двоеточие в нём использовать нельзя — иначе строка распадётся на части не там.

Шаг второй — файл на сервере. Создаём его командой htpasswd -c, вставляем сгенерированную строку, ставим права 640 и выдаём владельца веб-серверу. Шаг третий — .htaccess рядом с защищаемым каталогом: четыре директивы, Require valid-user, и путь к файлу паролей. Шаг четвёртый — проверка: открыть защищённый адрес и убедиться, что сервер спросил логин и что вход работает.

Шаги с второго до четвёртого выполняет браузер, остальное — на сервере, где Apache и должен проверять пароль.

Apache 2.2 и 2.4, Require и Order, HTTP и HTTPS

Главное отличие между поколениями Apache — в синтаксисе авторизации. В 2.2 доступ описывался списком правил: Order allow,deny задавал порядок просмотра, Allow from all или Deny from перечисляли адреса, а замыкала всё конструкция Require. В 2.4 осталась только Require, и правила применяются одновременно, а не по очереди. Отсюда практический совет: если сервер на 2.4, берите Require valid-user, если на 2.2 — не выбрасывайте Order и Deny, пока не переехали.

Второе отличие — транспорт. Basic-аутентификация отправляет логин и пароль в заголовке Authorization, закодированные в base64, то есть без всякого шифрования. По HTTP это значит, что пароль виден любому, кто слушает канал. HTTPS здесь не улучшение, а обязательное условие: иначе защита работает только против тех, кто не читает сеть. Третье отличие касается формата файла: Apache 2.4 умеет работать и с файлами паролей, созданными в других программах, — тут важно только, чтобы схема хеша была той, которую сервер умеет проверять.

• Apache 2.4: Require valid-user вместо Order, Allow и Deny
• Apache 2.2: старый синтаксис ещё обязателен до перехода
• Basic-аутентификация без HTTPS передаёт пароль почти в открытом виде
• Формат файла паролей должен совпадать с тем, что умеет проверять сервер
• Схема {SHA} без соли выдаёт одинаковые хеши для одинаковых паролей