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?
Hay algunos problemas con HTTP Basic Auth:
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).
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.
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.
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.
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.
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 .
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 encriptar . 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.
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.
Lea otras preguntas en las etiquetas web-application authentication tls appsec http