¿Es HTTPS y la autenticación básica lo suficientemente seguras para los servicios web bancarios (REST)?

22

He estado leyendo sobre SSL / TLS durante los últimos días y parece que nunca se ha descifrado prácticamente.

Dado que SSL / TLS se usa para todas las comunicaciones entre la aplicación cliente y el servidor, y dada la clave de la contraseña / API es aleatoria, segura y está almacenada de forma segura en el lado del servidor (bcryted, salado), ¿cree que la Autenticación Básica es ¿Lo suficientemente seguro, incluso para los servicios bancarios?

Veo que a muchas personas les disgusta la idea de que el nombre de usuario / contraseña se envíe por cable con cada solicitud. ¿Es este un punto débil real de la Autenticación básica (incluso con SSL / TLS usado), o simplemente es por miedo irracional?

    
pregunta dnang 02.11.2013 - 13:26
fuente

3 respuestas

32

La autenticación básica HTTP no se usa mucho en las conexiones de navegador-servidor porque implica, en el lado del navegador, una ventana emergente de inicio de sesión controlada por el navegador que es invariablemente fea. Por supuesto, esto no se aplica a las conexiones servidor-servidor, donde no hay usuarios humanos que observen la fealdad, pero contribuye a un clima general de desconfianza y desuso para la autenticación básica.

También, en la década de 1990, antes de los días de SSL, el envío de contraseñas de texto simple a través del cable se consideraba un delito de tiro, y, en su locura, las personas consideraban que los protocolos de desafío-respuesta como HTTP Digest fueron suficientes para garantizar la seguridad. Ahora sabemos que no es así; independientemente del método de autenticación, el tráfico completo debe estar al menos criptográficamente vinculado a la autenticación para evitar el secuestro por parte de atacantes activos. Así que SSL es obligatorio . Pero cuando SSL está en vigor, enviar la contraseña "tal cual" en el túnel SSL está bien. Entonces, para resumir, la autenticación básica en SSL es lo suficientemente fuerte para propósitos serios, incluidos los códigos de lanzamiento nuclear e incluso asuntos relacionados con el dinero.

Uno todavía debe señalar que la seguridad se basa en la imposibilidad de los ataques de Man-in-the-Middle que, en el caso de SSL (como se usa comúnmente) se basa en el certificado del servidor. El cliente SSL (otro servidor en su caso) DEBE validar el certificado del servidor SSL con mucho cuidado, incluida la verificación del estado de revocación mediante la descarga de la CRL correspondiente. De lo contrario, si el cliente es redirigido a un servidor falso, el propietario del servidor falso aprenderá la contraseña ... En ese sentido, el uso de algo parecido a HTTP Digest agrega un nivel adicional de mitigación en caso de que la situación ya se haya puesto bastante mal, porque incluso con HTTP Digest, un servidor falso que realiza un MitM aún puede secuestrar la conexión en cualquier momento.

Si vamos un poco más lejos, podemos notar que al usar la autenticación basada en contraseña, realmente queremos la autenticación mutua basada en contraseña. Lo ideal es que el cliente SSL y el servidor SSL se autentiquen entre sí en función de su conocimiento de la contraseña compartida. Los certificados son una complicación innecesaria; teóricamente, el cliente y el servidor SSL deben usar TLS-PSK o TLS-SRP en esa situación, y evite todo el negocio de certificados X.509 por completo.

En particular, en SRP, lo que el servidor almacena no es la contraseña en sí, sino un derivado de la misma (un hash con una estructura matemática adicional). Uno debe tener en cuenta un punto importante: en el caso de una API web, tanto el cliente como el servidor son máquinas sin humanos involucrados. Por lo tanto, la "contraseña" no necesita ser lo suficientemente débil como para ser recordada por las bolsas de carne. Esa contraseña podría ser, digamos, una secuencia de 25 caracteres aleatorios, con una entropía en el techo. Esto hace que los métodos de hashing de contraseñas habituales (hashing lento, sales) sean poco útiles. Todavía queremos evitar almacenar en la base de datos del servidor (por lo tanto, como una presa de posibles inyecciones de SQL) las contraseñas "tal como están", pero, en ese caso , un simple hash Sería suficiente.

Esto apunta a lo siguiente: idealmente, para que un servidor use una API RESTful para comunicarse con otro, con la autenticación basada en un secreto compartido (fat), la comunicación usará TLS con SRP. Sin certificado, solo hashes almacenados en el servidor. No es necesaria la autenticación básica HTTP o cualquier otra autenticación basada en HTTP, porque todo el trabajo ya se habría producido en el nivel SSL / TLS.

Lamentablemente, el estado actual de implementación de implementaciones SSL / TLS compatibles con SRP generalmente significa que no puede usar SRP todavía. En su lugar, tendrá que usar un SSL / TLS más mundano con un certificado X.509 en el lado del servidor, que el cliente valida debidamente. Siempre que la validación se realice correctamente, no hay ningún problema en enviar la contraseña "tal cual", por ejemplo. como parte de la autenticación básica HTTP.

    
respondido por el Thomas Pornin 02.11.2013 - 15:03
fuente
3

Un problema principal con la autenticación HTTP es que no hay forma de cerrar la sesión, excepto cerrar el navegador. Y como la contraseña va con cada solicitud, la autenticación no tiene estado. No se puede cerrar la sesión de los usuarios después de 20 minutos de inactividad, por ejemplo.

Los sitios de alta seguridad, como los bancos, generalmente (¿siempre?) proporcionarán no solo un medio para que un usuario cierre la sesión manualmente, sino que también también cerrará la sesión del usuario después de un período de inactividad. Esto ayuda a prevenir una serie de ataques oportunistas.

    
respondido por el tylerl 02.11.2013 - 20:34
fuente
2

En realidad, he visto estas solicitudes enviadas por mi banco. Sin embargo, todavía utilizan identificadores de sesión en lugar de enviar el nombre de usuario y la contraseña cada vez (esto no es realmente tranquilo, lo sé). La razón por la que no usan solo el nombre de usuario y la contraseña, sino una sesión, es porque requieren un segundo factor de autenticación. Esto significa que tendrá que volver a ingresar su respuesta de desafío para cada recarga de página.

Si su banco solo usa el nombre de usuario y la contraseña, honestamente no me importaría. Pero en mi opinión, cualquier aplicación bancaria que se respete a sí misma debería utilizar una forma de autenticación de dos factores: ya sea a través de SMS, lectores de tarjetas, tokens, ...

    
respondido por el Lucas Kauffman 02.11.2013 - 14:37
fuente

Lea otras preguntas en las etiquetas