¿Es BASIC-Auth seguro si se realiza a través de HTTPS?

AviD

2010-12-06 05:18:48 UTC

view on stackexchange narkive permalink

Hay algunos problemas con la autenticación básica HTTP:

La contraseña se envía por cable en codificación base64 (que se puede convertir fácilmente a texto sin formato).
La contraseña se envía repetidamente, para cada solicitud. (Ventana de ataque más grande)
La contraseña es almacenada en caché por el navegador web, como mínimo para la duración de la ventana / proceso. (Puede reutilizarse silenciosamente por cualquier otra solicitud al servidor, por ejemplo, CSRF).
La contraseña puede almacenarse permanentemente en el navegador, si el usuario lo solicita. (Igual que el punto anterior, además podría ser robado por otro usuario en una máquina compartida).

De esos, usar SSL solo resuelve el primero. E incluso con eso, SSL solo protege hasta que el servidor web: cualquier enrutamiento interno, registro del servidor, etc., verá la contraseña en texto sin formato.

Entonces, como con cualquier cosa, es importante tener en cuenta la imagen completa.

¿HTTPS protege la contraseña en tránsito? Sí.

¿Es suficiente? Por lo general, no. (Quiero decir que siempre no, pero realmente depende de cuál sea su sitio y de qué tan seguro debe ser).

de hecho, incluso con HTTP Digest, es posible que pueda obtener un hash de la contraseña (`md5 (nombre de usuario: reino: contraseña)`, a veces llamado HA1).

@AviD ♦ En mi opinión, sus puntos 3) y 4) rara vez son válidos para las API REST.

En caso de autenticación básica, la contraseña "tiene que estar" almacenada en el navegador, lo que solo se puede hacer a través de una cookie, que nunca puede considerarse segura. Publiqué una pregunta similar aquí: http://stackoverflow.com/questions/27177224/how-to-keep-state-at-the-client-safely/27177995#27177995 Mi conclusión fue que la autenticación básica NO es segura, que NO debe usarse como tal, y el almacenamiento de datos confidenciales en el cliente (como una contraseña de usuario) ni siquiera debe considerarse.

@KimGysen para Basic Auth, la contraseña NO se transmite ni se almacena en una cookie, se envía en el encabezado de solicitud `Autorización:` y se almacena en una parte especial (protegida) de la memoria del navegador. No es que no esté de acuerdo con usted, en el caso general, la autenticación básica no debería usarse, sin embargo, hay ciertas situaciones en las que la compensación podría ser viable.

El segundo punto no es un problema. Enviar credenciales con cada solicitud mantiene su backend sin estado.

Además de la "ventana de ataque más grande", no hay un mecanismo integrado como el bloqueo de la cuenta para protegerse contra la fuerza bruta.

@Artjom: El envío de credenciales básicas en cada solicitud es un problema, no porque tenga que seguir enviando las credenciales, sino porque se envía la misma cadena en cada solicitud. Existen otros mecanismos de autenticación, como HMAC, donde el encabezado de Autorización no se puede descifrar al secreto del usuario y el servidor puede autenticar la solicitud sin conocer realmente el secreto del usuario. En este mecanismo, la cadena enviada en el encabezado de Autorización cambia según el hash de la solicitud.

@LieRyan Sinceramente, no lo entiendo: - \. ¿Cuál es el problema de enviar la misma cadena? ¿Es porque la variedad es la sal de la vida?

Ataque de reproducción @DavidS:. Además, si pasa su tráfico a través de un proxy o servicio CDN, tiene cierta seguridad de que un atacante no puede atacar el proxy / CDN para alterar las solicitudes del usuario.

@Bruno, HTTP Digest es * peor * porque requiere que el servidor almacene las contraseñas de los usuarios en texto plano.

@Jacco En principio, el servidor solo podía almacenar `md5 (nombre de usuario: reino: contraseña)` y no necesitar la contraseña en claro (puede verificar el contenido de un archivo generado con `htdigest`, por ejemplo).Esto depende de la implementación.Dicho esto, todavía no es genial (también con la desventaja de ser fácilmente vulnerable a los ataques de degradación a Basic).

"Ventana de adjunto más grande" Entonces, el token de sesión normal que se envía como cookie también tiene un problema similar, ¿verdad?

@JithinJose que no incluiría la contraseña del usuario, ni es estática + válida durante mucho tiempo.

@LieRyan HMAC no es uno de los mecanismos de autenticación HTTP estándar, a diferencia de Basic y Digest.¿Estaba hablando de [el implementado por AWS] (https://docs.aws.amazon.com/en_us/AmazonS3/latest/dev/RESTAuthentication.html#ConstructingTheAuthenticationHeader)?

@LieRyan: Tanto la reproducción como el escenario de proxy / CDN no son posibles con TLS, a menos que TLS tenga un defecto.

Nemo

2012-07-15 08:27:07 UTC

view on stackexchange narkive permalink

Intente pensarlo de esta manera: cuando inicia sesión en cualquier sitio web usando SSL, lo más probable es que esté pasando la contraseña en texto sin formato a través de HTTPS (por ejemplo, GMail).

La única diferencia que hace Basic-Auth es que nombre de usuario / contraseña se pasa en los encabezados de la solicitud en lugar del cuerpo de la solicitud (GET / POST).

Como tal, usando basic-auth + https no es menos ni más segura que una autenticación basada en formularios a través de HTTPS.

Hay una pequeña diferencia entre esas situaciones: con la autenticación básica http, la contraseña se envía para * cada solicitud *, mientras que con un inicio de sesión basado en formulario se envía solo una vez y luego se usa algo así como una cookie de sesión. Esto * muy levemente * disminuye la superficie de ataque.

La contraseña de usuario se envía solo una vez, pero la cookie de autenticación también se envía en cada solicitud, por lo que la pregunta es solo enviar el usuario y la contraseña en lugar de la autenticación de la cookie

@deFreitas y, por lo tanto, tiene la premisa de OAuth: usar otro token para la autenticación en lugar de enviar el u / p todo el tiempo.

Creo que hay más que una pequeña diferencia: en el ejemplo de formulario POST, la representación de la página inicial debe enviarse a través de HTTPS antes de que el usuario decida ingresar sus credenciales y enviarlas nuevamente (de forma segura). Con la autenticación básica HTTP, incluso si el servidor se niega a atender una solicitud que no es HTTPS y redirige a HTTPS, las credenciales ya han pasado por el cable de forma insegura y luego son venerables para la indagación de MiTM. El cliente tiene que decidir POST HTTPS inicialmente o arriesgarse a un canal inseguro. Esto es menos probable con el escenario POST de formulario.

@PepijnSchmitz Notaría que la diferencia de una clave de sesión (que puede invalidarse) es muy diferente a que le roben las credenciales de inicio de sesión.El daño aún se puede infligir mientras otra parte tiene su clave de sesión privada, pero es de naturaleza mucho más limitada, especialmente porque puede hacer que su aplicación cierre la sesión de la API después de que termine de ejecutarse para invalidar la clave.

goodguys_activate

2010-12-06 11:49:54 UTC

view on stackexchange narkive permalink

La autenticación básica a través de HTTPS es buena, pero no es completamente segura. De manera similar a cómo funciona Fiddler para la depuración de SSL, un proxy HTTPS corporativo administra la conexión entre el navegador web y el Proxy (cuya dirección IP aparece en los registros de su servidor web). En ese caso, la contraseña HTTPS se descifra y luego se vuelve a cifrar en el proxy corporativo.

Dependiendo de quién está administrando el proxy y cómo se utilizan sus registros, esto puede ser aceptable o malo desde su perspectiva.

Para obtener más información sobre cómo se realiza la interceptación SSL , consulte este enlace:

Cuando el Proxy SSL intercepta una conexión SSL, presenta un certificado de servidor emulado al navegador del cliente. El navegador del cliente emite una ventana emergente de seguridad para el usuario final porque el navegador no confía en el emisor utilizado por ProxySG. Esta ventana emergente no ocurre si el certificado del emisor usado por el Proxy SSL se importa como una raíz confiable en el almacén de certificados del navegador del cliente.

El ProxySG hace que todos los certificados configurados estén disponibles para su descarga a través de su consola de administración. Puede pedir a los usuarios finales que descarguen el certificado del emisor a través de Internet Explorer o Firefox e instalarlo como una CA de confianza en el navegador de su elección. Esto elimina la ventana emergente de certificado para certificados emulados ...

Algunas empresas solucionan el problema de la ventana emergente de certificado mencionado anteriormente implementando los certificados raíz (del Proxy) en cada estación de trabajo a través de GPO. Aunque esto solo afectará al software que utiliza el almacén de certificados de Microsoft. El software como Firefox debe actualizarse de manera diferente.

En realidad, esto depende del sitio del que estés hablando. P.ej. si está navegando a su banco desde el trabajo y ellos usan la autenticación básica, el proxy no lo descifrará en su trabajo. SSL pasa por eso.

Esto no tiene sentido para mí, ¿en qué escenario estás pensando? Los proxies no pueden ver lo que hay dentro de una sesión https, si el navegador lo configuró con el punto final real, debidamente autenticado con un buen certificado (o DNSSEC o lo que sea).

El votante negativo debe leer la documentación vinculada, ya que este es un punto real y válido que no es ampliamente conocido. Documentos: http://www.bluecoat.co.jp/downloads/manuals/SGOS_DG_4.2.x.pdf

Sí, tiene razón: BlueCoat parece un malware corporativo que usa FUD para hacer que el negocio sea inseguro.

Y por cierto, Chrome usa la Tienda de certificados de Windows ...

Algún alma amable debería votar esta respuesta para que ya no sea (-1) Esta respuesta contiene información verdadera y fáctica

@AViD, hay algunos casos en los que los proxies corporativos en realidad _hacen_ descifran el tráfico SSL, presentando su propio certificado (que está firmado por un certificado corporativo interno que se importa como un certificado de autoridad raíz confiable en todas las estaciones de trabajo corporativas). Mi empresa hace esto para algunos sitios, incluido Gmail (pero no para sitios bancarios). Funciona y, a menudo, es invisible para los usuarios porque la empresa también administra los equipos de escritorio / navegadores. Tenga en cuenta que Strict Transport Security (HSTS) puede vencer esto ... ¡fue la advertencia de Firefox HSTS la que me alertó en primer lugar!

@MichaelLucas: sí, consulte los comentarios anteriores sobre BlueCoat (un popular malware, erm, proveedor de software en este espacio). Como insinué, este es un anti-patrón, con numerosas desventajas (por ejemplo, el usuario no tiene ninguna indicación sobre certificados de servidor no válidos o problemáticos ... y eso es además de los problemas de privacidad)

@MichaelLucas Que yo sepa, si lo hacen correctamente, HSTS no puede vencer esto, ¿puede explicar cómo aborda esto HSTS? Creo que lo notaría si echa un vistazo a la Cadena de Certificados en su navegador y comienza a preguntarse por qué su empresa es la CA de un sitio de terceros. Sin embargo, si mi empresa hiciera esto, ¡me quejaría!

@Nappy ¿Posiblemente lo que se quería decir era [HPKP] (https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning) en lugar de HSTS?Eso ciertamente podría derrotar a los desagradables escáneres corporativos.Excepto que Wikipedia afirma que la mayoría de los navegadores deshabilitan las comprobaciones de HPKP para certificados con raíces privadas específicamente para permitir tales escáneres.Oh bien...

Si la empresa realiza ataques MITM al tráfico de empleados, anula casi cualquier forma de autenticación, no solo la autenticación básica.Entonces, a menos que el servidor web esté dispuesto a usar algo más complejo como la autenticación de 2 factores, Basic es casi tan seguro como cualquier otra forma de autenticación.

nealmcb

2012-07-14 07:04:17 UTC

view on stackexchange narkive permalink

Observa la necesidad de autenticar al cliente y pregunta sobre la seguridad de la autenticación básica HTTP, a través de SSL. Esto es para lo que se diseñó SSL y funcionará bien siempre que la contraseña sea buena. Si realmente está configurando esto para un solo cliente, es fácil de asegurarse eligiendo una contraseña aleatoria larga, p. 12 caracteres utilizando una buena fuente de aleatoriedad u otras técnicas discutidas en este sitio.

Su cliente también necesita asegurarse de que tiene el certificado correcto para el servidor. En la situación como la que describe, estará bien usar un certificado autofirmado como se describe en la página de Python ssl a la que se hace referencia.

Si va a ser autofirmado, asegúrese de comunicar cuáles deben ser las huellas digitales SHA1 y MD5 del certificado para que puedan verificar su legitimidad al conectarse. O distribuya con anticipación, si es posible.

Existe otra preocupación con el uso de la autenticación básica HTTP: la contraseña completa se envía a través del túnel SSL. En otras palabras, la contraseña no se codifica antes de enviarla y, por lo tanto, podría capturarse (error en el código de su aplicación, etc.) Por lo general, esto no es una preocupación importante (esto es cierto para la mayoría de las contraseñas que envía a través de HTTPS, incluso en los formularios de inicio de sesión del sitio web e incluso en la contraseña SSH), pero vale la pena tomar nota de ello.

@ChrisKuehl ¿No hay argumentos sólidos en contra de hacer cripto en javascript del lado del cliente? Es eso lo que está sugiriendo? Me parece que TLS es lo mejor que puedo obtener aparte de pagar por firmar el certificado.

@StevenLu no que yo sepa o que pueda encontrar rápidamente, pero estaría interesado en leer algo sobre el tema. No veo ninguna forma de que el hash preliminar de algo antes de enviarlo al servidor pueda disminuir la seguridad, incluso si el servidor lo hace más hash antes de almacenarlo. Me sentiría tentado a usar [SSL / TLS auth] (http://goo.gl/xmzFI) en su lugar (los navegadores modernos permiten la autenticación bidireccional con sitios web que usan autenticación de clave), especialmente para una página que no está destinada a ser vista por usuarios habituales. Sin embargo, esto depende mucho de su caso de uso y probablemente sea difícil con su servidor web Python.

¿Qué pasa con TLS en TLS? Creo que envolverlo 4 veces sería más seguro que envolverlo una vez. De esta manera, puede distribuir las claves raíz en diferentes ubicaciones, por lo que si utiliza 4 empresas para hacerlo, es probable que ellas (ELLAS) no tengan la clave raíz secreta, o todas.

Eche un vistazo: http://www.matasano.com/articles/javascript-cryptography/

@StevenLu interesante, pero perdiendo el punto; La autenticación TLS, [tal como se implementa en los navegadores] (http://www.browserauth.net/tls-client-authentication), no incluye JavaScript. Es una característica del propio navegador. Hay problemas que hacen que no sea adecuado para su uso con la autenticación de cara al usuario, pero para los desarrolladores / administradores, creo que hay un caso sólido que se puede defender.

@ChrisKuehl Entonces, supongo que tendré que profundizar un poco más para encontrar una manera de configurar mi servidor para realizar una autenticación completa del cliente TLS.

@StevenLu, tu configuración me suena bien, pero todo depende de cuánta seguridad quieras. Solo lanzo una idea adicional :-).

La autenticación del servidor @ChrisKuehl TLS es definitivamente suficiente para mis necesidades y me sorprendió gratamente descubrir la simplicidad con la que pude configurarlo. Sin embargo, ahora me pregunto qué se necesitaría para obtener la autenticación completa del cliente.

Steve

2010-12-06 04:59:26 UTC

view on stackexchange narkive permalink

Depende completamente de cuán seguro debe ser. La autenticación básica a través de SSL seguirá enviando credenciales en texto sin formato, lo que significa que solo tiene una capa de protección.

Sería mejor que escribiera un hash en la contraseña con un nonce, o mejor aún, use el modelo de notificaciones que pasa la autorización a un tercero de confianza.

Weber

2010-12-06 06:25:50 UTC

view on stackexchange narkive permalink

Muchos sitios grandes y populares utilizan la autenticación básica (u otra basada en formularios) sobre HTTPS. Por lo general, recibe un "suspiro" de personas preocupadas por la seguridad. ¿Puede aplicar hash a la contraseña en el lado del cliente y enviar el hash en su lugar? Eso elevaría el listón un poco más.

Dicho esto, generalmente se considera aceptable, con la condición de que la página de destino que aloja el formulario de inicio de sesión también sea HTTP / S. En su caso de una API RESTful, probablemente no tenga una página de destino, así que está bien. Si puede, verifique su aplicación con algunas herramientas de seguridad gratuitas como Watcher y Skipfish.

solo un desafío-respuesta con hash es una mejora en la seguridad; de lo contrario, el atacante puede simplemente husmear el hash y aún obtener acceso cuando la sesión expire

Luc

2012-07-15 05:47:41 UTC

view on stackexchange narkive permalink

Yo mismo estoy usando esto para muchas cosas, y siempre que no ignore ninguna advertencia de TLS del navegador, debería estar bien.

TLS funciona por debajo de HTTP, por lo que cualquier dato transmitido a través de HTTP se cifrará. Será tan seguro como enviar cualquier formulario de contraseña.

Sin embargo, en lugar de usar un certificado autofirmado, sugeriría usar Let's Encrypt. Proporcionan certificados gratuitos y Microsoft, Mozilla, etc. confían en ellos, por lo que no darán una advertencia de TLS en el navegador. Creo que es mejor usar esto en lugar de un certificado autofirmado; si alguna vez ve un error de TLS, sabe que es real y no solo porque su certificado está autofirmado.

Definitivamente haría algo como esto, especialmente si es gratis. Los errores de "certificado no válido" son bastante evidentes.

Sí, StartSSL es realmente una especie de solución casera, pero las grandes partes confían en ella, así que supongo que está bien siempre y cuando no asegure nada que valga millones con ella. Cualquier cosa es mejor que un certificado autofirmado. La forma de hacer que la autofirmado sea segura es verificar la huella digital, pero aún puede hacerlo mientras usa (por ejemplo) StartSSL.

Estoy alojando mi contenido seguro en un servidor diferente de uno en el que puedo configurar el dominio de destino para un certificado (que será emitido por StartSSL). Esto se debe a que no estoy pagando por un VPS con una IP estática, estoy usando el servicio No-IP para que me redireccione a mi IP. ¿Es posible para mí obtener una clave / certificado que me permita abrir mi sitio desde cualquier lugar sin que muestre errores de certificado no válidos?

Por lo tanto, me parece claro que con una IP dinámica no hay absolutamente ninguna forma de configurar un certificado SSL adecuado. De acuerdo, supongo que estoy atascado con el error del navegador (a menos que realice algún tipo de configuración de proxy).

Actualización: StartSSL ha cerrado sus puertas.Su siguiente mejor opción es Let's Encrypt.

@starbeamrainbowlabs ¡Gracias!Actualicé la respuesta.

lightxx

2015-03-06 17:32:02 UTC

view on stackexchange narkive permalink

Otro argumento no mencionado (supongo) hasta ahora es el hecho de que muchos dispositivos móviles como los teléfonos inteligentes no permiten que el usuario verifique el certificado cuando realiza la autenticación básica a través de HTTPS en el navegador. Eso significa que, a diferencia de la autenticación basada en formularios, no puede omitir la ventana emergente de autenticación básica, que es un diálogo modal en la mayoría de las plataformas móviles para verificar el certificado antes de ingresar sus credenciales. Esto podría suponer un riesgo cuando un atacante utiliza un certificado válido.

Daniel Szpisjak

2019-02-05 13:05:44 UTC

view on stackexchange narkive permalink

Aquí hay un poco más de contexto para la historia. Al igual que otros dijeron que la autenticación básica sobre TLS funciona bien si puede vivir con algunas limitaciones.

Usado en el lado del cliente , probablemente necesite lidiar con la administración de sesiones, que es bastante difícil con la autenticación básica.

En el backend , la autenticación básica funciona bien, pero se basa completamente en TLS por confidencialidad e integridad. Es similar a la autenticación basada en tokens. Si necesita algo más sólido, considere usar un esquemas de firma o una autenticación de cliente TLS.