2011-11-18 9 views
5

De una gran cantidad de publicaciones que he visto en el sitio, los inicios de sesión realizados por AJAX o los formularios tradicionales son tan seguros entre sí. (Re: Login/session cookies, Ajax and securityAjax login and javascript cookies, is this secure?)Javascript hashing en llamadas de inicio de sesión AJAX, más seguridad?

Mi pregunta (s) es/son:

  1. Si hash de la contraseña del usuario (a través del lado del cliente/javascript hash de bibliotecas) antes de enviarlo al servidor ¿Aumento la seguridad de la reducción de personas?

  2. Si pongo un token de formulario (uno al azar, otro basado en el tiempo), ¿eso cubre los ataques CSRF?

  3. ¿Tendría todas mis bases cubiertas después de todo esto? ¿Esta forma sería segura?
+1

Use SSL si necesita enviar contraseñas (y si es posible para todo lo demás que no tenga también una cookie de sesión de inicio de sesión). – Thilo

Respuesta

5

En realidad, esto podría ser un problema de seguridad importante. La razón por la cual las contraseñas son hash es un medio para planificar el fracaso. Un atacante podría obtener acceso al almacén de datos (inyección sql) y luego obtener el hash. Si acaba de iniciar sesión con un hash, entonces el atacante no tiene que descifrar el hash recuperado para obtener acceso a la aplicación.

Los ataques de reproducción también son un problema. Si olfateo el hash durante la autenticación, ¿qué impide que vuelva a reproducir esa solicitud para autenticarse?

Los protocolos que usan funciones de resumen de mensajes para la autenticación proporcionan al cliente un nonce, que se utiliza como una sal única. La autenticación SMB NTLM de Microsoft es un buen ejemplo, pero ha tenido a lot of problems.

USE SSL, y no solo para iniciar sesión. OWASP A9 indica que la identificación de la sesión nunca debe filtrarse a través de un canal inseguro. Después de todo, ¿a quién le importa la contraseña si solo derrama las credenciales de autenticación reales algunos milisegundos después?

La mayoría de las personas no implementan la protección CSRF para iniciar sesión. Después de todo, el atacante tendría que saber la contraseña desde el principio, por lo que "montar la sesión" es un punto discutible.

+0

Solo por curiosidad, si utilizara cifrado de clave pública en la contraseña antes de enviarla, y luego descifrara la contraseña en el servidor utilizando la clave privada correspondiente, ¿sería eso mejor? – Esailija

+0

@Esailija El cifrado asimétrico tiene sus propios problemas, como ataques de reproducción y falta de IV. Pero más importante aún si no estás protegiendo la identificación de la sesión, entonces no estás protegiendo nada. Cualquier atacante que olfatee el cable tendrá acceso completo. – rook

+0

Ah sí, debería haber leído su respuesta con más reflexión. Me perdí completamente la última parte del tercer párrafo ... bueno, gracias por responder. – Esailija

0

Si el atacante sabe qué hash está utilizando, entonces puede descifrarlo. Y si desea agregar una sal, debe enviarla al navegador y el atacante podría interceptarla. Usar el tiempo como sal tampoco funcionará porque solo hay una cantidad de tiempo relativamente corta para que puedan resolverlo también.

+0

"Hashing" (a diferencia del cifrado) generalmente no es reversible. –

+0

@DavidGelhar Gracias, cambié la redacción, era una mala elección de palabras de mi parte. – qw3n

+1

@David Gelhar significa un ataque trivial. John el destripador, o arcoiris, debería hacer el truco. – rook

1

Un pequeño aparte, pero en respuesta a la pregunta 3. ¡NO! Además, recuerde que AJAX y los formularios estándar también son tan inseguros entre sí.

La implementación de autenticación segura es difícil. A menos que lo esté haciendo como un ejercicio académico, le recomendaría utilizar la biblioteca proporcionada por su marco, si tiene la suerte de tener uno bueno.

También tendrá que considerar cosas como las siguientes, y más.

  • Implemente una identificación de sesión adecuadamente aleatoria e indescifrable para su uso en la cookie de sesión.
  • No permita que se fuerce la identificación de la sesión.
  • Cuando se cambian los permisos o las credenciales (por ejemplo, porque el usuario ya inició sesión o se desconectó), entonces invalida inmediatamente la sesión y comienza una nueva.
  • Proporcione una función de cierre de sesión y asegúrese de invalidar la sesión al cerrar la sesión.
  • Establezca la cookie en HttpOnly: preferiblemente, solicite HTTPS y configure la cookie como segura únicamente.
  • Considere restringir la validez de la sesión para incluir la comprobación de otra información que ayude a hacer coincidir al usuario, p. agente de usuario.
  • Siempre caduque las sesiones después de la no utilización y no implemente "mantenerme conectado" al volver a conectar al usuario a su antigua sesión http.
  • Asegúrese de que 2 sesiones no pueden tener el mismo ID de sesión al mismo tiempo
  • Asegúrese de que todos los datos de sesión se destruyan cuando se invalide una sesión. Un nuevo usuario que viene, puede recibir una identificación de sesión que se haya usado previamente. Esta nueva sesión no debe tener ningún acceso a los datos de sesión que se hayan establecido previamente en esa identificación de sesión.
+0

Esto es genial! Es "Asegúrese de que 2 sesiones no pueden tener la misma identificación de sesión al mismo tiempo" incorporada a la función session_start() de PHP. –

+1

@JosephSzymborski sí. Puede encontrar este interesante re php http://phpsec.org/projects/guide/4.html – Cheekysoft

Cuestiones relacionadas