Esto depende completamente de lo que esté haciendo con el nombre de usuario almacenado en la cookie. Si confía automáticamente en que el nombre de usuario que proporciona la cookie es válido, entonces está invitando efectivamente a la suplantación de identidad de los usuarios por parte de piratas informáticos.

Si, por otro lado, simplemente está almacenando el nombre de usuario para que puedan rellenarlo automáticamente la próxima vez que inicie sesión, está perfectamente bien ya que un nombre de usuario no es información secreta.

Si, por algún motivo, necesita usar una cookie para almacenar la autenticación, el método preferido es usar un identificador de sesión generado aleatoriamente que se rastree en el servidor y pueda caducar.

Si el almacenamiento del lado del servidor no está disponible, el servidor puede cifrar el nombre de usuario y la fecha de caducidad (y opcionalmente una IP desde la cual se conectaron) con una clave simétrica (como AES) y luego pasar ese valor cifrado a la cookie. El servidor puede verificar la cookie más tarde sin que un atacante pueda alterarla. El principal inconveniente de este enfoque es que una vez que se emite una cookie, no se puede invalidar si el usuario desea cerrar sesión en todas sus sesiones (porque, por ejemplo, su computadora fue robada).

Supongo que la pregunta es ¿por qué harías esto?

Si está almacenando el nombre de usuario en una cookie para omitir un paso en el que extraería esa información de la base de datos entonces se está dejando abierto a riesgos si confía ciegamente en que el usuario sea ellos mismos.

Cualquier cosa que esté en forma de cookie es

1. legible por el usuario
2. puede ser manipulado por el usuario

Las variables que el usuario tiene la capacidad de modificar no se deben confiar SIEMPRE si están almacenadas en el navegador (Cookies), enviadas por el usuario a través de un formulario (variable POST o GET), o si se pueden manipular En la barra de direcciones (variables GET).

Si está almacenando cookies (como lo hacen algunos sitios) para recordar a un usuario cuando regresan, entonces debe codificar la variable con una sal y pasar esa variable picada con sal (con algo como una marca de tiempo y algo que le guste) una clave privada todo hash juntos). Esto hace que sea mucho más difícil para el atacante obtener un falso positivo en la manipulación de cookies, ya que necesitarían tener acceso al código y presentar la marca de tiempo exacta para poder coincidir en la base de datos (ver más abajo).

Acerca de las SESIONES

Algunas implementaciones de SESSIONS en lenguajes de programación como PHP serán por defecto almacenan las variables de SESIÓN en las cookies . Por lo tanto, cualquier información que no querría que el usuario viera tampoco debería almacenarse como una variable de sesión sin que se la codifique o codifique de alguna forma o forma, ya que, de forma predeterminada, en algunos idiomas se transmite al navegador y proporciona cualquier posible la información del atacante sobre la forma (denominando convención y estructura) almacena sus variables.

Siempre que espere que se registren solo desde una máquina, una buena práctica sería:

1. Guarde la variable puntual con hash con hash en una tabla relacional en la base de datos junto con una coincidencia específica del usuario (como una identificación) Y una marca de tiempo. Solo debe haber una variable en esta tabla almacenada por usuario. Esto actuará como la última visita al sitio desde este navegador. Las sesiones duran tanto como lo permitan los tiempos de espera de la sesión. Esto existe solo para la última página de su última sesión y puede existir en la página donde ellos terminaron su sesión (digamos que se desconectan). Si elige reactivar su última sesión (siempre que no se desconecte), almacene el session_ID en la tabla relacional junto con esta variable única, ya que cualquiera que esté revisando su tráfico probablemente ya tenga su session_id. Tendrían que saber que esta clave única para el usuario del sitio era lo que se requería para que sea un poco más fácil de regresar.
2. Al recuperar la cookie almacenada, límpiela (elimine las etiquetas, comillas, cualquier cosa que se use como un ataque de inyección), verifíquela para asegurarse de que se ajuste al formato esperado (si está esperando un hash MD5, no No acepte un número, no acepte SHA, etc.)
3. Ejecute una consulta de verificación cruzada en la base de datos que verifique un conteo de 1 para la variable ahora limpiada en comparación con un registro existente en su tabla relacional.
4. SI ha recibido el conteo de 1, ENTONCES realice una consulta limpia en la base de datos para obtener más información sobre el usuario porque ahora el usuario sería * confiable * o al menos la variable estuvo en uso al mismo tiempo en tu sistema Si recibe un conteo de 0, esto significa que no existe y no es confiable. Si recibe un conteo de más de uno, esto significa que no está almacenando correctamente los hash en la base de datos, ya que cada nueva sesión debería tener su propio hash especial.

Si el tiempo es mayor que un período de tiempo más largo (por ejemplo, 1 mes), haga que proporcionen todas las credenciales como no reconocidas. Esta es una decisión ejecutiva en relación con la experiencia del usuario.

Si una sesión ha caducado, haga que el usuario vuelva a autenticarse. Si no ha caducado, el usuario todavía debe estar conectado a menos que tenga un evento en el lugar que mate la sesión de un usuario después de una cantidad determinada de inactividad (lo que significa que la sesión * no debería estar activa).

En el momento en que se reconozca al usuario que no ha iniciado sesión, entonces preséntele un desafío y una respuesta que conozca para verificar que no haya alguien en su terminal. No les proporcione ninguna información que pueda usarse contra su cuenta en caso de que su máquina haya sido comprometida.

NUNCA imprima nada directamente en la pantalla, escríbalo en una base de datos, o escríbalo en un disco de un usuario sin limpiarlo. Incluso los sitios web de intranet de LAN de back-end seguros tienen el potencial de ser explotados.

No almacene información como esta en una cookie. Use la caché de sesión del servidor (es decir, $ _SESSION) para obtener información como esta. Las cookies se pueden falsificar fácilmente y lo último que desea es que un usuario se haga pasar por otra persona simplemente cambiando una cookie.

  

Quiero almacenar el nombre de usuario de un sitio web en la cookie, ¿es seguro?

No. Si almacena información en la computadora de un usuario, donde no tiene control sobre ella, no es segura. Ese usuario o cualquier otra persona con acceso a esa computadora puede cambiar el contenido de esa cookie.

Tenga en cuenta que puede cifrar la información antes de almacenarla en una cookie y que siempre debe validar la entrada del usuario. Incluso si lo validó previamente antes de almacenarlo en la computadora de los usuarios.

Básicamente: nunca confíes en la entrada del usuario.

  

¿Qué puede hacer un hacker con esta información?

Si los datos en la cookie no están cifrados y verificados, el atacante puede probar los llamados ataques xss. P.ej. leyó (lo que espera que sea) el nombre de usuario de la cookie y se lo devolvió al usuario.

Por ejemplo,

  Users computer                   Your server

read username from cookie   ----   
                                   Information accepted at the server


                                   Display a greeting without verifying the contents
"Hello Jane. Welcome back!"  -----

Sin verificación, la devolución podría ser simple:
"Hola" + name_from-cookie +. ¡Bienvenido de nuevo! "

Ahora imagine que alguien cambia la cookie a "Jane. algún comando "

El navegador de los usuarios, que ya está en comunicación con su servidor web de confianza, intentará mostrar esto e intentará mostrar el contenido de algún comando .

Ahora, este es solo un ejemplo en el que puede decir 'pero si alguien pudiera hackear su cookie para hacer eso, también podría haber hecho cosas peores'. Esto es verdad. Pero es solo un defecto que creo que podría explicar fácilmente. Podrían hacer cosas mucho peores.

Obtenga nombres de usuario de los usuarios mediante el uso de otros ataques. Todas las cookies son información almacenada. Cuando se puede realizar el robo de cookies, ya está en problemas, ya que PHP, etc., almacena el ID de sesión en una cookie.

Las cookies son información no confiable, por lo tanto, nunca confíe en los datos ni los elimine.

También cuando haces algo como: Has iniciado sesión como "'. $ SESSION [' username '].' Espero que no tengas usuarios llamados alerta ("xss")