¿Las cuentas registradas permanentemente son inseguras?

Una cookie de identificación buena (larga, fuerte y aleatoria) es mucho más difícil de adivinar que una contraseña típica. Eso es lo suficientemente seguro.

El truco aquí es usar la autenticación "multifactor".

La cookie, más la dirección IP, más cualquier otra información en el encabezado HTTP proporciona alguna "continuidad" del usuario. El idioma de aceptación y el agente de usuario, por ejemplo, no cambian mucho si utiliza el mismo equipo desde la misma ubicación todo el tiempo.

Un poco de JavaScript puede devolver la información window.screen , que, de manera similar, no debería cambiar muy a menudo.

Sí, se puede falsificar. Pero la mayoría de las veces, una cookie robada también termina en una dirección IP inesperada con un valor de encabezado HTTP inesperado en la solicitud.

Cualquier duda sobre los otros encabezados significa que la cookie es dudosa y se debe proporcionar un desafío.

El truco es también hacer que el "eventual" vaya más allá de la vida útil prevista del Universo. Eso es bastante fácil debido a las exponenciales: solo use una cookie lo suficientemente larga. Cada bit agregado duplica el número de valores de cookie posibles.

Por ejemplo, suponga que obtiene 16 mil millones de usuarios (es decir, cada ser humano, incluidos los bebés, crea dos o tres cuentas). Eso es aproximadamente 2 ³⁴ cuentas. Use cookies de 160 bits (20 bytes, nada de qué preocuparse por una cookie). Eso es 2 ¹⁶⁰ posibles valores de cookie, por lo que solo un valor de cookie cada vez 2 ¹²⁶ está vinculado a una cuenta existente. Ahora, nuestro atacante está realmente motivado y probará valores de mil millones por segundo (eso es realmente grande porque "probar un valor de cookie" significa conectarse a su servidor, por lo que asumimos que su servidor es lo suficientemente inteligente) para manejar mil millones de conexiones por segundo (es de suponer que podría permitirse eso, si toda la Humanidad es su cliente). Un billón es aproximadamente 2 ³⁰ , por lo que, en promedio, el atacante deberá intentarlo durante unos 2 ⁹⁶ segundos antes de alcanzar un valor de cookie válido. "2 ⁹⁶ segundos" es una cantidad de tiempo también conocida como "alrededor de 2500 billones de billones de años": ese atacante es seguramente paciente y dedicado.

Entonces, esto no es un problema en la práctica: unos cuantos bytes más y los atacantes se ven frustrados por números absolutos. No hay necesidad de implementar funciones de bloqueo (especialmente porque las funciones de bloqueo a veces pueden ser contraproducentes al atacar a clientes honestos con cualquier tipo de error en el navegador del cual no estaba al tanto, o algo malo como eso). Por supuesto, esto supone que los valores de las cookies se generan con un generador de números aleatorios suficientemente fuerte; piense CryptGenRandom () en Windows, /dev/urandom en Linux / * BSD / Solaris, java.security.SecureRandom con Java.

(El bit sobre la vida del Universo es verdadero solo si la hipótesis Big Crunch es válida y no hay Dios [porque la eternidad es un poco larga también]).

Lo más importante es asegurar la conexión con TLS / SSL. Sin él, es vulnerable a ataques como FireSheep, como se documenta en ¿Puede proteger una aplicación web de FireSheep sin usar SSL? .

En ese momento entran en juego otros grandes riesgos, como alguien que compromete la máquina que está conectada o que obtiene acceso físico a ella.

Regrese a la pregunta sobre la cantidad de entropía en la cookie, ya que otros han señalado que no es difícil obtener una cookie lo suficientemente larga y lo suficientemente aleatoria. Consulte también ¿Cuánto tiempo debe durar una excepción aleatoria? - Seguridad de TI - Intercambio de pila

Otro problema que aún no se planteó, y esto tiene que ver más con la pregunta titulada (cuentas registradas permanentemente), y menos con la cookie de sesión:

Las cuentas registradas permanentemente le brindan al atacante potencial una ventana de ataque mucho mayor.
Si el atacante se las arregla de de alguna manera para robar su cookie (por ejemplo FireSheep, acceso a su máquina, etc.), será válido indefinidamente y, por lo tanto, es más probable que una cookie robada se utilice incorrectamente.
Además, si alguien obtiene acceso a la máquina de su cliente en algún momento en el futuro, por ejemplo, computadoras de escritorio compartidas, computadora portátil prestada (o robada), cibercafé: todavía estás conectado.

Dicho esto, esto es un compromiso, que a menudo tendrá sentido para los usuarios, dependiendo del contexto de la aplicación. Por ejemplo, quiero permanecer conectado a mi gmail (y sitios de SE), pero no a mi banco.
Por otro lado, proteger su cookie de ser robada en primer lugar (SSL, no iniciar sesión en una máquina pública, cerrar sesión cuando haya terminado, etc.) es siempre una buena idea . p>     

Hay algunas razones por las que no debes preocuparte demasiado por este tipo de ataque como se describe a continuación:

• Tamaño : con un tamaño suficientemente grande, que se supone que forma parte del valor de la cookie, será prohibitivamente costoso (en cuanto a hardware y tiempo) generar un valor coincidente con una cookie actualmente válida. También estoy asumiendo que todas las variables adicionales incluidas en el proceso de generación de cookies son conocidas por el atacante, simplemente por ser amables.
• Limitaciones de punto final : es probable que el servidor que administra las conexiones de red en su extremo sea un cuello de botella increíble cuando considere la cantidad de conexiones de red necesarias para obtener un rendimiento razonable de conjeturas por segundo (considere el rango de valores de cookie potenciales!).
• Ancho de banda de la red : incluso suponiendo que tenga acceso a una máquina monstruosa del infierno de un servidor, el atacante estará limitado por el ancho de banda disponible para llevar a cabo el ataque.

Suponiendo que el objetivo del atacante es hacerse pasar por un usuario, diría que es mucho más probable que intente robar cookies de usuarios confiados.

Sí, no te preocupas por nada.

En primer lugar, debes usar una tecla lo suficientemente grande para que no se pueda adivinar probando todas las combinaciones. Por ejemplo, si SHA1 cifra su nombre de inicio de sesión, contraseña y alguna otra información, llevará más tiempo la edad del universo para adivinar una combinación correcta, incluso si fuera posible intentar mil millones de combinaciones por segundo.

Por supuesto, es más riesgoso, pero la seguridad se trata de sopesar el riesgo frente a la recompensa (en el caso, usabilidad).

Es mucho más probable que cometa algún otro error básico, como no forzar el uso de HTTPS en todas partes, que tener un problema con la cookie.