por - ¿Manera correcta de administrar sesiones en PHP?
session php (4)
Debo agregar a esto. Si está haciendo el método "MD5 la contraseña, luego verifique la base de datos", esto sugiere que la contraseña se almacena en un solo hash md5. Esta ya no es una forma estándar de almacenar contraseñas hash.
Encontré este enlace muy informativo: http://www.itnewb.com/tutorial/Encrypting-Passwords-with-PHP-for-Storage-Using-the-RSA-PBKDF2-Standard
Actualmente estoy configurando un sistema de autenticación. Mi diseño actual es obtener su correo electrónico de $_POST , md5 su contraseña, y verificar la base de datos en contra de su correo electrónico y su contraseña. Si coincide, utilizo session_start , y empiezo a almacenar datos en la variable $_SESSION , así:
$_SESSION[''uid''] = $uid;
$_SESSION[''first_name''] = $first_name;
Y en cada página del sitio web, realizaría una simple verificación de
isset($_SESSION[''uid'']);
de lo contrario, redirija a la página de índice, si es así, cargue la página.
¿Estoy haciendo esto correctamente? ¿Esto es lo suficientemente seguro? ¿Qué tan fácil es para alguien forjar esa información?
Alguien me dijo que debería crear una tabla, con el correo electrónico del usuario y su ID de sesión y usar eso para administrar las cosas ... Me he confundido bastante, ¿cómo podría ayudar esto?
¿Alguien podría aclarar esto? ¿Cuál es la forma correcta de administrar la autenticación con sesiones de PHP?
Gracias.
No estoy al 100% en esto, pero creo que es posible forjar la sesión si alguien realmente quisiera.
Creo que guardar la ID de sesión en una tabla es la forma más segura de hacerlo.
He investigado esto un poco recientemente pero nuevamente no estoy seguro, interesado en saber cuál es la mejor práctica.
Aquí hay algunos recursos para mirar
No hay nada de malo en hacer esto
isset($_SESSION[''uid'']);
Los datos de la sesión no se transmiten al usuario, se almacenan en el servidor (o donde el manejador de sesión lo almacena). Lo que se transmite al usuario es la identificación de la sesión, que es solo una cadena aleatoria generada por PHP, esto puede ser robado, por supuesto, porque se envía al usuario.
Debería observarse claramente que almacenar aleatoriamente una cadena en la base de datos y la sesión de los usuarios y luego usar eso para identificar al usuario no hace que la sesión sea más segura, si el atacante obtiene la sesión todavía van a comprometer al usuario.
Lo que estamos discutiendo ahora es el secuestro de la sesión , es posible que estés pensando que puedes simplemente almacenar la dirección IP en la sesión y verificar que la IP provenga de la solicitud y terminar con ella. Sin embargo, a menudo no es tan simple, me quemé con esto recientemente cuando en una gran aplicación web almacenamos un hash del agente de usuario + dirección IP en la sesión y luego comprobamos que coincidían en cada ocasión, para el 99% de los usuarios esto funcionó bien Sin embargo, comenzamos a recibir llamadas de personas que descubrían que continuamente se desconectaban sin explicación. Pusimos registro en las comprobaciones de secuestro de la sesión para ver qué estaba pasando y descubrimos que estas personas entrarían en una IP y su sesión continuaría en otra, esto no fue un intento de secuestro, sin embargo, tenía que ver con cómo su servidor proxy funcionó, como resultado modificamos nuestro código de secuestro de sesión para determinar la clase de la dirección IP y de allí deducir la porción de red de la dirección IP y almacenar solo esas partes de la dirección IP, esto es un poco menos seguro en ese secuestro de sesión En teoría, podría provenir desde dentro de la misma red, pero causó que todos nuestros falsos positivos desaparezcan.
Actualización de seguridad : a partir del 23-10-2017: el consejo en esta respuesta, aunque de importancia histórica, es completamente inseguro. Nunca se debe usar md5 al hacer hash con una contraseña porque es tan fácil de usar. Consulte esta respuesta sobre cómo usar la contraseña integrada * api para verificar y verificar las contraseñas.
He tratado los sistemas de inicio de sesión / autenticación más temprano, y encuentro varias deficiencias en este método:
- usted "md5 su contraseña, y verifique la base de datos" - esto significa que si una persona tiene acceso a la base de datos, ¡puede descubrir quién tiene las mismas contraseñas!
ADDENDUM (19 de septiembre de 2015) * Mira este link . Explica todos los conceptos básicos, los enfoques que puede tomar, por qué debe tomar esos enfoques y también le da código PHP de muestra. Si es demasiado largo para leer, simplemente ve hasta el final, toma el código y prepárate.
MEJOR APROXIMACIÓN : para almacenar md5 de username+password+email+salt de username+password+email+salt en la base de datos, siendo aleatorio y almacenado junto con el registro del usuario.
- Usar el ''uid'' directamente en las variables de sesión puede ser muy arriesgado. Considere esto: mi amigo ha iniciado sesión desde mi navegador, y se va por una fuga. Reviso rápidamente qué cookies están configuradas en su navegador y descifro su ''uid''. ¡Ahora lo tengo!
MEJOR APROXIMACIÓN : para generar un sessionid aleatorio cuando el usuario inicia sesión exitosamente, y almacenar ese ID de sesión en la $_SESSION[] . También necesitará asociar el sessionid con su uid (usando la base de datos o memcached). Las ventajas son:
- Incluso puede vincular un sessionid a una IP particular para que no se pueda abusar del sessionid, incluso si se captura
- Puede invalidar un sessionid anterior si el usuario inicia sesión desde otra ubicación. Entonces, si mi amigo inicia sesión desde su propia computadora, el sessionid en mi computadora deja de ser válido automáticamente.
EDITAR: siempre utilicé las cookies de forma manual para el manejo de mi sesión. Esto me ayuda a integrar los componentes de JavaScript de mis aplicaciones web más fácilmente. Es posible que necesite lo mismo en sus aplicaciones, en el futuro.