¿Cuál es la mejor manera de enviar los datos del formulario de autenticación web a través de HTTP?

https://stackoverflow.com/questions/715348

23-08-2019
|

Pregunta

Una empresa que conozco está en conversaciones para concretar su política de seguridad de la contraseña a través de todos sus productos de aplicaciones web.

En este momento se está enviando la autenticación de nombre de usuario / contraseña en formularios de envío a través de HTTP, y por lo tanto, están siendo enviadas en texto plano.

La solución más sencilla para el problema es simplemente para requerir HTTPS para el inicio de sesión a través de todas nuestras aplicaciones, ¿verdad?

Bueno, hay cierto debate interno sobre su lugar haciendo algún tipo de encriptación roll-nuestra-propia del cliente de contraseñas (password + sal, etc.).

¿Hay una solución HTTP sólo se acepta?

Las opiniones son como ... bueno, todo el mundo tiene una opinión, así que estoy buscando bibliografía sobre la seguridad creíble que pueda apoyar su recomendación. No sólo Google y me envía a una entrada de blog ... ya he hecho eso y más.

He encontrado las recomendaciones de OWASP: http://www.owasp.org/index.php/Top_10_2007-A7# protección

Además de Microsoft de: http://msdn.microsoft.com/en-us/library/aa302420. aspx

EDIT: Dar a su recomendación para el uso de SSL no es suficiente. Necesito algún tipo de documentación de apoyo. Yo sé que, para reducir nuestro propio cifrado por parte del cliente es malo. Tengo que ser capaz de vender de forma creíble que a compañeros de trabajo y gestión.

Además, HTTP Digest se ha mencionado. Parece agradable, pero Digesto es sólo para la autenticación HTTP, y no para los datos enviados por POST.

Solución

1 a de Mehrdad respuesta . De seguir adelante con la criptografía de cosecha es arriesgado.

Hablando de experiencia aquí, después de haber visto vulnerabilidades en soluciones de cifrado del lado del cliente de cosecha propia. La mayoría de las vulnerabilidades se deben a la misma razón - la transferencia de datos está protegido por un cifrado con una clave secreta, pero la clave se intercambien de manera insegura

TLS / SSL resuelve el problema de no sólo asegurar el intercambio de claves, sino también de la transferencia segura de datos.

TLS / SSL protege su información confidencial mediante el uso de la criptografía de clave asimétrico para el intercambio de la clave simétrica utilizada para cifrar la información de ida y vuelta, una vez que se ha establecido la sesión TLS / SSL. La clave simétrica se genera en tiempo de ejecución, y es un secreto compartido entre el cliente y el servidor; es esta clave que se utiliza para cifrar todo el tráfico restante una vez que la sesión está listo para la transferencia de datos.

claves pública y privada del servidor sólo se utilizan para el intercambio de este secreto compartido. La única forma conocida de comprometer la clave compartida es comprometer la clave privada del servidor (por lo que la clave secreta a continuación, puede ser descifrado). En realidad, se requiere negligencia o malicia por parte del administrador del servidor.

Si sacas su propia solución de cifrado, debe cambiar la clave simétrica, de una manera segura La forma más sencilla de hacerlo es utilizar TLS / SSL; el camino más difícil es implementar su propia solución de intercambio de criptografía de clave asimétrico.

Otros consejos

I altamente recomiendo contra ir con su propia solución (en ambientes sensibles de seguridad). Vaya con SSL. Es una tecnología probada y es fácil de implementar.

rodar sus propias soluciones de seguridad puede ser muy peligroso e incluso si se aplica correctamente (0,000001% de probabilidad), que ser costoso.

Si los datos en sí no es demasiado sensible, pero las contraseñas son, me gustaría sugerir el uso de HTTP la autenticación implícita (que es bastante bestia diferente de la autenticación básica HTTP). Es bastante seguro es a través de HTTP recta, y en absoluto difícil de implementar en el servidor. Nada se envía a través del cable que podrían revelar cuál es la contraseña, simplemente información que permite al cliente para demostrar al servidor que tengan la contraseña correcta.

Si desea una explicación decente de cómo implementar la autenticación HTTP Digest en su aplicación, Paul James tiene un excelente artículo sobre ella .

El único problema real con la autenticación HTTP se encuentra en los navegadores sí mismos: la interfaz de usuario es terrible, pero que puede ser superar con un poco de Javascript .

Puede almacenar las contraseñas de forma segura mediante el almacenamiento de hash A1.

ACTUALIZACIÓN:. Como se ha mencionado en otras respuestas, mientras que el servidor puede evitar ataques MITM al no aceptar la autenticación básica, el cliente sigue siendo vulnerable porque va

ACTUALIZACIÓN:. No se puede asegurar los datos sobre el poste a menos que sea (a) cifrado en JavaScript en el cliente o, (b) hacer todo a través de SSL

puede , con un poco de magia, el uso de autenticación HTTP con formas. El artículo he vinculado a arriba se llama 'HTTP de autenticación de formularios HTML', después de todo. Pero eso no se llevará a cabo durante la POST.

Si realmente a necesitar que hace uso de la POST, el uso de SSL y la sal las contraseñas en su base de datos.

Si desea evitar CSRF, recomiendo el uso de formkeys , aunque la idea pasa por muchos diferentes nombres, me recogieron ese nombre de la piratería Slashcode para mi propio uso hace unos años, que es donde me encontré por primera vez.

Vas a pasar más tiempo y dinero rodar su propia solución y no estar seguro de que es seguro. Industria SSL estándar es fácil de implementar y mucho más seguro fuera de la caja de lo que puede permitirse el lujo de hacer su propia solución.

tiempo == dinero

Comprar un certificado y pasar su tiempo a trabajar en su aplicación en lugar de un formulario de acceso seguro.

cifrado del lado del cliente no puede hacer nada en contra de la mayoría de los ataques MITM. Atacante puede simplemente eliminar la secuencia de comandos.

Es sólo protegerá frente a la inhalación de pasivo. Si eso es lo suficientemente bueno para usted, puede utilizar:

hashing implementado en Javascript. Es fácil de implementar desafío-respuesta para el primer inicio de sesión, pero no hay que olvidar que para la sesión atacante cookie es casi tan buena como la contraseña (que tendría que limitar a un solo inicio de sesión IP y / o usar script para generar cookie de una sola vez para cada petición, que me imagino que sería difícil y solución frágil).
autenticación HTTP Digest. Más seguro, ya que puede utilizar valores hash de una sola vez, la autenticación mutua, etc., pero la interfaz de usuario estándar es absolutamente repulsivo.

... sólo tiene que utilizar SSL.

HTTP únicas soluciones siempre serán susceptibles a ataques man-in-the-middle.

EDIT:. Una traza de red sería una manera fácil de demostrar que no es seguro HTTP

Bueno, aquí está la única respuesta que necesita: Su banco sólo es compatible con entrada / autenticación a través de SSL. Si había una mejor manera de hacerlo, lo harían.

Bueno, hay una cierta discusión interna sobre el lugar haciendo algún tipo de roll-nuestra-propia cifrado del lado del cliente de contraseñas (password + sal, etc.).

Lo primero que tenemos que abordar es los datos en tránsito frente a los datos en reposo. Desde el OP suena como la gran preocupación es nombre de usuario / contraseña en la clara a través de Internet. Por lo tanto, realmente se preocupan por los datos en tránsito. HTTPS a través de SSL es un método probado de hacer esto (y es una solución bastante fácil!). Ahora, si realmente quiere rodar su propia para datos en reposo (en una base de datos, en el servidor de archivos, etc.), que es un animal diferente, pero los métodos existentes para la encriptación de datos van a ser mejor que un rollo de su propio .

Basándose en el lado del cliente para su seguridad es mala. Período. En un entorno corporativo, sí, se puede confiar en algo una configuración estándar. Pero, en última instancia, los usuarios son tontos y se pueden ejecutar a alguien deshabilitar JavaScript o cualquier cliente basado en la solución sacas a cabo, por lo que acaban de enviar el nombre de usuario / contraseña en texto plano de todos modos (incluso si sus servidores 'no saben qué hacer con él porque no está en el formato esperado.

Roll-su-propio no va a estar sujeta al escrutinio que tiene una solución existente. Usted podría terminar la adición de los problemas de seguridad adicionales en la mezcla debido al código.

Acabamos de poner a cabo una aplicación web / móvil para hacer algunas de estas cosas. Se crea direcciones URL al azar para inicios de sesión, usando HTTPS y un método de cifrado hash / AES para el almacenamiento de base de datos. Hay un sencillo API JSON para usarlo sin nuestra interfaz de usuario, aquí está nuestra valoración crítica, darle un aspecto .. http://blog.primestudiosllc.com/security/send-time-limited-secure-logins-with-timebomb-it

usted ha mencionado haciendo su propia encriptación más sal ... se sugiere emplear Javascript MD5 (que también se usa por yahoo en sus páginas no SSL, o al menos eso dice) ...

Y hace doble hash de la contraseña ... Algunos pueden argumentar que la doble dispersión lo haría propenso a ataques de colisión. Tendría que estar en desacuerdo porque la gente ha sido capaz de hacer hasta ahora colisiones firma MD5 sólo en archivos, donde se md5'ed gran cantidad de datos ...

Si se trata de una gran página web corporativa (y no habría motivos para romper en) no hay excusa para no utilizar SSL.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow