Cita:
Iniciado por david_M_G 
Pero puede conseguir el SID (el identificador que sirve de referente) y con él ya no necesita saber ni usuario ni contraseña. Creo
Cierto, pero solamente mientras dure la sesión (que por seguridad normalmente se cierra después de 10-20 minutos de inactividad)
Cita:
Iniciado por david_M_G Si consigue usuario y contraseña obteniéndolas de las cookies del usuario (ambos datos codificados) no puede acceder a la cuenta a no ser que los crackee para descifrarlos.
Falso. Si consigue acceso a la cookie, puede enviar exactamente lo mismo que envía el usuario mediante cabeceras HTTP, ¡no necesita decodificar nada!
La utilidad de "robar" el identificador de sesión es limitada. Aún si el usuario deja la ventana del navegador abierta y se va, un atacante solamente tiene un cierto tiempo para intentar hacerse con la sesión (siguiendo con la idea de arriba de que la sesión se debe cerrar por inactividad).
Robar una cookie con datos que no expiran (como usuario y contraseña) es mucho más útil: puedo robarla y usarla semanas después.
Han habido en el pasado muchos fallos de los navegadores, o malas prácticas de programación, que han permitido robar cookies de forma remota. Y ni siquiera voy a mencionar que robarlas teniendo acceso físico a la computadora es trivial.
De todas formas siguen existiendo problemas a considerar, como el almacenamiento de los archivos de sesión, la posible transmisión del SID a otro sitio mediante enlaces referidos, u otros problemas de los que probablemente no tenga conocimiento.
Pienso que lo ideal sería hacer una segunda identificación del usuario, por ejemplo que una sesión (o cookie, tu decidirás qué vas a usar al final) esté asociada con una sola dirección IP.
Saludos.
Edito: estuve buscando información sobre este tema. Wikipedia tiene una especie de "resumen" de los problemas de seguridad de las sesiones y las cookies.
http://en.wikipedia.org/wiki/Session_fixation http://en.wikipedia.org/wiki/Session_hijacking http://en.wikipedia.org/wiki/Session_poisoning http://en.wikipedia.org/wiki/HTTP_cookie
Me retracto de lo que escribí antes ("el usuario no tiene forma de falsearlo"). También me retracto (internamente, ya que nunca lo dije
) de la idea de que el servidor genera un SID con los datos del cliente y por tanto debía ser único: tenía esa idea en la cabeza pero está lejos de ser verdad.
Me queda claro (no es que me haya dado cuenta ahora...) que todos los sistemas tienen sus problemas. Seguramente las sesiones mal usadas son menos seguras que las cookies
bien usadas.
Tengo que admitir que el concepto de autenticación con cookies sin sesiones no es inherentemente más inseguro que si se usan sesiones. después de todo, si el SID es lo único que valida al usuario, da lo mismo si se manda un SID o un par usuario/contraseña (si están cifrados de una forma que no sea sencilla de averiguar, claro está). Pero para eso se deben usar otros controles, sobretodo de validez de la sesión. Estamos de acuerdo en que una sesión controlada solamente por un SID es insegura, pero también es insegura una sesión controlada únicamente por usuario/contraseña.
Se usen sesiones o no, se debe enviar de alguna forma algo que identifique al usuario.
La ventaja de usar sesiones es que los controles están del lado del servidor, y no se necesita más que el SID para mantenerlas. Si los controles están en el servidor, no se pueden engañar (asumiendo que estén bien hechos)
Si se confía únicamente en cookies, habrá que enviar también algo que compruebe su validez. Si esto se manda en la cookie misma, puede falsearse de alguna forma. Si no se manda en la cookie (se almacena en el servidor) lo que se está haciendo es generar un sistema de sesiones paralelo al de PHP, lo cual es "malo": se estaría reimplementando un sistema de sesiones en vez de usar el que contiene PHP.
Sigo manteniendo, sin embargo, que un SID expira más pronto que una cookie y que un SID será inválido antes de que lo sea un par usuario/contraseña, por muy cifrados que estén.
De todas formas, "un sistema de autenticación con cookies sin sesiones" y "el sistema de autenticación usado en el primer mensaje de este tema" son cosas diferentes, muy diferentes.
El sistema creado en el primer mensaje no tiene ni siquiera un poco de seguridad. No hay protección contra inyección SQL, no hay cifrado de ninguna clase, no hay control de validez de la cookie (ni siquiera se le da un tiempo de validez "seguro").
Disculpen lo largo de la "edición", y lo terco que estaba siendo
Saludos.
