Supongamos que está generando el token con suficiente entropía y no usa el valor predeterminado rand() . Supongamos también que ejecuta PHP 5.5.0 o superior, que admite bcrypt (), y luego felicitaciones allí.

Para mí no está claro de qué se supone que debe hacer el SHA1, o contra lo que debe protegerse. No proporcionará seguridad o confidencialmente porque cualquier persona podría enviar el token con SHA1. Hasta cierto punto, valida integridad , pero ¿para qué? Almacenar el token en la base de datos sin ningún tipo de ofuscación hace exactamente lo mismo.

Si sus tokens son válidos por un período de tiempo más largo, digamos más de unas pocas horas, sugeriría:

• Use tokens de actualización, para que pueda revocar tokens de los clientes mucho más rápido.
• Firme los tokens al crearlos y valide la firma en cada solicitud. Esto confirmará integridad y autenticidad.

Como último consejo, nunca asumas que SSL / TLS es el Santo Grial, pero usa la defensa en profundidad.

  

• Usar HTTPS en todo
  

Hasta ahora todo bien.

  

• Cifre las contraseñas usando la función password_hash () de PHP.
  

¿Realmente necesita que su usuario realice un seguimiento de ¿otro usuario / contraseña ? ¿No puede utilizar su licencia de conducir de Internet ?

Dicho esto, asumiendo que no puedes o no, asegúrate de usar una buena sal y una versión de php que use bcrypt (creo que es la versión predeterminada desde 5.0).

  

• Genere un nuevo token y elimine el anterior en cada inicio de sesión nuevo.
  
• Usuario de inicio de sesión mediante una cookie, que almacena el token de usuarios
  
• Verifique la cookie en cada carga de página contra una versión hash SHA1 del token almacenado en la cookie.
  
• Si el token se elimina de la base de datos, el usuario se desconecta.
  

Supongo que tienes un tiempo de caducidad para los tokens y que son eliminados por un backend. ¿Qué sucede si el usuario está conectado actualmente y el backend detecta que el token ha caducado?

Hay varias otras cosas a considerar.

CSRF

Tenga cuidado con CSRF en sus formularios de inicio y cierre de sesión. No quiere que sus usuarios cierren sesión automáticamente por terceros.

En realidad, tenga cuidado con CSRF en todo el sitio.

Bruteforcing

Implemente las medidas de fuerza bruta en su formulario de inicio de sesión y en cualquier backend que se comunique a:

• Demora creciente por intentos fallidos de inicio de sesión
• captchas obligatorios después de un umbral de intentos
• Prohibición temporal por dirección IP después de un umbral de intentos

Supervise cada una de estas medidas, asegúrese de que no causen problemas a sus usuarios.

Mecanismos de recuperación de contraseña

¿Cómo recuperarán los usuarios las contraseñas olvidadas?

Asegúrese de que su mecanismo sea seguro y no filtre información personal de sus usuarios.

Fuga de información

Asegúrese de no filtrar información en intentos de inicio de sesión fallidos. Un mensaje de error como este:

  

Usuario no válido

Proporciona información valiosa a los atacantes (pueden saber si existe un nombre de usuario o no).

No es suficiente tener un mensaje de error genérico. Esto es mucho más matizado de lo que parece al principio: si tarda 2 segundos en responder por contraseñas incorrectas pero solo 100 milisegundos por nombres de usuario incorrectos, está filtrando información.

Consulte CVE 2006-5229 para ver un buen ejemplo de este último ataque.

Facilidad de uso

  

La seguridad a expensas de la usabilidad viene a expensas de la seguridad

Use los nombres de campo estándar para el nombre de usuario / contraseña para que sus usuarios puedan usar cómodamente un administrador de contraseñas si así lo desean.

OWASP

Para obtener más información, lea la documentos OWASP sobre autenticación .

OWASP es una necesidad para todos los desarrolladores web.