¿Cómo codifico contraseñas en formularios web sin javascript?

No es que no tenga acceso a javascript, por supuesto. En la mayoría de mis cursos de desarrollo web CS, se nos enseña un poco sobre la validación del lado del servidor, y tan pronto como se introduce javascript, la validación del lado del servidor se elimina de la ventana.¿Cómo codifico contraseñas en formularios web sin javascript?

Elijo no solo confiar en javascript, ya que el lado del cliente nunca es un lugar seguro. He adquirido el hábito de escribir tanto el código del cliente como el del servidor para tales cosas. Sin embargo, para una aplicación web que estoy escribiendo que tiene AJAX opcional, no deseo que la contraseña se envíe texto sin formato a través del cable si alguien tiene Javascript desactivado.

Me doy cuenta de que puedo estar planteando una situación de catch-22, así que permítanme preguntarles: ¿cómo sabemos que las contraseñas de nuestros usuarios estarán seguras (suficientes) de usuarios malintencionados en la misma red cuando todos podemos confiar? es el scripting del lado del servidor. En esa primera solicitud desde la página de inicio de sesión, ¿hay alguna forma de que el navegador encripte un campo de datos?

Fuente

2010-02-24 sdellysse

+1 por la paranoia sensible con respecto a sus clientes ... =) –

Sí, de acuerdo. NUNCA confíes en ningún dato del navegador. Un usuario puede cambiarlo a voluntad. Redefina el javascript o apáguelo por completo. O simplemente publique datos de una página en su propio sitio al suyo. Las comprobaciones de Javascript están disponibles ÚNICAMENTE para brindar al usuario una experiencia de IU más fluida y guardar un viaje al servidor para marcar los datos incorrectos. Sin embargo, DEBE repetir todos los controles nuevamente en el servidor. – Cheekysoft

SSL Resuelve este problema. Para el registro, las contraseñas nunca deben estar "encriptadas" o "codificadas", esto emplea que hay un método de "Decodificación" o "Descifrado" que es una clara violación si CWE-257. Las contraseñas deben ser hash, SHA-256 es una gran opción, pero esto no es para transmisión, solo almacenamiento. Cuando transmite secretos, hay una larga lista de cosas que pueden salir mal, SSL es, de lejos, la mejor opción para resolver estos problemas.

Si el atacante puede oler el tráfico, podrán ver la identificación de la sesión y usarla inmediatamente, por lo que es un punto discutible. Debe usar SSL para proteger la sesión autenticada de todos modos.

Fuente

2010-02-24 02:57:16 rook

Entonces, lo que obtengo es esto: si un usuario tiene que iniciar sesión en un sitio y no quiere que nadie escuche, use SSL para cada página, incluidas las que están después del inicio de sesión. ¿Cómo es que este sitio es http: // y no https: //? ¿Mala práctica? ¿O me estoy perdiendo otro concepto? – sdellysse

Su derecho, nada impide que un atacante secuestre una sesión de stackoverflow olfateando el tráfico. Podrías estar tomando un chi caliente en un café usando la conexión inalámbrica abierta y haciendo que te secuestrasen. La mayoría de los desarrolladores no entienden esto, pero si observas cualquier portal de banca en línea como bankofamerica.com, protegerán todas las sesiones autenticadas con SSL. – rook

Las posibilidades de que alguien detecte su inicio de sesión aquí son remotas en el mejor de los casos, y si usa un OpenID para iniciar sesión, ese sitio es responsable de la autenticación (en mi caso, hecho a través de HTTP Digest, que es hash). Para aumentar la improbabilidad de que alguien detecte su sesión de stackoverflow, a la mayoría de las personas que tienen esas habilidades no les importaría stackoverflow o desfigurar su cuenta de todos modos. –

La solución fácil es SSL.

Fuente

2010-02-24 01:49:16

También puede usar Digest HTTP Authentication.

Fuente

2010-02-24 03:00:36

HTTP Digest no permite un inicio de sesión basado en formulario. –

He estado buscando esto como loco. Hice una pregunta aquí, pero creo que no entendí la respuesta.Entonces, ¿podría dejar de buscar y descartar cualquiera de mis pruebas de cifrado y buscar SSL? – Jigzat

Creo que estás mezclando un par de conceptos. El navegador no encripta campos individuales. Las secuencias de comandos del lado del cliente, las secuencias de comandos del lado del servidor y AJAX no son medios para defenderse contra el espionaje.

Como han dicho otros, SSL es la tecnología que encripta los datos. Toda la solicitud y respuesta, incluidos los campos y las secuencias de comandos, están incluidas en la sesión SSL.

Fuente

2010-02-24 03:24:31

Eso es cierto, estaba mezclando cosas equivocadas. Después de leer estas respuestas, tiene sentido que SSL encripte todo, o de lo contrario no sería de mucha utilidad. Creo que me faltaba el bosque para los árboles. – sdellysse

¿Cómo codifico contraseñas en formularios web sin javascript?

Respuesta

Cuestiones relacionadas