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

268

Estoy haciendo un REST-API y es sencillo hacer un inicio de sesión de autenticación BÁSICO. Luego, permita que HTTPS asegure la conexión para que la contraseña esté protegida cuando se utiliza la api.

¿Se puede considerar seguro?

    
pregunta Morten 05.12.2010 - 23:42
fuente

8 respuestas

232

Hay algunos problemas con HTTP Basic Auth:

  • La contraseña se envía a través del cable en la 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)
  • El navegador web almacena en caché la contraseña, como mínimo para la longitud de la ventana / proceso. (Puede ser reutilizado en silencio por cualquier otra solicitud al servidor, por ejemplo, CSRF).
  • La contraseña se puede almacenar de forma permanente en el navegador, si el usuario lo solicita. (Igual que el punto anterior, además, otro usuario puede robarlo en una máquina compartida).

De ellos, el uso de 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 de texto sin formato.

Por lo tanto, como con cualquier cosa, es importante mirar el panorama completo.

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

¿Es eso suficiente? Por lo general, no. (Quiero decir, siempre que no, pero realmente depende de lo que sea su sitio y de lo seguro que sea).

    
respondido por el AviD 06.12.2010 - 00:18
fuente
58

Intente pensarlo de esta manera: cuando inicies sesión en cualquier sitio web utilizando SSL, lo más probable es que pases la contraseña en texto sin formato sobre HTTPS (por ejemplo, GMail).

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

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

    
respondido por el Nemo 15.07.2012 - 05:27
fuente
20

La Autenticación básica sobre HTTPS es buena, pero no es completamente segura. De forma similar a como Fiddler funciona para la depuración de SSL, un proxy HTTPS corporativo administra la conexión entre el navegador web y el Proxy (cuya IP la dirección 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 administre el proxy y de cómo se utilicen sus registros, esto puede ser aceptable o malo desde su perspectiva.

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

  

Cuando el proxy SSL intercepta un SSL   Conexión, presenta un emulado.   certificado de servidor al cliente   navegador. El navegador del cliente emite un   ventana emergente de seguridad para el usuario final   porque el navegador no confía en el   Emisor utilizado por el ProxySG. Esta   ventana emergente no se produce si el emisor   certificado utilizado por SSL Proxy es   importado como una raíz de confianza en el   almacén de certificados del navegador del cliente.

     

El ProxySG hace todo configurado   certificados disponibles para descargar   A través de su consola de gestión. Usted puede   Pedir a los usuarios finales que descarguen el emisor.   Certificado a través de Internet Explorer   o Firefox e instalarlo como un confiable   CA en su navegador de elección. Esta   elimina el certificado emergente para   certificados emulados ...

Algunas compañías evitan el problema emergente de certificados mencionado anteriormente al implementar 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.

    
respondido por el random65537 06.12.2010 - 06:49
fuente
12

Usted nota la necesidad de autenticar al cliente y pregunta sobre la seguridad de la autenticación básica HTTP, sobre SSL. Esto es para lo que se diseñó SSL y funcionará bien siempre y cuando la contraseña sea buena. Si realmente está configurando esto para un solo cliente, es fácil de garantizar seleccionando una contraseña aleatoria larga, por ejemplo. 12 caracteres que utilizan una buena fuente de aleatoriedad u otras técnicas que se analizan en este sitio.

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

    
respondido por el nealmcb 14.07.2012 - 04:04
fuente
9

Depende completamente de qué tan seguro debe ser. La autenticación básica sobre ssl seguirá enviando credenciales en texto sin formato, lo que significa que solo tiene una capa de protección.

Sería mejor si hash la contraseña con un nonce, o mejor aún, utilice el modelo de reclamaciones que pasa la autenticación a un tercero de confianza.

    
respondido por el Steve 05.12.2010 - 23:59
fuente
3

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

Dicho esto, generalmente se considera aceptable, bajo la condición de que su página de destino que aloja el formulario de inicio de sesión también sea HTTP / S. En su caso de una API REST, es probable que 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 .

    
respondido por el Weber 06.12.2010 - 01:25
fuente
3

Lo estoy usando para muchas cosas, y mientras no ignore las advertencias TLS del navegador, debería ser bueno.

TLS funciona por debajo de HTTP, por lo que cualquier información transmitida 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 Vamos a cifrar . Proporcionan certificados gratuitos y son de confianza para Microsoft, Mozilla, etc., y por lo tanto no dará una advertencia TLS en el navegador. Creo que es mejor usar esto en lugar de un certificado autofirmado; si alguna vez ve un error TLS, sabe que es real y no solo porque su certificado es autofirmado.

    
respondido por el Luc 15.07.2012 - 02:47
fuente
2

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 pasar por alto 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 usa un certificado válido.

    
respondido por el lightxx 06.03.2015 - 12:32
fuente

Lea otras preguntas en las etiquetas