Envío de passwords a través de ajax

dado el siguiente escenario: Tenemos un formulario html para cambiar la contraseña de una count. Se parece a esto:

CurrentPassword: __________________ NewPassword: __________________ NewPasswordAgain: __________________ 

Queremos enviar esta request a través de una llamada ajax. Si lo enviamos y nos vamos de nuestra computadora (sin cerrar la session y permanecer en la misma página) alguien podría abrir el inspector de webkit (o firebug) y ver algo como esto:

Screen shot 2011-04-29 at 15.47.15 .png

¿Cuál sería tu solución para hacer esto más seguro? ¿Es posible utilizar una llamada ajax aquí o sería mejor utilizar un formulario html "normal" que vuelva a cargar toda la página después del envío?

El autor no está interesado en las conexiones cifradas aquí. Él bien podría estar haciendo eso ya. Lo que quiere es poder ocultar la contraseña (y el nombre de usuario) de cualquiera que tenga acceso a la computadora, y puede abrir las herramientas del inspector para ver la networking que se produjo en la página.

Una de las cosas más simples que puede hacer es actualizar la página en caso de que la authentication sea exitosa.

Algo que debe hacer es actualizar la página cada vez que el usuario presiona "cerrar session". Esto debería borrar todos los datos de networking anteriores.

Las opciones less buenas son sobre cifrar, ofuscar y cifrar la contraseña antes de enviarla.

Hashing la contraseña en el lado del cliente no es ideal porque esto impide el uso de passwords hash con keys en el lado del server (piense en HMAC). Las passwords HMAC son las mejores, porque la key se guarda en el sistema de files mientras que la sal se mantiene en la database. Romper el hash de contraseña requiere un acceso bastante sólido al sistema.

Ofuscación y encriptación de la contraseña se puede revertir. Si alguien ve una request de inicio de session en Webkit Inspector, podría estar muy interesado en pasar el time para desnudar sus defensas.

Recomiendo actualizar la página en algún momento para evitar el problema por completo. Otras opciones no parecen tan buenas.

El uso de un formulario html "normal" tiene el mismo problema, ya que el rastreo de packages podría revelar los mismos datos en un encabezado POST o GET con la misma facilidad.

La mejor solución que puedo pensar es encriptar la contraseña del lado del usuario a través de javascript. En realidad, no tiene que preocuparse por el "¿y si el usuario tiene javascript deshabilitado?" caso ya que, en ese caso, la request AJAX tampoco se procesará. Obviamente, esto puede tener ramificaciones con respecto a cómo almacenar la contraseña, pero le permitirá continuar utilizando las requestes de AJAX para la actualización de la contraseña.

¡Encripte la contraseña en el transporte y asegúrese de que las llamadas que está haciendo se realicen a través de SSL!

Para hacer esto seguro sin usar SSL, hash las passwords en el cliente usando SHA-2 . Si bien eso protegerá la contraseña en sí misma, no protegerá a nadie de olfatear la contraseña hash . Entonces tampoco puedes autenticarte con la contraseña hash.

Una forma de hacerlo es usar una sal aleatoria generada por el server al autenticarse. Para autenticarse, el cliente solicita sal del server, luego hash la contraseña una vez (para hacer coincidir la versión hash almacenada en el server), luego hashes nuevamente usando esa sal que recibió del server, luego finalmente se autentica usando un segundo ajax consulta con la contraseña salteada con hash.

El server se autenticará solo si coincide con su propia contraseña hash almacenada, hash con la misma sal que proporcionaba previamente el cliente.

De esta forma, es imposible que alguien se autentique usando la versión de hash simple de la contraseña. Como cada sal proporcionada por el server es válida solo una vez, sería esencialmente imposible que alguien la interceptara y autenticara. (Tendrían que interceptar la request de sal, y luego tratar de autenticarse antes de que el cliente legítimo pudiera, todo el time suplantando su session).

Esto protege las passwords de los usuarios sin usar SSL, evita el inicio de session utilizando datos interceptados mientras el usuario legítimo se está autenticando, y es bastante fácil de implementar. Por supuesto, no hay sustituto para SSL en cuanto a la protección de los datos reales en su sitio, pero para muchos sitios web típicos donde no hay realmente información confidencial, debería preocuparse más por evitar el robo de las passwords de sus usuarios dado que las personas usa la misma contraseña tan seguido Esto resuelve ese problema.

Tenga en count que esto tampoco hace nada para evitar el secuestro de la session, pero puede minimizar el riesgo y el daño al hacer cosas como include información específica de los browseres con la session de los usuarios y permitir solo una sola session activa a la vez, y requerir una nueva authentication para cambiar la dirección de correo electrónico o la contraseña.

Dependiendo del nivel de security que necesite, puede usar RSA y cryptography de key pública para encriptar la contraseña dentro del browser antes de enviar la request ajax. En el lado del server, descifrarías las passwords y las procesarías como siempre.

Por supuesto, también deberías tener cuidado de eliminar cualquier variable utilizada para save las passwords ingresadas, y estoy seguro de que hay otros agujeros de security en esto, pero el encryption al less te ofrecerá un alto grado de protección contra ese tipo de ataque. .

Aquí hay una biblioteca que encontré con una búsqueda rápida. (descargo de responsabilidad: no he probado esto, pero se ve bastante bien)

Por último, le recomiendo encarecidamente que transmita toda la información de inicio de session a través de SSL . Esto agrega una capa adicional de security en la parte superior de toda la session del browser entre el browser y su server.