Estoy utilizando 2 variables en la cookie (expiración de 7 días) que es id de usuario y hash. Hash es una codificación sha1 del agente de usuario y la identificación del usuario. En este caso, algunos piratas informáticos pueden iniciar sesión con el navegador de cookies robadas. ¿Qué camino debo seguir o qué práctica es mejor para recordarme problemas de seguridad?Práctica recomendada para recordarme característica
Si bien se puede desmenuzar un user_id y secret_key, cualquier persona que intercepta esta cookie puede conectarse a su aplicación. Además de esto, puede hacerlo para que sus cookies para recordarme se vuelvan obsoletos muy rápidamente. A nadie le gusta una galleta pasada.
Puede almacenar la marca de tiempo de la última visita de cada usuario en su base de datos y en la cookie. Cada vez que lee la cookie para iniciar sesión con el usuario, verifica que ambas marcas de tiempo coincidan. Si no lo hacen, niegue al usuario. Si lo hacen, actualice las marcas de tiempo.
Al usar este método, cada vez que su usuario regrese a su sitio, todas las cookies antiguas quedarán obsoletas. Un hacker que ha interceptado una cookie ahora tiene una cookie obsoleta sin valor porque no sabe la marca de tiempo exacta en la cookie actual. Por supuesto, el hacker puede utilizar una cookie fresco todo lo que quiere hasta que el usuario se vuelve a conectar.
//check for cookie
if(isset($_COOKIE['remember_me'])) {
// get hash and time stamp from cookie
$hash = substr($_COOKIE['remember_me'],0,40);
$last_visit = substr($_COOKIE['remember_me'],41);
// query your db with $hash and $last_visit
// if hash and time stamp match up
// log in
// store the current time stamp in a variable to use for both
$time = date("Y-m-d H:i:s");
// update the time stamp in your cookie
$cookie = $pass . "-" . $time;
setcookie('remember_me', $cookie, time()+60*60*24*100, '/');
// update the time_stamp in your database
else {
// remove the remember me cookie
setcookie('remember_me', '', time()-42000, '/')
}
Este método ofrece una pequeña cantidad de la seguridad, y ciertamente debe ser utilizado a lo largo de los métodos secundarios propuestos en otras respuestas . Se debe almacenar una clave hash en la cookie. Recuerda que la cookie no puede ser perfectamente segura, por lo que debe ser necesaria la re-entrada de la contraseña para cualquier acceso adicional a datos altamente sensibles o características de la aplicación.
También recomiendo nombrar su cookie algo además de 'remember_me' para hacerlo un poco más difícil de encontrar. Si bien no agrega mucha seguridad, si hay alguna, nombrar tu cookie 'ht33424' toma el mismo nombre que 'remember_me' o 'hack_me'.
Lo siento pero no creo que me guste esta respuesta, a menos que malinterprete la lógica de esto, esto depende de que el usuario cargue una nueva página antes de que el hacker tenga tiempo de copiar y ejecutar la página de su lado. Al final de una sesión de usuarios genuinos hay una gran ventana para el secuestro, e incluso durante una sesión no debería ser demasiado difícil deslizarse entre las cargas de la página. Esto crearía un comportamiento de página inusual para el usuario genuino. Renombrar nombres de variables de cookies es la seguridad a través de la oscuridad y una pérdida de tiempo. (Continúa) –
... Probablemente sea otra capa que ayudará, pero un hacker determinado no será detectado por ella. Además, no es 100% a prueba de fallas por las razones que mencioné anteriormente. Para acceso sensible y potencialmente dañino a información y funcionalidad delicada, no recomendaría este método como una solución 100% segura, solo una mejora marginal. –
Para un hacker determinado, ningún método es 100% a prueba de fallas. Como dijiste, esto realmente es solo una capa más para intentar acercarnos al 100%. Esto está destinado a ser utilizado junto con otros métodos, muchos de los cuales se proporcionan en otras respuestas. Una clave hash definitivamente debe almacenarse en la cookie, y la re-entrada de contraseña debe ser requerida para acceso adicional a información y características sensibles. – SomewhereThere
Personalmente, creo un hash aleatorio y lo almaceno en una tabla de "recordarme". La tabla también tiene el agente de usuario, la identificación del usuario y la dirección IP. Compruebo ambos cada vez que vuelvo a iniciar sesión en el usuario desde la función de recordarme. Y si el usuario cierra la sesión manualmente, simplemente elimino esa fila de la tabla. Luego, si vuelven a iniciar sesión, crea un nuevo hash aleatorio. Realmente no hay forma de combatir a alguien olfateando paquetes con un sistema de recordarme (a menos que use cookies seguras con el conjunto de banderas solo HTTPS). Por lo tanto, use una conexión segura con cookies de solo HTTPS. Si no puede, al menos haga el hash al azar, de modo que si se descubre puede al menos generar un nuevo hash para matar ese inicio de sesión ...
¿Cuide explicar el -1? – ircmaxell
No era yo, pero siempre desconfío de la implementación, ya que asume que variables como el agente de usuario y la ip son constantes cuando a menudo no lo son. No definiría esto como una solución, sino como una solución –
. Pero en ausencia de una cookie HTTPS solamente, ¿hay alguna forma mejor de intentar verificar la fuente? – ircmaxell
Eventualmente puede usar sesiones para almacenar el estado del usuario. Pero mantener una sesión tan larga causa el mismo problema, cuando la identificación de la sesión será robada. Puede unir información de cookies con otra, como el navegador o la dirección IP, pero podría causar un problema cuando el usuario no tenga IP estática.
De todos modos, tener una identificación de sesión es más seguro que simplemente poner la contraseña de usuario Sha1 Endded a las cookies.
Afortunadamente, el OP no habló de contraseña en absoluto :) Pero sí, una ID de sesión podría ser útil aquí. – Piskvor
Las sesiones de larga duración son casi siempre una mala idea. Abren la puerta a ataques específicos de DOS ya que puede consumir una cantidad no despreciable de espacio de almacenamiento ya que PHP no puede GC las sesiones hasta que se alcance el límite de tiempo. Hay algunos casos en los que es necesario, pero en su mayor parte no es una buena idea ... – ircmaxell
HMAC
que suele hacer de esta manera, así que no tengo nada que almacenar en el servidor de bases de datos o similar.
Tiene que generar una cadena aleatoria que se convierta en su "clave secreta" y que tenga que almacenar en el servidor (probablemente en un script config php como una constante) y nunca se lo cuente a nadie. Llamaré a esta clave secreta SECRET_KEY.
A continuación, la cookie tiene que poner dos valores:
USER_ID: El ID de usuario del usuario que obtendrá el inicio de sesión automáticoHASH: Un hash criptográfico seguro de USER_ID y SECRET_KEY. Entonces, por ejemplo, md5(USER_ID . "-" . SECRET_KEY). (Se prefiere algo diferente a md5, como sha1 o sha256).Así que su cookie final podría ser: USER_ID:HASH.
Entonces, cuando usted tiene que comprobar si una cookie es un verdadero recuérdame galleta, usted tiene que hacerlo:
function isCookieGenuine($cookie_value) {
list($value, $hash) = explode(':', $cookie_value, 2);
if (md5($value . "-" . SECRET_KEY) == $hash)
return true;
else
return false;
}
El punto es que sólo se puede generar un hash que pasa esta comprobación porque el hash no solo necesita el USER_ID sino también el SECRET_KEYdesconocido por cualquier persona que no sea el servidor. :)
Como se señaló en los comentarios que usted puede hacer esto mediante el uso de la función hash_hmac en PHP> = 5.1.2: http://us.php.net/manual/en/function.hash-hmac.php
Demasiado malo la eliminación de referencias de matriz aún no funciona en PHP (se implementa solo en troncales). entonces puedes hacer 'list ($ value, $ hash) = explotar (':', $ cookie_value, 2);' Y puede ser mejor para la seguridad si implementa un "secreto" diferente para cada usuario (desde entonces, un compromiso único de un secreto no abre la puerta para cada usuario). Ah, y PHP tiene una función incorporada ['hash_hmac'] (http://us.php.net/manual/en/function.hash-hmac.php) para hacer esto mismo ... – ircmaxell
@ircmaxell, + 1 para su comentario (estoy empezando a olvidar estas cosas ... ya no estoy escribiendo php :)). Estoy integrando tus consejos. En cambio, no estoy de acuerdo con la idea de crear secretos diferentes para cada usuario. Si bien es obvio que es más seguro, la ventaja es mínima en mi opinión en este caso. –
Puede establecer simplemente la fecha de caducidad como ahora más un año en la cookie, pero luego debe tener un campo para ingresar la contraseña en todas las áreas sensibles, al igual que la implementación que usa Amazon. Una cookie secuestrada le otorgará acceso pero para comprar o modificar cualquier cosa personal requiere contraseña para ser reingresado.
El problema con las tablas "recordarme" es que si un pirata informático puede acceder a esta tabla, puede crear e iniciar sesión en tantas cuentas como desee. Puede argumentar que refuerza la seguridad de una función de recordarme, pero debe sopesarse con los riesgos de suavizar las áreas de seguridad de la rodilla.
Relacionados: http://stackoverflow.com/search?q=php+session+hijacking –
Debe volver a utilizar un marco de autenticación existente siempre que sea posible, porque, en realidad, es complejo. Por ejemplo, eche un vistazo a https://github.com/delight-im/PHP-Auth – caw