¿Qué nivel de seguridad proporciona esto?
.htpasswd no proporciona mucha seguridad por sí mismo. Es decir, proporciona un mecanismo de inicio de sesión y Apache no responderá sin las credenciales adecuadas, pero a menos que se configure por separado, nada sobre el intercambio se cifra (o incluso se ofusca). Por ejemplo, escuchar la solicitud GET con Wireshark le da una buena vista de todas las cabeceras de ser enviado por el cliente, incluyendo:
Authorization: Basic d3BhbG1lcjp0ZXN0dGVzdA==
"d3BhbG1lcjp0ZXN0dGVzdA==" siendo sólo los base64 forma de "wpalmer:testtest" codificados. En estos días, un pirata informático (o más probablemente, un virus) puede sentarse en una conexión WiFi pública y registrar cualquier solicitud que contenga Authorization: para su consulta posterior. En general, enviar una información de autenticación a través de una conexión HTTP no cifrada se considera una mala idea, incluso si se está transfiriendo a través de un cable o Wi-Fi seguro de extremo a extremo. Por ejemplo, no cumpliría con los requisitos de PCI Compliance si almacena datos de clientes, información de pago, etc. detrás del bloqueo .htpasswd.
Añadir https a la mezcla, y se elimina por completo este problema en particular, sin embargo ...
.htpasswd autenticación aplicado por httpd Apache no proporciona ninguna forma de protección que limita la velocidad o la fuerza bruta. Puede hacer tantos intentos simultáneos en una contraseña adivinar como Apache está dispuesto a servir páginas simultáneas, y Apache responderá con éxito/fracaso tan pronto como sea posible. Puede usar algo como Fail2Ban para limitar el número de intentos fallidos que se pueden hacer antes de que el cliente bloquee su conversación con el servidor, pero eso no proporcionará necesariamente ninguna protección útil contra una botnet, que puede apuntar automáticamente a su servidor desde miles de direcciones. Esto puede llevar a la decisión de "¿Me dejo vulnerable a intentos de contraseñas de botnets o me vuelvo vulnerable a ataques de denegación de servicio cuando toda la cuenta está bloqueada debido a fallas de múltiples clientes?"
Estos ángulos de ataque se pueden limitar agregando restricciones basadas en IP a su archivo .htaccess, permitiendo conexiones solo desde ciertas direcciones. Dependiendo de cómo opere, esto puede ser un inconveniente, pero también limita severamente los tipos de amenazas a las que sería vulnerable. Aún correría riesgo si alguien se centra específicamente en su sitio o si se contagia de una parte de la infraestructura de la red. Dependiendo del tipo de contenido que esté protegiendo, esto puede ser "lo suficientemente bueno".Un ejemplo de este tipo de restricción es:
Order deny,allow
Deny from all
Allow from 127.0.0.1
Esto significa, en pocas palabras, "sólo permiten conexiones desde el host local". Línea por línea, que significa:
Order deny,allow define el orden en que se procesan las reglas, con el último partido que tiene precedencia.Deny from all partir del presupuesto de que todos los clientes se les niegaAllow from 127.0.0.1 si el cliente tiene la IP 127.0.0.1, a continuación, se le permite
En cierta medida, las restricciones basadas en IP también le protegerán al punto donde HTTPS puede considerarse opcional. Los atacantes/virus todavía pueden ver sus credenciales, pero les resulta más difícil usar esas credenciales en la página. Una vez más, esto no sería compatible con PCI, y no sería adecuado para la información "importante", pero hay algunas situaciones en las que esto puede considerarse "lo suficientemente bueno". Tenga en cuenta que muchas personas vuelven a usar las credenciales en varios sitios, por lo que no proteger los datos de inicio de sesión generalmente se considera muy peligroso para el usuario, incluso si el sitio está protegido.
Finalmente, el archivo .htaccess en sí mismo es un poco responsable. Vea la respuesta a "¿necesitan estar fuera del directorio público?" para más detalles sobre eso.
¿Se puede omitir fácilmente?
No. No hay ninguna razón para esperar que el servidor, cuando se configura correctamente, fallará al requerir detalles de inicio de sesión para acceder al contenido protegido. Si bien la autenticación HTTP básica tiene sus fallas, Apache httpd es muy robusto y es uno de los programas de software más probados en el mundo. Si le dice a Apache que se requiere autenticación HTTP básica para acceder a cierto contenido, será necesario.
Si Apache de forma predeterminada no permite a los usuarios acceder directamente a ninguno de los dos archivos, ¿necesitan estar fuera del directorio público?
Hay un par de puntos a esto. En primer lugar, Apache hace no predeterminado para evitar el acceso a cualquiera de estos archivos. Muchas distribuciones de Apache httpd incluyen una configuración inicial que impide el acceso (usando las reglas "Denegar de todas") a, según la distribución, los archivos .htaccess/.htpasswd, .ht* o .*. Es muy común, pero hay muchas razones por las cuales este no es el caso. Se puede añadir una regla de sí mismo para bloquear estos archivos, si no están ya bloqueadas:
<FilesMatch "^.(htaccess|htpasswd)$">
Order Allow,Deny
Deny from all
</FilesMatch>
En segundo lugar, debe señalarse que la forma .htaccess archivos de trabajo, que se procesan cuando el directorio se encuentran en está emparejado . Es decir: .htpasswd puede estar en otra parte, pero .htaccess debe estar en el mismo directorio. Dicho esto, consulte la sección "implicaciones de velocidad" para obtener más detalles.
Entonces, como pueden bloquearse tan fácilmente, ¿por qué mantener .htpasswd fuera del directorio público? Porque ocurren errores, y el archivo .htpasswd es una gran responsabilidad. Incluso si está utilizando HTTPS, la exposición de su archivo .htpasswd significa que sus contraseñas se pueden descifrar fácilmente mediante ataques de fuerza bruta.Hoy en día, las GPU de grado de consumo pueden hacer millones de intentos de contraseña por segundo. Esto puede hacer que incluso las contraseñas "fuertes" caigan en un tiempo comparativamente corto. Una vez más, este argumento generalmente solo se aplica a un ataque dirigido, pero el hecho es que si un atacante tiene su archivo .htpasswd y quiere acceder a su sistema, en estos días, pueden hacerlo fácilmente. Consulte Speed Hashing en Coding Horror para obtener una descripción general relativamente reciente (abril de 2012) del estado de cosas.
Teniendo esto en cuenta, la posibilidad de exponer accidentalmente (temporalmente) su archivo .htaccess vale la pena moverlo a un lugar que nunca debería ser siquiera mirado cuando httpd está buscando contenido para servir. Sí, todavía hay cambios de configuración que podrían exponerlo si está "un nivel arriba" en lugar de "en el directorio público", pero es menos probable que esos cambios sucedan accidentalmente.
¿Hay alguna implicación de velocidad?
Algunos.
En primer lugar, el uso de archivos .htaccess ralentiza un poco las cosas. Más específicamente, la directiva AllowOverride all causa una gran disminución potencial. Esto hace que Apache busque archivos .htaccess en cada directorio y en todos los padres de un directorio al que se accede (hasta e incluyendo el DocumentRoot). Esto significa consultar el sistema de archivos para un archivo (o actualizaciones del archivo), para cada solicitud. En comparación con la alternativa de potencialmente nunca golpear el sistema de archivos, esta es una gran diferencia.
Entonces, ¿por qué existe .htaccess en absoluto? Hay muchas razones que pueden hacer que valga la pena:
- dependiendo de la carga de su servidor, es posible que nunca note la diferencia. ¿Su servidor realmente necesita exprimir hasta el último milisegundo de cada solicitud? Si no, entonces no te preocupes por eso. Como siempre, no se preocupe por las estimaciones y proyecciones. Perfile sus situaciones del mundo real y vea si hace la diferencia.
.htaccess se puede modificar sin reiniciar el servidor. De hecho, esto es lo que lo hace tan lento: Apache busca cambios o la presencia de un archivo .htaccess en cada solicitud, por lo que los cambios se aplican de inmediato.- Un error en
.htaccess eliminará el directorio, no el servidor. Esto hace que sea mucho menos una responsabilidad que cambiar el archivo httpd.conf.
.htaccess puede modificarse incluso si solo tiene acceso de escritura a un único directorio. Esto lo hace ideal para entornos de alojamiento compartido. No es necesario tener acceso al httpd.conf o acceder para reiniciar el servidor..htaccess puede mantener las reglas de acceso al lado de los archivos que están destinados a efectuar. Esto puede hacer que sea mucho más fácil de encontrar, y simplemente mantiene las cosas más organizadas.
¿No desea utilizar .htaccess, aun teniendo en cuenta todo lo anterior? Cualquier regla que se aplique a .htaccess se puede agregar directamente al httpd.conf o un archivo incluido.
¿Qué hay de .htpasswd? Eso depende de cuántos usuarios tenga. Está basado en archivos y es el mínimo indispensable en términos de implementación.De The docs for httpd 2.2:
Debido a la forma en que se especifica la autenticación básica, su nombre de usuario y la contraseña deben ser verificados cada vez que se solicita un documento desde el servidor. Esto incluso si está recargando la misma página , y para cada imagen en la página (si provienen de un directorio protegido ). Como se puede imaginar, esto ralentiza un poco las cosas. La cantidad que ralentiza las cosas es proporcional al tamaño del archivo de contraseñas , porque tiene que abrir ese archivo y pasar a la lista de usuarios hasta que llegue a su nombre. Y tiene que hacer esto cada vez que se carga una página.
Una consecuencia de esto es que hay un límite práctico para la cantidad de usuarios de que puede colocar en un archivo de contraseña. Este límite variará dependiendo de en el rendimiento de su máquina servidor particular, pero puede esperar ver ralentizaciones una vez que obtenga más de unos cientos de entradas, y puede considerar un método de autenticación diferente en ese momento.
En resumen, .htpasswd es lento. Si solo tiene un puñado de usuarios que necesitan autenticarse, nunca lo notarán, pero es otra consideración.
Resumen
Asegurar una sección de administración con .htpasswd no es ideal para todas las situaciones. Dada su simplicidad, puede valer la pena los riesgos y problemas en los que la seguridad y el rendimiento no son las más altas prioridades. Para muchas situaciones, con un poco de ajuste, se puede considerar que es "lo suficientemente bueno". Lo que constituye "lo suficientemente bueno" es un llamado de juicio para que usted haga.