Aunque la entropía en un token aleatorio grande sugiere que el token sería un mecanismo seguro de autenticación, existen muchos problemas asociados con él:

• El token es fijo por usuario, por lo que un usuario no puede cambiarlo si sospecha que está comprometido.
• El token se podría usar un número ilimitado de veces, lo que aumenta la oportunidad de compromiso.
• Según su descripción, el cliente puede conocer los tokens para sus empleados. Si bien los datos pueden ser los mismos (o tener las mismas restricciones de acceso) para cada cuenta que administra el cliente, esto compromete el no repudio . El cliente podría usar una cuenta de empleado y nadie sería más sabio.

Hay un problema de proceso

Como ha señalado, hacer que los clientes llamen al servicio de atención al cliente para cambiar una contraseña tiene dos problemas importantes:

• Primero, es ineficiente para su empresa y le está costando dinero a su empresa y a sus clientes.
• Segundo, es peligroso desde una perspectiva de seguridad.

Considere cómo permitir que el servicio al cliente para restablecer las contraseñas afecta la seguridad de la aplicación:

• Cualquier representante de servicio al cliente puede restablecer la contraseña (y en función de cómo la describa, en realidad configuró la contraseña) de cualquier cuenta de cliente, y por lo tanto puede acceder a la información confidencial de la cuenta de ese cliente.
• Dependiendo de los procedimientos para restablecer la contraseña iniciada por teléfono, el proceso podría ser susceptible de ingeniería social.

Use el token aleatorio para iniciar un restablecimiento de contraseña

Los clientes que necesiten cambiar su contraseña deben usar la aplicación web existente para solicitar un restablecimiento de la contraseña. Esto podría solicitar un correo electrónico en el que la cuenta esté registrada y, opcionalmente, un conjunto de preguntas de seguridad (según su propia evaluación de riesgos). A continuación, se envía un enlace de restablecimiento de contraseña con un token aleatorio a esa dirección de correo electrónico. Este enlace solo debe ser válido una vez y debe caducar después de un breve período de tiempo si no se utiliza. Cuando el usuario hace clic en el enlace, se autentican. La mayoría de las aplicaciones web harán que el usuario establezca una contraseña en este punto. En su caso, es posible que desee permitir al usuario omitir la configuración de una contraseña, ya que la olvidarán de todos modos.

Los clientes que llaman al servicio al cliente para restablecer su contraseña deben recibir instrucciones para utilizar la función de restablecimiento de contraseña. El representante del servicio al cliente puede permanecer en la línea y guiar al cliente a través del procedimiento, pero el punto clave Es que el cliente hace el reset ellos mismos. Una vez que un cliente restablece una contraseña, es menos probable que vuelvan a llamar.

Esto es casi equivalente a pasar la contraseña como un parámetro GET, que es malo. Se trata aquí: ¿Hay alguna diferencia entre GET y POST para la seguridad de la aplicación web?

Además, en su URL de ejemplo no está utilizando HTTPS. El envío de su contraseña en texto sin formato a través de la red también es malo por razones obvias.

A continuación, ¿puede un usuario cambiar su token en caso de que esté comprometido? ¿Estás seguro de que no perderán esta ficha? Quiero decir, también podrían simplemente escribir su contraseña.

Como alternativa, puede utilizar la autenticación básica a través de HTTPS. Esta es una técnica de autenticación estándar y se puede escribir en forma de una URL como enlace . Dudo que se guarde como un marcador, pero la mayoría de los navegadores deberían ofrecer una función de "recordar estas credenciales".

Su esquema propuesto corresponde básicamente al problema de seguridad de la aplicación web más peligroso de OWASP: autenticación y sesión rotas gestión . El sitio de OWAPS explica el problema bastante bien:

  

La aplicación de reservas de la aerolínea admite la reescritura de URL, colocando los ID de sesión en la URL:    enlace

     

Un usuario autenticado del sitio desea informar a sus amigos sobre la venta. Él envía por correo electrónico el enlace anterior sin saber que también está regalando su ID de sesión. Cuando sus amigos usen el enlace, usarán su sesión y su tarjeta de crédito.

También considere que cada URL escrita por un usuario puede enviarse a su navegador y / o motor de búsqueda preferido (consulte política de privacidad de Google Chrome ).

Esta es una expansión en la respuesta de amccormack .

Permita que el cliente inicie un inicio de sesión ingresando su dirección de correo electrónico. Cuando hayan ingresado la dirección de correo electrónico, utilícela para validar que el usuario tiene permiso para iniciar sesión, luego envíe un token de corta duración a la dirección de correo electrónico del usuario. Esto podría estar en la forma de un enlace web con nonces adecuados, o una clave que el usuario necesita copiar en un campo en el siguiente formulario (inicio de sesión de estilo de asistente). Valide que el token ingresado coincida con el enviado para esa dirección de correo electrónico y que todavía sea válido. Asegúrese de permitir algunas horas de validez inicial en caso de listas grises, pero también de un solo uso para que no se pueda reutilizar un token.

En este caso, el usuario no tendrá que recordar nada especial para su servicio (solo se necesita su dirección de correo electrónico y el acceso a esa cuenta de correo electrónico), y el esquema probablemente no sea menos seguro que cualquier otro restablecimiento puro -el esquema de contraseña por correo electrónico que puede encontrar.

Además, en el futuro, puede extender esto permitiendo la entrega de token a través de SMS (o cualquier otro canal de entrega que pueda imaginar), con cambios mínimos en todo menos en el código de entrega de token.