¿Qué hay de malo con mi propio esquema de autenticación?

Sí, esto es inseguro como se especifica.

Su diseño parece ser vulnerable a los ataques de falsificación de solicitudes entre sitios (CSRF, también conocido como XSRF) (es necesario agregar un El token CSRF con todas las acciones POST que se muestran con el formulario y se almacenan en una cookie de sesión). Básicamente, si un usuario ingresa a otro sitio web (correo electrónico, foro, blog) mientras está conectado a su sitio web, su navegador puede verse forzado (mediante javascript, mediante un formulario secreto) a realizar una solicitud POST no intencionada a su sitio web realizando alguna acción que No quiero.

Tu esquema tampoco es particularmente específico.

• ¿Cómo se tratan las contraseñas (bcrypt o PBKDF)? ¿O al menos un hachís salado? ¿Se verifican con un derecho de comparación de cadena de tiempo constante?
• ¿Cómo se protegen los datos a través de la red durante el tránsito (HTTPS?),
• ¿Cómo se insertan / extraen los datos de la base de datos? ¿Declaraciones preparadas (también conocidas como consultas parametrizadas) en todas partes? (¡Genial!) ¿O ejecuta una cadena con un comando SQL que contiene la entrada del usuario (Vulnerable!)?
• ¿Cómo se almacenan los tokens en el navegador (cookies seguras solo de HTTP?)

Posiblemente también podrían haber otras fallas en la implementación.

Lo que presentas no es un protocolo de autenticación; es simplemente un concepto , es decir, el concepto de token de sesión .

En palabras sencillas:

• El servidor autentica al cliente y envía una clave secreta a ese cliente (el token de la sesión).
• Cuando el cliente vuelve, muestra el token al servidor para demostrar que es el mismo cliente que anteriormente.
• El cliente puede solicitar al servidor que olvide el token (por supuesto, y al contrario de lo que se muestra, esa solicitud de "cierre de sesión" también debe incluir el token, de lo contrario, cualquier persona podría cerrar sesión en cualquier otro lugar).

No hay nada de malo en este concepto, siempre y cuando entiendas sus limitaciones. Por ejemplo, se basa inherentemente en que las comunicaciones cliente / servidor son confidenciales (de modo que ningún atacante pasivo escuche el token) y sea resistente a la manipulación (para que ningún atacante activo pueda secuestrar la conexión justo después de la autenticación). En pocas palabras, SSL (es decir, HTTPS) es obligatorio.

Estoy de acuerdo contigo: este esquema parece fácil de construir. Pero cuídate: es una ilusión. De hecho, no es fácil construir un sistema de sesión autenticado seguro, incluso si el concepto es claro y simple. Crear un sistema que funcione es fácil y se puede probar; la seguridad, sin embargo, no se puede probar y es mucho más trabajo de lo que generalmente se supone.

Hay un número extraordinariamente alto de formas en que la realización puede descarrilar. @jimbob te da algunos (y la lista no es exhaustiva en absoluto). El arte de la seguridad informática no consiste en hacer que el sistema funcione correctamente en condiciones normales; se trata más de asegurarse de que los sistemas no funcionen de manera inadecuada en condiciones anormales.

Lo gracioso de proporcionar una 'esencia' genérica de un flujo de autenticación es que a menos que realmente arruines el flujo, es probable que no encuentres problemas serios porque simplemente no hay suficientes detalles decir de una manera u otra. La mayoría de las veces, la implementación es defectuosa.

Esto se complica aún más por el hecho de que no especifica contra qué está protegiendo. Pasar solo un nombre de usuario e iniciar sesión es perfectamente seguro *, en las condiciones adecuadas. La pregunta que debe hacerse es contra quién o contra qué está tratando de protegerse, y si su flujo de autenticación ha proporcionado o no medidas de protección contra lo que esos malos le lanzarán.

Usted menciona contraseñas ... ¿cómo está verificando las contraseñas?

Tokens de sesión ... ¿cómo los genera, cómo los almacena en el servidor, cómo los almacena en el lado del cliente, cómo valida el token en "cualquier acción"?

Más preguntas, etc. ...

Por eso se recomienda que no construyas tu propio. Las probabilidades son bastante buenas, no has pensado en todos los ángulos, mientras que los desarrolladores de un componente conocido podrían tenerlo. Como ejemplo, decir que generar un token de sesión es "solo un detalle de implementación" no es del todo incorrecto, pero es un detalle serio que lo arruinará de verdad si lo desordena.

Entonces, mi respuesta a tu pregunta es: sí, es insegura porque no hay suficientes detalles para decir de una manera u otra.

* Bueno, tal vez no, pero entiendes el punto.