'Recordar-me' característica de autenticación, lo hace siempre media página web 'no seguro'?

Question

Estoy pensando en poner en práctica el clásico 'recordar-me' casilla de verificación en mi aplicación web para permitir que el usuario autenticado a ser 'recordado' una vez que regrese a visitar mi página web.

Gmail , Facebook y otros tienen este tipo de función, pero no estoy muy seguro de cómo asegurar que puede ser.

Un marco de Java como usos Spring Security un 'hash-Based Enfoque de emergencia'. La señal que se genera (con nombre de usuario, contraseña, y una expirationTime PrivateKey) se almacena en las cookies del Cliente 'token = 567whatever567'. El token se vuelve a utilizar después de volver a autenticar al usuario la próxima vez que vuelva.

a mí respecta al hecho de que aunque el proceso de inicio de sesión que pasó bajo una conexión https, en cada petición HTTP posterior se enviará sin cifrar la cookie en la red.

Básicamente todos puede leer el token y reutilizarla para autenticar.

Estoy tratando de echar un vistazo a la forma en Gmail o Facebook están implementando esta funcionalidad. Puedo ver algunos de cookies como 'presencia DJ267619445G09H0L15228675 = .....' en FB, otros en Gmail.
No estoy muy seguro de si utilizan algún otro truco para proteger en contra de alguien que trata de hacerse pasar por otro usuario.

Voy a tratar de hacerse pasar por mí mismo usando algo así como cURL para ver si sólo está utilizando una específica contadores a recordar al usuario.
Si son lo que parece a mí como un gran problema de seguridad. Tal vez no facebook (no me importa de ella) pero con Gmail si no se establece ' Usar siempre https ' una conexión HTTP se utilizará y enviará sus fichas no cifrados a través de Internet.
¿Qué opinas?

También he notado que los campos nombre de usuario / contraseña de Facebook están expuestos bajo http (no https). En este sentido También me pregunto: ¿Son todos los sitios web que exponen campo de nombre de usuario / contraseña a través de HTTP no seguro 'por naturaleza'. Una vez que la solicitud se envía a través de HTTP no hay es 'redirección a https' que puede arreglar las 'credenciales visibles para el mundo' problema.

Gracias

Editar :
Mis preocupaciones eran fundadas http://codebutler.com/
Gracias a las Firesheep creadores para poner de relieve el problema !!!

Answer 1

No es un problema semejante para implementar un recuerdo-me. Lo que hay que hacer es mantener la sesión activa por mucho tiempo (y establecer la cookie para durar mucho tiempo). Incluso Gmail sesión se cerrará después de cierto período (creo que es dos semanas o un mes). Sin embargo, es necesario darse cuenta de que mantener la misma sesión abierta más tiempo aumenta la posibilidad de secuestrar en ella. Como contramedida, es necesario aumentar la fuerza de su identificador de sesión. identificador de sesión es la que está en la cookie (o en el URI que suele verse en algún software como "archivo.php? PHPSESSID = 1234 ...").

La clave es mantener una fuerte identificador de sesión. Por ejemplo, en Gmail, usted tiene un GX galleta con un valor similar a

DQAAAJoAAAA8mnjaAwgkS7y8Ws5MYCl-PAQLp9ZpMXpGKR47z4L9mlBH-4qEyApAtFbnLkzv1pPqxua1hOWMGiKYpBZr-h7Icyb-NUUg2ZW_nUFIymvw9KjmjSECYTowbCsDerkAxCzSDa83b5YC1mykPv1a9ji4znt6Fsna-AKgNTntvmUxeJ92ctsSlg9iGySEmXnisVyyJiQvI8jzbZqSpE_N2RKZ

El motivo por el secuestro de sesiones es más o menos imposible es, debido a que el identificador de sesión es tan fuerte, y debido a que el sitio utiliza HTTPS en todas partes. Nadie puede adivinar o de otra manera obtener su identificador de sesión (por lo tanto no puede secuestro en su sesión). En un rápido vistazo, el identificador de sesión anterior parece tener un poco ~ 1250 bits de fuerza, 1 * 10 ^ 376 posibilidades diferentes. Nadie puede adivinar que.

Es obvio que será siempre posibles formas de seguir secuestro en la sesión. Por ejemplo, las vulnerabilidades XSS abren el camino de la puerta para conseguir las cookies y por lo tanto su identificador de sesión, pero esto no es culpa de tus sesiones de ninguna manera, y no tiene nada que ver con una "recordar-me".

  

a mí respecta al hecho de que aunque el proceso de inicio de sesión que pasó bajo una conexión https, en cada petición HTTP posterior se enviará sin cifrar la cookie en la red.

Si se establece el indicador seguro de galletas a la verdadera mientras que en HTTPS, la cookie nunca será enviada al acceder al sitio a través de HTTP. Es una necesidad para hacer por sitios HTTPS solamente.

En general, la gente parece usar sólo HTTPS para la página de conexión, lo cual es incorrecto. Si uno se preocupa de verdad, él debe utilizar HTTPS por toda la página. De lo contrario, es imposible evitar todos los intentos de secuestro de sesión.

¿Por qué muchos todavía utilizan HTTPS sólo para el registro, en parte? Probablemente debido a que no se dan cuenta lo que está en las apuestas, o porque es demasiado pesado para CPU utilizan HTTPS en todas partes. Sin embargo, todavía es mejor utilizar HTTPS para el inicio de sesión que no utilizarlo en cualquier lugar - ya que encripta las credenciales (por tanto, sólo el identificador de sesión puede ser robada más tarde, no las credenciales reales durante el inicio de sesión)

  

Tal vez no facebook (no me importa de ella) pero con Gmail si no se establece 'Usar siempre https' se utilizará una conexión HTTP y enviará sus fichas no cifrados a través de Internet.   ¿Qué opinas?

Creo que el valor por defecto debe a HTTPS en todos los casos, si es posible. La única verdadera razón de por qué no utilizar HTTPS es dinero (= rendimiento / hardware).

Answer 2

Es generalmente llamado un ataque de repetición. El atacante reproduce una petición con las mismas credenciales (por ejemplo, cookies) que te robó, y es capaz de hacerse pasar por ti. El ataque XSS es sólo una variación de esto, pero se puede prevenir (por ejemplo, usando HTTPOnly).

La única manera de mitigar la mayoría de los ataques de repetición es https en todas partes. Eso debería mantener a la mayoría de las miradas indiscretas.

Hay un montón de técnicas de prevención también.

También hay dispositivos de hardware que hacen un mejor trabajo que se puede cortar a cabo en el software, lo que frena su servidor en el proceso, y es probable que se equivocan. hardware especializado puede hacer un mejor trabajo de seguimiento de solicitudes en tiempo real y determinar que la misma razón está siendo utilizado por diferentes muchos todo IP de, al mismo tiempo, y más rápido que un solo operador humano debe ser capaz de petición.

En ASP.NET 2.0 +, el uso de formularios de autenticación, puede especificar requireSSL='true' para indicar que los navegadores sólo deben enviar la cookie de autenticación cuando se realiza una conexión HTTPS. Ver este artículo de MSDN para obtener más información sobre cómo asegurar la autenticación de formularios.

---

La única razón para no permitir que remember me es si usted es una entidad bancaria o aplicación similar. Si no está, sólo tienes que seguir unas cuantas reglas sencillas:

1. Si tiene remember me, poner de caducidad de la cookie en la mayoría de los 30 días en el futuro y no se deslizan el valor. Obligando al usuario a inicio de sesión una vez al mes no es tan malo.
2. Las operaciones sensibles requerir una contraseña. Cuando la actualización de la facturación, tarjetas de crédito o detalles de la cuenta siempre re-petición de la contraseña de los usuarios. La forma más probable de abuso es normalmente a través del mismo equipo que la persona está utilizando, sino que también asegura que incluso una cookie de autenticación robada por sí mismo no puede hacer demasiado daño. Se puede ver el saldo de mi, pero no se puede transferir nada.

Answer 3

De acuerdo con la mayoría de los comentarios hechos anteriormente. Si está preocupado por la seguridad, que debería -

a) El uso de HTTPS en todas partes. Incluso Gmail recientemente pasado a utilizar https por defecto - ver http : //gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html

b) Establecer la bandera seguro en su cookie de sesión para impedir que el navegador de enviarla a través de una conexión HTTP.

c) Fijar XSS en su aplicación. Si usted tiene problemas de XSS, su implementación de 'Recordarme' siempre va a ser no seguro. Ver OWASP XSS Prevención hoja de trucos.

La dirección IP Incluyendo en el identificador de sesión no va a ayudar. Hacer esto hará que el 'yo recuerde funcionalidad' bastante inútil, y que no aporta mucha seguridad. Sé con seguridad Google no pone direcciones IP en su identificador de sesión.

Answer 4

La única manera de hacer sitio totalmente seguro es permitir a https en todas partes. Tienes razón, las cookies pueden ser inhalados y posteriormente utilizar para suplantar.

Answer 5

Hay un par de formas de impiden secuestro de sesión , tales como el almacenamiento de la dirección IP del cliente que inició la sesión. Los datos adicionales deben ser almacenados en el servidor para verificar sesiones, incluso sin una función de inicio de sesión automático. Es mejor utilizar un nonce para el token (o al menos de base que en los datos no secreto ) en lugar del nombre de usuario y contraseña con algoritmo hash, ya que un atacante podría montar un ataque concebible para encontrar la información de autenticación dado el valor hash.

Si nos fijamos en la fuente para el Facebook, Gmail y, probablemente, formularios de ingreso de otros sitios, los usos forma de acción de inicio de sesión HTTPS, que redirige a una página no segura, una vez registrada la.

Answer 6

1 / Cuando el cheque de usuario "acuérdate de mí": almacena un hash de cada información sobre su equipo: IP, navegador, sistema operativo, idioma, etc ... y escribir este hash en sus galletas con su ID 2 / cuando el usuario está de vuelta, a calcular su nuevo hash. Se compara este valor con el valor de la cookie recibida, y el valor en la base de datos (para el ID especificado). si son todos iguales, se puede autenticar al usuario.

¿Está claro?

https no podía hacer nada si usted tiene un ataque XSS (mejor manera de robar la cookie)