PHP Login System

Question

Estoy creando un sistema de inicio de sesión para una aplicación web usando PHP. Mi pregunta es, ¿es seguro almacenar solo la información de inicio de sesión del usuario en la sesión actual? Por ejemplo, si un usuario llamado John inicia sesión exitosamente en mi sitio, ¿puedo simplemente almacenar $ _SESSION ['Username'] = 'John' y $ _SESSION ['LoggedIn'] = 1 y luego verificar que $ _SESSION ['LoggedIn'] es igual a 1 en cada página para verificar que el usuario está realmente conectado? ¿O hay una mejor manera de hacer esto? No estoy al tanto de ningún problema que esto pueda causar en la cabeza, pero quería asegurarme de no dejar un gran agujero en mi sitio que pudiera causar problemas en el futuro.

Además, estoy almacenando un hash md5 de la contraseña + contraseña del usuario en la base de datos, no su contraseña de cadena real, por lo que es una cosa menos de la que preocuparse.

Deseo saber si necesita más información o si no está claro. ¡Gracias!

Answer 1

Ese es un enfoque perfectamente razonable. Sus visitantes nunca podrán editar los datos de la sesión en su servidor (a menos que el servidor en sí sea inseguro, en cuyo caso cualquier cosa es juego limpio), por lo que un valor LoggedIn = 1 en la sesión es perfectamente seguro.

Sin embargo, tenga en cuenta el riesgo de que un visitante secuestre la sesión de otro (robando la clave de sesión). Una forma de ayudar a protegerse contra esto es almacenar también la dirección IP del visitante (desde $_SERVER['REMOTE_ADDR']) en la sesión y luego en las solicitudes posteriores confirmar que no ha cambiado.

Answer 2

Suena bien; Es posible que desee pensar en establecer un tiempo de caducidad (por lo tanto, si alguien se va y deja el navegador abierto, tampoco están en mucho peligro).

Answer 3

Considere SHA1 o un hash aún más fuerte en lugar de MD5. Sin embargo, estás salando, eso está bien.

Volver a su pregunta: sí, está bien. Sin embargo, implemente medidas para asegurarse de que las sesiones no sean secuestradas. Wikipedia actually has a fairly good article on it.

En la mayoría de los sistemas que he escrito, he incluido la lógica para verificar que la dirección IP remota no haya cambiado. También puede almacenar eso en la sesión, ya que los valores de sesión no se pasan al usuario (solo la ID de la sesión). Si realmente desea ser creativo, puede agregar otros controles: user-agent y lo que no.

También tiene que dar cuenta de los ataques a la sesión. Ver referencias. Si tiene una operación desastrosa, llamémosla POST a DeleteMyAccount, puedo escribir un envío de formulario más javascript para presionar DeleteMyAccount en una publicación del foro en un sitio no relacionado, y espero que esa sesión esté presente en la información del usuario.

Answer 4

Hay una serie de riesgos a tener en cuenta: el secuestro

1. Sesión: aquí es donde alguien roba la cookie del usuario y se hace pasar por ellos. Algunos sugerirán el filtrado de IP para contrarrestar esto, pero eso puede tener efectos secundarios incómodos. La gente usa sitios web desde dispositivos móviles o en computadoras portátiles que se usan en el trabajo, en el hogar y en puntos de acceso wifi, y hay otros casos en los que las direcciones IP pueden cambiar. Así que mi consejo es solo hacer esto para altamente sitios web sensibles (por ejemplo, banca en línea);
2. Su sitio está comprometido: en este caso, el usuario tendrá acceso a su base de datos de todos modos por lo que no hay riesgo adicional al almacenar la información de autenticación en la sesión.Pueden cambiar fácilmente lo que son al emitir instrucciones de ACTUALIZACIÓN a su base de datos;
3. Un sitio cohosted se compromete: si utiliza el alojamiento compartido, un sitio completamente no relacionado podría ponerlo en riesgo (con o sin este esquema) porque varios sitios se ejecutan en la misma instancia de Apache y pueden así acceden a los archivos de los demás (aunque puede ser difícil averiguar a qué sitio pertenecen). Entonces, si un sitio del que nunca has oído ha sido pirateado puede afectar tu sitio;
4. Un sitio cohospitado es Malicioso: similar a (3) excepto que la amenaza es interna pero es similar.

Así que yo diría que está bien (sujeto a (2)) pero solo tenga en cuenta los riesgos. Siga, como mínimo, estas mejores prácticas:

1. Nunca almacene contraseñas no cifradas;
2. Utilice un fuerte algoritmo hash (SHA1 preferido o MD5 al menos);
3. Asegúrese de que las cookies de autenticación caduquen en algún momento. Cuánto tiempo depende de su sitio. Podría ser una semana o dos o una o dos horas de inactividad o ambas cosas.

Answer 5

En general, definitivamente está en el camino correcto. Le recomendaría que use identificadores para sus usuarios en la sesión en lugar del nombre de usuario, ya que los ID son una mejor referencia única dentro de su código.

Además, md5 ya no se considera lo suficientemente fuerte para el hash de contraseñas: es demasiado rápido para el hash y no lo quiere en un control que un atacante tendrá que ejecutar una y otra vez (mientras que un atacante solo necesita hacerlo una vez). Me gustaría poder encontrar la referencia, pero la sabiduría de vanguardia es hacer muchas rondas de un algoritmo hashing de vanguardia, como sha512.

Answer 6

Puede usar COOKIE en lugar de la variable SESSION. puede establecer COOKIE siguiendo

setcookie ('ID', $ variable, time() + 8 * 60 * 60);

Debe tener en cuenta la inyección de SQL. Cuando inserte o actualice su base de datos donde se relaciona el cuadro de texto del usuario, tenga en cuenta la inyección de SQL. Inserta/actualiza tus valores por la función htmlentities().