Técnicas para hacer segura una página de inicio de sesión sin usar SSL

¿Por qué te niegas a usar TLS? Funciona, tiene un buen historial (aparte de algunas excepciones menores). Negarse a usar buenas herramientas sin una razón convincente no genera confianza y no sugiere de inmediato la profesionalidad.

Además, no ruede su propio sistema de autenticación. Eso es tonto, y cometerás errores. En cambio, como espera que sus usuarios tengan una cuenta de Facebook, use OAuth2 para consumir la autenticación y la identidad federada. Aún mejor, externalice esto a un servicio de federación que lo ha dominado e incluso proporciona fragmentos de código ( enlace me viene a la mente).

No hagas tu vida difícil.

Los certificados SSL / TLS serán gratuitos para el segundo trimestre de 2015. Obtenga el certificado aquí:

enlace

Let's Encrypt ofrecerá certificados validados en el dominio firmado a través de IdenTrust sin cargo alguno.

Cuando esto esté activo, estas preguntas deberían cerrarse, IMHO

  

¿Cuáles podrían ser otros buenos consejos para lograr la mayor seguridad posible sin utilizar SSL?

Puedes usar TLS en lugar de hacer algo estúpido.

Lo que intenta hacer es imposible sin una forma segura de enviar sus archivos al cliente, como TLS. Los métodos de hashing de la contraseña del lado del cliente requieren que el javascript se envíe de forma segura al cliente. De lo contrario, un MITM podría simplemente servir un script que no elimine la contraseña, sino que les envíe la contraseña de texto sin cifrar directamente.

La parte importante es que necesita código de confianza en el cliente . Con TLS, ese código de confianza es el navegador, que a su vez verifica la integridad de su javascript para que también sea confiable. Sin confiar en eso o algo equivalente (que no conozco), no puede hacer suposiciones sobre lo que se ejecuta en la máquina del cliente.

La única forma de estar seguro sin TLS es mediante un complemento del navegador, que debe descargarse ... sobre TLS. Y un complemento del navegador es un gran inconveniente de usabilidad.

El motivo de esto es que debe haber algún código de confianza en la computadora del usuario. Puede ser el código TLS en el navegador del usuario o el código del complemento.

Las otras respuestas son claras: use SSL

sin embargo, para señalar qué fallaría si lo implementara como se describe:

  

Pensé en resolverlo con un primer hash en el lado del cliente con   JavaScript y luego en el lado del servidor, si recibo valores hash (en   En caso de que alguien borre algún JavaScript), un segundo hash y tienda.   esos valores hash en la base de datos de usuario. ¿Es una forma segura de   ¿Impleméntalo? Además, ¿hay alguna posibilidad de que algunos datos se pierdan? Si   entonces, ¿cómo puedo saber si los datos recibidos no están comprometidos?

Por lo tanto, en este caso, un MITM recibiría el hash enviado por el cliente: si se trataba de un inicio de sesión o similar, podrían copiarlo y enviarlo cada vez que deseen iniciar sesión como X. Posibilidad de pérdida de datos ? con un MITM, básicamente se garantiza que se pueden perder algunos datos. La pregunta es: ¿podrá usted detectarlos? En cuanto a cómo sabe que los datos recibidos no están comprometidos, la forma típica sería firmarlos.

Si realmente no debe usar SSL, podría retirarlo de manera segura a través de WS Security en su lugar, pero advirtió, esto va a ser más complicado que solo SSL.

  

Proteger de ataques de diccionario y de fuerza bruta.

En general, pueden ser derrotados como lo describió usted, sin embargo, las veces que realmente necesita preocuparse por los ataques de fuerza bruta son ataques sin conexión, es decir, cuando su código no se está ejecutando y no puede proteger los datos al limitar la frecuencia de intentos de inicio de sesión - Se requieren muchas rondas de hash para hacer eso

  

El formulario de inicio de sesión. Lo implementé de esta manera (sin el hashing para   ahora)

¿cuál sería exactamente la diferencia para un atacante si vieran una URL con hash o una carga útil con hash de los mismos datos? De todos modos, si no desea que los datos estén en la URL, use un POST HTTP en lugar de un GET HTTP

En realidad, existe un esquema de autenticación "seguro" en la web que precede a SSL denominado autenticación de acceso digital , así que El interrogador está preguntando no es del todo imposible. Esto es MUCHO menos seguro que SSL, y está sujeto a que la fuerza bruta de la contraseña a través de ataques sin conexión, así como el uso de un algoritmo de hashing antiguo y de poca confianza de MD5.

Sin embargo, seguiría dando el mismo consejo que todos los demás y te diré que SSL es, con mucho, la mejor solución que confiar en un sistema obsoleto basado en desafío-respuesta que no se ha actualizado desde 1993.