Riesgos de usar GET param para Auth

1

Actualmente estoy desarrollando una pequeña aplicación web. Dado que el nombre de usuario / contraseña sería una sobrecarga, estoy pensando en un parámetro GET para la autorización y autenticación.

Ejemplo: funnydomain.rocks/lol?secret=some_random_hash

Para estar seguro, no estoy preguntando si esto es seguro, ya que no lo es. Estoy pidiendo el riesgo de usarlo. ¿Qué tan grande es la posibilidad de que alguien más use esto para "iniciar sesión"? Estoy de acuerdo en recuperar mi base de datos una vez al año y cambiar el hash para cada usuario. Mucho menos esfuerzo que usar un nombre de usuario / contraseña, especialmente con mi tipo de usuarios ...

Suposiciones:

  • cantidad limitada de usuarios (no más de diez)
  • cada usuario recibe su propio hash
  • se utiliza SSL
  • La URL y el secreto se marcarán en varios navegadores (y se guardarán en algunos servicios en la nube)
  • d̶a̶t̶a̶ ̶i̶s̶ ̶n̶o̶t̶ ̶w̶o̶r̶t̶h̶ ̶p̶r̶o̶t̶e̶c̶t̶i̶n̶g̶ los datos no son críticos
pregunta 0lli.rocks 01.03.2017 - 12:09
fuente

1 respuesta

3

Si está utilizando HTTPS / SSL y confía en sus puntos finales, esto es bastante seguro para sus propósitos, ya que el parámetro de obtención se cifrará como parte de la cadena de consulta, por lo que la captura de tráfico no es un problema.

Lo más probable es que los hashes "secretos" terminen en los registros del servidor web del servidor web en el que se encuentran los servidores de su aplicación web, pero si controla estos registros, entonces para su nivel de seguridad deseado probablemente no sea un problema.

Obviamente, también tendrá que confiar en todos los servicios que almacenan estas URL (marcadores de navegador, servicios en la nube, etc., pero le parece que está de acuerdo). Pensaría que el mayor riesgo estaba aquí (por ejemplo, uno de sus usuarios inicia sesión usando una computadora pública, y el siguiente usuario de esa computadora pública mira el historial del navegador, hace clic en el enlace y tiene acceso a sus datos protegidos).

Si estás usando HTTP no cifrado, tus hash secretos también terminarán en los registros del servidor proxy y, básicamente, cualquier persona que pueda escuchar tu conexión tendrá muchas oportunidades de capturar los secretos.

Sin embargo , solo haría la autenticación directa de GET param si realmente no me importaba mucho el secreto y la integridad de los datos que los hashes secretos deben proteger (básicamente, si quisiera mantener a raya a las hordas de vándalos estúpidos, pero no creía que una persona determinada pudiera estar lo suficientemente interesada en mis datos para intentar acceder a ella, y no tenía ningún problema si resultó que estaba equivocada).

Una forma muy sencilla de mejorar considerablemente la seguridad de su esquema de autenticación sería hacer que los tokens secretos expiren, o incluso mejor, tratarlos como contraseñas de un solo uso. Entregue a cada usuario una lista de tokens, que se utilizarán uno tras otro. Esto no requiere mucho código en el lado del servidor y resuelve el problema de que uno de sus usuarios accidentalmente deje / publique su token secreto en algún lugar.

    
respondido por el Pascal 01.03.2017 - 12:37
fuente

Lea otras preguntas en las etiquetas