Analizar mi esquema de autenticación web personalizado, basado en un token derivado del nombre de usuario y la contraseña

Question

Analizar mi esquema de autenticación web personalizado, basado en un token derivado del nombre de usuario y la contraseña

#1 de Brett Littrell (8 votos)
#2 de paj28 (4 votos)
#3 de LvB (4 votos)
#4 de Cort Ammon (2 votos)

2

Para evitar que el usuario inicie sesión cada vez que caduque su sesión, quiero implementar un sistema de autenticación basado en token.

Mi esquema funciona así:

Envíe el inicio de sesión del usuario (enviar nombre + contraseña) a través de $.ajax() a https URI
Cree un token a través de $token = bin2hex(openssl_random_pseudo_bytes(16));
Guardar $token , userid y la fecha en una base de datos (solo accesible mediante SSL)
Haz eco de $token y userid al cliente
Guarde $token y userid en html localStorage en el cliente
Al hacer un $.ajax() desde el cliente, siempre envíe userid y $token como POST
Serverside, haga coincidir el $token proporcionado y vea si aún es válido (fecha no vencida).
Si está bien, continúe entregando el material solicitado

¿Puedes analizar mi esquema?

Muchas personas aconsejan no implementar procesos de autenticación personalizados, ya que a menudo son vulnerables a los ataques. Esto me hace sospechar que mi enfoque también puede tener fallas. ¿Puedes revelarme estos defectos?

web-application authentication ajax

pregunta Clawish 05.01.2015 - 16:47

fuente

4 respuestas

Lea otras preguntas en las etiquetas web-application authentication ajax

¿Es seguro el siguiente generador de contraseñas? ¿La contraseña del usuario en ubuntu 13.04 está en texto plano?

score 8 · Answer 1

Así que hay algunas razones por las que no quieres hacer esto, aunque no entiendo el código que presentaste, ya que no me ocupo de eso. Debe utilizar una biblioteca de terceros para gestionar sus sesiones. Hay varias razones ...

El código se examina, prueba y mejora en una audiencia mucho más amplia cuando se usa un esquema de autenticación integrado o conocido.
Cuando y si te vas, alguien no se queda atascado al tratar con un mecanismo de autenticación creado a medida
Probablemente haya vulnerabilidades en el código, puede o no estar directamente en su código, pero en un servicio al que llama, la actualización de ese servicio único puede causar problemas en el resto del código, como argumentos y variables en desuso. Esto puede no hacer que su programa sea menos seguro, pero puede romperlo.
¡La autoayuda es difícil, especialmente cuando haces un buen trabajo y se ejecuta sin problemas durante un año o dos, luego bam! en el medio de otro proyecto, algo se rompe y tienes que tomarte el tiempo para solucionarlo desde abajo hacia arriba.
CYA, si cometes un error y sucede algo malo, eres a quien las personas volverán y preguntarán, ¿por qué no usaste este o aquel esquema que no es vulnerable a algún ataque y tendrás que explicarlo? que.

De todos modos, espero que ayude

score 4 · Answer 2

No es un mal comienzo. Algunas cosas a tener en cuenta:

Si falla el inicio de sesión, no revele si el usuario existe
Implementar alguna forma de protección de fuerza bruta
Proporcionar una función de cambio de contraseña; requiere la contraseña anterior
Realizar la comprobación de seguridad de la contraseña
Las sesiones generalmente tienen inactividad y tiempos de espera absolutos
Almacenar contraseñas de forma segura, por ejemplo, bcrypt
Use un token anti-CSRF
Permitir a los usuarios autogestionar sesiones

Y eso es solo autenticación y gestión de sesión. Hay una gran cantidad de otras consideraciones de seguridad: inyección de SQL, secuencias de comandos entre sitios, uso de SSL / TLS, etc.

La mayoría de las bibliotecas de autenticación NO resuelven todos estos problemas en la configuración predeterminada.

score 4 · Answer 3

A primera vista, con un MITM solo puedo acceder a su aplicación web siempre y cuando una de sus usuarios esté usando mi "wifi"

Además, ¿por qué usar algo no comprobado cuando puede usar tecnología probada (OAuth2 sería suficiente para sus propósitos y eso ha sido probado en seguridad)

Y no tiene un control creado para forzar a la fuerza su "token", lo que significa que puedo forzar la fuerza bruta tan pronto como obtenga un "ID de usuario" (probablemente un número tan fácil de adivinar).

Además, este ejemplo carece de protección contra las inyecciones de SQL, lo que significa que podría darle a mysql un token válido e iniciar sesión en la cuenta de cualquier persona.

Resolver todos ellos (sin crear puertas traseras ocultas / etc) es casi imposible para un hombre. Simplemente use una de las bibliotecas disponibles de la comunidad de código abierto, una que está probada y verificada.

score 2 · Answer 4

Si toma el patrón de identificación de sesión estándar y lo implementa usando una cookie persistente en lugar de la cookie de sesión más típica, obtiene exactamente lo que describe, solo que el navegador realiza una implementación profesional. p>

Recuerde: no solo su algoritmo puede tener fallas, sino que su implementación también puede tener fallas. Cuanto más tenga que implementar, mayor será su riesgo. Lawri señaló que usted ahora es responsable de asegurarse de que no haya ataques de inyección SQL en su sistema.

Si realmente quiere hacer esto usted mismo, la forma correcta de verificar el algoritmo es identificar cómo alguien puede usar la información. Como lo ha escrito, la única diferencia entre su token y una contraseña es que el token caduca técnicamente (lado del servidor). En consecuencia, debe escribir su código que trata los tokens con el mismo cuidado y atención que le brindaría al almacenar y transmitir una contraseña.

Como mínimo absoluto, usted debe implementar SSL para protegerse de los ataques de rastreo del estilo Firesheep, como mencionó Lawri. Si no lo hace, entonces probablemente no debería implementar sus propios sistemas de identificación de sesión cuando esto generalmente se reconoce como un "problema resuelto".