Правильный.использование помощью пароля через htpasswd

какой уровень безопасности это обеспечивает?

.htpasswd не обеспечивает большую безопасность сам по себе. То есть, он предоставляет механизм входа в систему, и Apache не будет отвечать без надлежащих учетных данных, но если отдельно не настроен, ничего об обмене не зашифровано (или даже запутано). Например, прослушивание GET запрос Wireshark дает вам хороший вид всех заголовков, отправляемых клиентом, в том числе:

Authorization: Basic d3BhbG1lcjp0ZXN0dGVzdA==

"d3BhbG1lcjp0ZXN0dGVzdA== " будучи просто закодированной формой base64 "wpalmer:testtest". В эти дни хакер (или, скорее, вирус) может сидеть на общественном WiFi-соединении и регистрировать любые запросы, содержащие Authorization: для последующего прочтения. В общем, отправка любой аутентификационной информации по незашифрованному HTTP-соединению считается плохой идеей, даже если вы находитесь по проводу или защищенному WiFi. Он не будет, например, отвечать требованиям разъем PCI Соответствие если вы хранили данные о клиентах, платежную информацию и т. д. За .htpasswd замок.

добавьте https в микс,и вы полностью устраните эту конкретную проблему...

.htpasswd аутентификация, реализованная Apache httpd, не обеспечивает какой-либо формы ограничения скорости или защиты от грубой силы. Вы можете сделать столько одновременных попыток угадать пароль, сколько Apache готов обслуживать одновременные страницы, и Apache ответит успех / неудача, как только это возможно. Вы можете использовать что-то вроде кроме того, fail2ban ограничить количество неудачных попыток можно до того, как клиент будет заблокирован от разговора с сервером, но это не обязательно обеспечит какую-либо полезную защиту от ботнета, который может автоматически нацеливаться на ваш сервер из тысяч уникальных адресов. Это может привести к решению " оставляю ли я себя уязвимым для попыток пароля из ботнетов, или я оставляю себя уязвимы для атак типа "отказ в обслуживании", когда вся учетная запись заблокирована из-за сбоев нескольких клиентов?"

эти углы атаки могут быть ограничены путем добавления ограничений на основе IP к вашему .htaccess файл, позволяющий подключаться только с определенных адресов. В зависимости от того, как вы работаете, это может быть неудобно, но это также серьезно ограничивает типы угроз, к которым вы будете уязвимы. Вы все еще будете в опасности от кого-то специально нацеленного на вас сайт или инфекция на части самой сетевой инфраструктуры. В зависимости от типа контента, который вы защищаете, это может быть "достаточно хорошим". Примером такого ограничения является:

Order deny,allow
Deny from all
Allow from 127.0.0.1

это означает, короче говоря, "разрешать подключения только локальным хостом". Строчка за строчкой, это значит:

• Order deny,allow определяет порядок, в котором обрабатываются правила, причем последнее совпадение имеет приоритет.
• Deny from all начните с предположения, что все клиентам отказано
• Allow from 127.0.0.1 если у клиента есть IP 127.0.0.1, тогда разрешено

в некоторой степени ограничения на основе IP также защитят вас до такой степени,что HTTPS может считаться необязательным. Злоумышленники / вирусы все еще могут видеть ваши учетные данные, но им сложнее использовать эти учетные данные на самой странице. Опять же, это не будет совместимым с PCI, и это не будет подходящим для "важной" информации, но есть некоторые ситуации для что можно считать "достаточно хорошим". Имейте в виду, что многие люди повторно используют учетные данные на нескольких сайтах, поэтому неспособность защитить данные для входа обычно считается очень опасным для пользователя, даже если сам сайт защищен.

наконец,.htaccess сам файл-это немного ответственность. См. ответ на вопрос " Должны ли они находиться за пределами общедоступного каталога?- подробнее об этом.

можно ли его обойти легко?

нет. Нет никаких оснований ожидать, что сервер, при правильной настройке никогда не требует логин для доступа к защищенному контенту. Хотя http Basic authentication имеет свои недостатки, Apache httpd очень надежен и является одним из самых тщательно протестированных программных продуктов в мире. Если вы скажете Apache, что для доступа к определенному контенту требуется базовая аутентификация HTTP, это будет необходимо.

если Apache по умолчанию делает не позволяйте пользователям напрямую обращаться к одному из двух файлов, должны ли они находиться вне общего каталога?

есть несколько моментов. Во-первых, Apache делает не по умолчанию для предотвращения доступа к любой из этих файлов. Многие дистрибутивы Apache httpd включают начальную конфигурацию, которая предотвращает доступ (используя правила "Deny from all") к, в зависимости от дистрибутива, .htaccess/.htpasswd файлы .ht* файлы, или .* файлы. Это очень обычно, но есть много причин, почему это может быть не так. Вы можете добавить правило самостоятельно, чтобы заблокировать эти файлы, если они еще не заблокированы:

<FilesMatch "^.(htaccess|htpasswd)$">
    Order Allow,Deny
    Deny from all
</FilesMatch>

во-вторых, следует отметить, что путь .htaccess файлы работают, они обрабатываются, когда сопоставляется каталог, в котором они находятся. То есть: .htpasswd может быть в другом месте, но .htaccess должен быть в том же каталоге. Тем не менее, см. раздел "последствия для скорости" для немного более подробной информации.

так, как они могут быть заблокированы так легко, зачем держать .htpasswd за пределами общедоступного каталога? Потому что ошибки случаются, и .htpasswd файл является большой ответственностью. Даже если вы используете HTTPS, экспозиция вашего .htpasswd файл означает, что ваши пароли могут быть легко взломаны с помощью атак грубой силы. В наши дни графические процессоры потребительского класса могут делать миллионы догадок о паролях в секунду. Это может сделать даже "сильные" пароли падают в сравнительно немного времени. Опять же, этот аргумент обычно применяется только к целевому атака, но факт остается фактом, что если атакующий имеет ваш и хочет доступ к вашей системе, в эти дни, они могут быть в состоянии сделать это легко. См.Скорость Хеширования о кодировании ужасов для относительно недавнего (апрель 2012) обзора состояния вещей.

имея это в виду, возможность случайного (временного) разоблачения вашего .htaccess файл стоит переместить его куда-то, что никогда не следует даже смотреть, когда httpd ищет контент для обслуживания. Да, все еще есть изменения конфигурации, которые могут выставить его, если он "на один уровень выше" вместо "в общедоступном каталоге", но эти изменения гораздо менее вероятны случайно.

влияет ли скорость?

некоторые.

во-первых, использование .htaccess файлы несколько замедляют работу. Более конкретно,AllowOverride all директива вызывает много потенциальных замедлений. Это заставляет Apache искать .реврайт файлы в каждом каталоге и в каждом родительском каталоге, доступ к которому осуществляется (вплоть до DocumentRoot). Это означает запрос файловой системы на файл (или обновления файла) для каждого запроса. По сравнению с альтернативой потенциально никогда попадание в файловую систему, это довольно большая разница.

так почему же .htaccess существуют вообще? Есть много причин, которые могут сделать это "стоит":

• в зависимости от загрузки сервера, вы может и не заметит разницы. Действительно ли ваш сервер должен выжимать каждую последнюю миллисекунду из каждого запроса? Если нет, то не беспокойтесь об этом. Как всегда, не беспокойтесь об оценках и прогнозах. Профилируйте свои ситуации в реальном мире и посмотрите, имеет ли это значение.
• .htaccess можно изменить без перезагрузки сервера. На самом деле, это то, что делает его настолько медленным - Apache проверяет наличие изменений или наличие .htaccess файл по каждому запросу, поэтому применяются изменения немедленно.
• ошибка .htaccess будет снимать каталог, а не сервер. Это делает его гораздо меньше ответственности, чем изменение .
• .htaccess можно изменить, даже если у вас есть только доступ для записи в один каталог. Это делает его идеальным для виртуального хостинга. Нет необходимости иметь доступ к httpd.conf вообще или доступ для перезапуска сервера.
• .htaccess можно сохранить правила доступа рядом с файлами, для которых они предназначены эффект. Это может сделать их намного проще найти, и просто держит вещи более организованно.

не хочу использовать .htaccess, даже учитывая все вышесказанное? Любое правило, которое применяется к .htaccess можно добавить непосредственно в httpd.conf или включенный файл.

а как же .htpasswd? Это зависит от количества пользователей. Он основан на файлах и является минимальным с точки зрения реализации. От документы для httpd 2.2:

из-за того, как указана базовая аутентификация, ваш логин и пароль должны быть проверены каждый раз, когда вы попросите документ с сервера. Это даже если вы перезагружаете то же самое страница, и для каждого изображения на странице (если они приходят от защищенного справочник.) Как вы можете себе представить, это немного замедляет процесс. Этот сумма, которую он замедляет, пропорциональна размеру файл пароля, потому что он должен открыть этот файл и спуститься вниз список пользователей пока не доберется до вашего имени. И он должен делать это каждый время загрузки страницы.

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

In коротко,.htpasswd медленно. Если у вас есть только несколько пользователей, которым требуется аутентификация, вы никогда не заметите, но это еще одно соображение.

резюме

защита раздела администратора с помощью .htpasswd не подходит для всех ситуаций. Учитывая его простоту, оно может оправдать риски и проблемы, когда безопасность и производительность не являются самыми высокими приоритетами. Для многих ситуаций, с небольшим количеством настроек, его можно считать " хорошим достаточно." То, что составляет "достаточно хорошо", - это призыв к вам.