No puedo usar openid porque mi autenticación no se basa en la identificación del correo electrónico
OpenID no depende del correo electrónico, una identidad de OpenID podría ser algo así como someone.example.com .
Luego inserte (usuario, ip, clave única que creo). en una base de datos.
No es aconsejable vincular sus sesiones a la dirección IP. Las direcciones IP de algunos usuarios variarán legítimamente (por ejemplo, porque están detrás de un clúster proxy o están cambiando entre redes móviles). Ponerlos en marcha al cambio de IP haría que su sitio sea muy difícil de usar para un subconjunto de su audiencia.
La concordancia de IP es, en cualquier caso, de utilidad muy limitada. El ataque habitual que intenta abordar es el de la fuga de token de sesión y la reutilización de un cliente atacante. Pero las posibles causas de la fuga de tokens son generalmente aquellas que le dan al atacante acceso para hacer solicitudes del cliente de todos modos (XSS, malware del lado del cliente, seguridad de transporte defectuosa) o aquellas que ya son catastróficas (compromiso de la base de datos, ejecución del código del servidor). p>
De forma similar, la concordancia Usuario-Agente es de poco valor, ya que la cadena UA no es ningún tipo de secreto y es fácil de falsificar. La concordancia de IP y UA puede valer como una entrada para un sistema de clasificación de riesgo complejo con historial de comportamiento, pero la conciliación primitiva es ineficaz como medida de seguridad y es probable que cause más daños por falsos negativos que beneficios.
Marca de tiempo + ip + agente de usuario + nombre de usuario y cifrándolos muchas rondas = clave única!
Tipo de cifrado = MCRYPT_RIJNDAEL_256
Luego inserte (usuario, ip, clave única que creo). en una base de datos.
configura la clave única en la cookie y la transmite al usuario.
Como la 'clave única' enviada por el cliente se verifica simplemente comparándola con el valor conocido en la base de datos, su contenido real no es relevante y no tiene sentido generarla de una forma tan elaborada.
Una cadena de datos aleatorios haría lo mismo para esto, y luego lo que tendrías sería equivalente funcionalmente a la forma normal en que la gente hace inicios de sesión en PHP: colocando un ID de usuario registrado en la sesión . Reutilizar las sesiones estándar basadas en PHPSESSID aleatorias de PHP tendría ventajas en términos de rendimiento y la naturaleza bien entendida de su configuración.
Hay otro modelo de autenticación algo común, que puede ser lo que pensabas con la idea de "clave única". Aquí es donde crea un token basado en los elementos que desea autenticar (generalmente, ID de usuario, números de generación de contraseña / restablecimiento y tiempo de caducidad del token) junto con una firma criptográfica sobre esos elementos (normalmente HMAC) usando una clave secreta del lado del servidor. El servidor puede reconocer y autenticar el token entrante utilizando esa firma, lo que le da la ventaja de que no necesita ningún almacenamiento de sesión / base de datos persistente. Pero a menos que necesite esa propiedad en particular, me quedaría con las sesiones antiguas.
Creo que usar TLS es obligatorio aquí
Sí. Y recuerde dar a sus cookies la marca secure para que no se filtren a través de una solicitud que no sea TLS.