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

Question

Una compañía que conozco está en conversaciones para reforzar su política de seguridad de contraseñas en todos sus productos de aplicaciones web.

En este momento están enviando la autenticación de nombre de usuario/contraseña en formularios POST a través de HTTP, y por lo tanto, se están enviando texto sin formato.

La solución más simple al problema es simplemente requerir HTTPS para el inicio de sesión en todas nuestras aplicaciones, ¿verdad?

Bueno, hay una discusión interna sobre el hecho de hacer algún tipo de encriptación de contraseñas de nuestro cliente (contraseña + sal, etc.).

¿Hay una solución aceptada solo HTTP?

Las opiniones son como ... bueno, todos tienen una opinión, entonces estoy buscando literatura de seguridad creíble que pueda respaldar su recomendación. No solo busque en google y envíeme a una publicación de blog ... Ya lo hice y más.

he encontrado recomendaciones de OWASP: http://www.owasp.org/index.php/Top_10_2007-A7#Protection

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

EDIT: dando a su recomendación para el uso de SSL no es suficiente. Necesito algún tipo de documentación de respaldo. SÉ que rodar nuestro propio cifrado del lado del cliente es malo. Necesito poder vender de manera creíble eso a los compañeros de trabajo y la administración.

Además, se ha mencionado HTTP Digest. Parece agradable, pero Digest es ÚNICAMENTE para la autenticación HTTP, y no para los datos enviados a través de POST.

Answer 1

1-Mehrdad's answer. El ir adelante con la criptografía de cosecha es arriesgado.

Hablando de experiencia aquí, después de haber visto en las vulnerabilidades de cosecha cliente-si de soluciones de cifrado. La mayoría de las vulnerabilidades se deben a la misma razón: la transferencia de datos estaba protegida por encriptación con una clave secreta, pero la clave en sí misma se intercambió de manera insegura.

TLS/SSL resuelve el problema no solo del intercambio seguro de claves, sino también de la transferencia segura de datos.

TLS/SSL protege su información sensible mediante el uso de criptografía de clave asimétrica para intercambiar la clave simétrica utilizada para encriptar 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 la que se utiliza para cifrar todo el resto del tráfico una vez que la sesión está lista para la transferencia de datos.

Las claves públicas y privadas del servidor se utilizan solo para intercambiar este secreto compartido. La única forma conocida de comprometer la clave compartida es comprometer la clave privada del servidor (para que la clave secreta pueda descifrarse). En realidad, requiere negligencia o malicia por parte del administrador del servidor.

Si transfiere su propia solución de cifrado, debe intercambiar la clave simétrica de forma segura. La manera más fácil de hacerlo es usar TLS/SSL; la forma más difícil es implementar su propia solución de cifrado de intercambio de claves asimétricas.

Answer 2

I altamente recomendamos que contra vaya con su propia solución (en entornos sensibles a la seguridad). Ir con SSL Es una tecnología probada y es fácil de implementar.

Hacer rodar sus propias soluciones de seguridad puede ser realmente peligroso e incluso si se implementa correctamente (0,000001% de posibilidades), será costoso.

Answer 3

Si los datos en sí no son muy sensibles, pero sí las contraseñas, sugiero usar HTTP digest authentication (que es una bestia bastante diferente de la autenticación básica de HTTP). Es bastante seguro sobre HTTP directo, y no es difícil de implementar en el servidor. No se envía nada por el cable que pueda revelar cuál es la contraseña, solo información que permite al cliente demostrarle al servidor que tiene la contraseña correcta.

Si desea una explicación decente sobre cómo implementar la autenticación resumida HTTP en su aplicación, Paul James has an excellent article on it.

El único problema real con la autenticación HTTP está en los navegadores mismos: la interfaz de usuario es terrible, pero puede ser overcome with some Javascript.

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

ACTUALIZACIÓN: Como se menciona en otras respuestas, aunque el servidor puede evitar ataques MITM al no aceptar autenticación básica, el cliente sigue siendo vulnerable porque lo hará.

ACTUALIZACIÓN: No puede proteger los datos a través de POST a menos que (a) haga encriptación en JavaScript en el cliente o, (b) haga todo a través de SSL.

Usted puede, con un poco de magia, use HTTP auth con formularios. El artículo que he vinculado anteriormente se llama 'HTTP Auth with HTML forms', después de todo. Pero eso no se hará a través de POST.

Si usted realmente lo necesita, utilice POST, use SSL y escriba las contraseñas en su base de datos.

Si quieres evitar CSRF, te recomiendo usar formkeys, aunque la idea tiene muchos nombres diferentes, recogí ese nombre de hackear Slashcode para mi propio uso hace unos años, que es donde lo encontré primero.

Answer 4

Las soluciones HTTP solo siempre serán susceptibles a los ataques de hombre en el medio.

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

Answer 5

La encriptación del lado del cliente es impotente contra la mayoría de los ataques MITM. El atacante simplemente puede eliminar tu script.

Solo protegerá contra el olfateo pasivo. Si eso es lo suficientemente bueno para usted, puede usar:

• Hashing implementado en Javascript. Es fácil implementar desafío-respuesta para el inicio de sesión inicial, pero no olvide que para la cookie de sesión del atacante es casi tan bueno como la contraseña (tendría que limitar el inicio de sesión a una sola IP y/o usar script para generar una cookie única para cada solicitud, que me imagino que sería una solución difícil y frágil).
• Autenticación HTTP Digest. Más seguro, ya que puede usar hashes únicos, autenticación mutua, etc., pero la interfaz de usuario estándar es absolutamente repugnante.

... solo use SSL.

Answer 6

Pasarás más tiempo y dinero rodando tu propia solución y no estarás seguro de que sea segura. El estándar industrial SSL es fácil de implementar y mucho más seguro de lo que puede permitirse hacer su propia solución.

tiempo == dinero

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

Answer 7

Bien, aquí está la única respuesta que necesita: su BANCO solo admite el inicio de sesión/autenticación a través de SSL. Si hubiera una mejor manera de hacerlo, lo harían.

Answer 8

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

Lo primero que debemos abordar es la información en tránsito frente a la información en reposo. Desde el OP parece que la gran preocupación es el nombre de usuario/contraseña en forma clara a través de Internet. Entonces, realmente te importan los datos en tránsito. HTTPS a través de SSL es un método probado para hacer esto (¡y es una solución bastante fácil!).Ahora, si realmente desea obtener los propios datos en reposo (en una base de datos, en un servidor de archivos, etc.), esa es una bestia diferente, pero los métodos existentes para el cifrado de datos serán mejores que un rollo propio .

Confiar en el lado del cliente para su seguridad es malo. Período. En un entorno corporativo, sí, puede confiar en una configuración estándar. Pero, en última instancia, los usuarios son tontos y puede encontrarse con alguien que deshabilita javascript o cualquier solución basada en cliente que implemente, por lo que terminan enviando 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 una solución existente tiene. Usted podría terminar la adición de los problemas de seguridad adicionales en la mezcla debido al código.

Answer 9

mencionaste hacer 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 el doble hashing 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 md5 colisiones de firmas solo en archivos, donde hay una gran cantidad de datos md5'ed ...

Si es un sitio corporativo grande (y habría razones para irrumpir) no hay excusa para no usar SSL.

Answer 10

Acabamos de publicar una aplicación web/móvil para hacer algunas de estas cosas. Crea URL aleatorias para inicios de sesión, utilizando HTTPS y un método de cifrado hash/AES para el almacenamiento de la base de datos. Hay una API JSON simple para usarla sin nuestra interfaz de usuario, aquí está nuestro informe, echele un vistazo. http://blog.primestudiosllc.com/security/send-time-limited-secure-logins-with-timebomb-it