¿Qué tan seguro es enviar una contraseña de texto sin formato con AJAX?

Question

Tal vez el título está mal redactado, pero no se le ocurrió una mejor manera de decirlo.

Estoy trabajando en un sistema de inicio de sesión en este momento (nada formal, simplemente experimentando) y estaba planeando utilizar PHPLiveX (una biblioteca AJAX) para algunas características. Básicamente, usted crea algunas funciones de PHP que luego se llaman a través de JavaScript. Puede agregar parámetros (getElementById) al JavaScript que se transfiere a la función PHP.

Lo que realmente quería saber es si es seguro llamar simplemente a la función desde JavaScript sin cifrar primero la contraseña, y luego dejar que la función PHP la cifre (SHA256 en este caso). ¿Se pueden interceptar los datos transferidos a través de AJAX? Si es así, ¿qué tan probable es esto?

Answer 1

No más o menos seguro que una solicitud POST HTTP normal, emitido por un navegador (como en a partir de una <form>)

El "FIX" para esto es la misma "solución" para no AJAX solicitudes: use SSL.

Answer 2

Las llamadas AJAX son simplemente una solicitud HTTP.

Se comporta como una solicitud HTTP normal y también viene con todas las ventajas y desventajas de la misma. No es más seguro.

Para hacer su llamadas AJAX seguro, hay varias formas en las que puede probar:

1. Usar SSL. SSL cifrará los mensajes entre su usuario y su servidor. La desventaja de SSL es que tendrá que pagar una tarifa adicional para los certificados SSL válidos. Los certificados SSL no válidos, aunque utilizables, no brindan el mismo nivel de garantía de seguridad a los usuarios.
2. Encripta las solicitudes antes de enviarlas, del lado del cliente. Por ejemplo, hash contraseña de los usuarios antes de ser enviado a través de la red. La mayoría de las veces, no necesita la contraseña de texto sin formato de todos modos. Esto no se puede usar cuando los usuarios no permiten la ejecución de scripts del lado del cliente.
3. Y aparte de la información engañosa común donde la POST es más segura que GET, no lo es. Ambos son igualmente abiertos para que los atacantes los vean.

Answer 3

Ya sea que esté enviando la contraseña a través de AJAX o mediante un formulario normal, todavía se envía a través de una solicitud HTTP POST (con suerte). Por lo tanto, no agrega ni elimina nada relacionado con la seguridad.

La única manera de evitar que alguien intercepte su contraseña es mediante el uso de SSL (a través de AJAX o no).

Answer 4

La contraseña de texto sin formato transmitida a través de AJAX será tan segura como la misma contraseña transmitida a través de una publicación HTTP normal. Es decir, AJAX usa HTTP y, por lo tanto, puede ser interceptado y olido. Su mejor opción es usar HTTPS (SSL).

Para leer más acerca de AJAX y seguridad te recomiendo las siguientes lecturas

• Top 10 Ajax Security Holes and Driving Factors
• Ajax security holes and how to fill them

Answer 5

Esto es tan seguro como tener un formulario de acceso que no está asegurada SSL ser enviado por el cable, ¡como lo hacen casi todos los foros!

Answer 6

No es seguro. No envíe contraseñas no cifradas. Es muy probable que sean interceptados en algún momento, tendrás un problema importante.

Aquí hay un ejemplo de video de capturar una contraseña de telnet. Telnet envía en texto plano y esto ilustra muy bien el problema principal que tiene si siquiera piensa en hacer esto. Cualquier script kiddie de dos bits puede atrapar una contraseña de texto simple más rápido que tú, así que "Dios mío, ¿a dónde fue mi base de datos?"

Answer 7

Asegúrate de que el objetivo de tu llamada AJAX sea una página HTTPS: // de confianza y asegúralo tan seguro como cualquiera de los otros envíos de la misma información que el resto de tu aplicación. La mayoría de las bibliotecas/frameworks no te limitan a solo HTTP: // para tus llamadas AJAX.

Answer 8

Lo está enviando sin cifrar, por lo que cualquier persona que olfatea/escucha/etc. la red del cliente podrá ver fácilmente la contraseña. La llamada AJAX es solo un simple mensaje HTTP antiguo. Si desea ver esto en acción, ejecute una copia de wireshark y realice la solicitud usted mismo. Podrá ver la contraseña en el paquete HTTP.

Answer 9

Sí, se puede leer. Al igual que todo lo demás sin algún tipo de capa de seguridad (Consulte SSL)

Para verlo usted mismo ejecute una herramienta como WireShark mientras hace sus comandos AJAX.

¿Cuán probable es? No muy, pero la contraseña del usuario probablemente se guardará en los archivos de registro de alguien en texto plano. Si alguien finalmente lo encontró, entonces podrían ser malas noticias. De vuelta a la universidad, mi clase de redes tenía acceso a algunos enrutadores (semi) sofisticados. Tuvimos asignaciones donde nos registramos para cuentas en sitios web aleatorios. Al hacer esto, notamos algunas cosas muy atemorizantes en los archivos de registro en los enrutadores. Esta fue una revelación para que yo piense en cómo se rastrea cada comunicación y lo más probable es que se registre en alguna parte.

Answer 10

Como han mencionado otros, no es más peligroso que enviar una publicación HTTP desde un formulario. De hecho, es lo mismo.

Pero si HTTPS no es una opción, siempre puede usar un esquema de desafío/respuesta sobre una conexión no encriptada. Básicamente funciona así:

• El servidor tiene un SHA (o cualquier algoritmo de hash que prefiera) hash de la contraseña del usuario.
• El cliente tiene la contraseña.
• Las solicitudes de cliente (utilizando AJAX sin cifrar) que el servidor envíe un desafío (una cadena aleatoria de bytes; personajes están muy bien.)
  
• Server crea un desafío y una identificación desafío, y la guarda con una caducidad.
• El cliente recibe la identificación de desafío y desafío.
• El cliente codifica la contraseña usando SHA.
• El cliente realiza el hash resultante del hash con el desafío adjunto de alguna manera.
• El cliente envía la identificación del desafío (no el desafío en sí) y el segundo hash resultante.
• El servidor busca el desafío usando ID si existe y no ha expirado.
• El servidor anexa el desafío al hash de contraseña almacenado y crea un hash usando el mismo esquema que el cliente.
• El servidor compara su hash con el cliente.Si es lo mismo, el usuario está autenticado.

De hecho, es muy fácil de configurar una vez que se entiende la idea. Wikipedia tiene algo de información adicional al respecto.

EDIT: me di cuenta me olvidé de mencionar, si la autenticación es exitosa se debe eliminar el reto, sin tener en cuenta. Dar al cliente múltiples intentos en un desafío podría generar problemas de seguridad.

Answer 11

Como ya se ha mencionado, SSL es la mejor solución aquí. Sin embargo, podría hash la contraseña en el lado del cliente. Si busca en Google, encontrará muchas implementaciones de javascript de md5.

Answer 12

maldita sea que ustedes me preocupan. SSL no protege contra el ataque MITM de envenenamiento arp. Sería fatal adorar SSL como ustedes. Debe tener una forma de encriptar la contraseña del lado del cliente antes de que salte un solo salto, o incluso un novato novato podrá interceptar la contraseña en texto sin formato

Answer 13

También se debe tener muy en cuenta las posibles vulnerabilidades de seguridad al construir una aplicación que utiliza Ajax.

El siguiente sitio tiene la muy buena información en lo que respecta a Ajax y XSS o XSRF ataques http://www.isecpartners.com/files/isec-attacking_ajax_applications.bh2006.pdf

No hay que olvidar que cuando se hace una función remota accesible a una llamada de JavaScript, un usuario podría simplemente adivinar la función llamar y modificarlo para hacer su oferta.