Necesito su sugerencia sobre esto.
Considerar Tenemos una aplicación móvil y una gran cantidad de usuarios. Queremos implementar la funcionalidad de restablecimiento seguro de contraseña con el consentimiento de la experiencia del usuario.
Supuesto: aquí, todos asumimos que el pirata informático ha robado el teléfono de la víctima, por lo que la implementación tradicional de restablecimiento de contraseña no funcionará como:
- Si enviamos OTP para restablecer la contraseña en el teléfono, el pirata informático ya tiene el teléfono de la víctima. Por lo tanto, no sirve.
- Si enviamos el token de restablecimiento de contraseña, el pirata informático tiene un teléfono de la víctima donde, en la mayoría de los casos, la identificación del correo electrónico está vinculada y abierta en el teléfono. Por lo tanto, no sirve.
Implementación actual: si alguien solicita una solicitud de restablecimiento de contraseña, les damos una nueva contraseña después de 24 horas. Mantenemos esta ventana de tiempo para que si el teléfono del usuario es robado y el pirata informático envía una solicitud de restablecimiento de contraseña, el usuario debe informarnos dentro de las 24 horas para que el pirata informático no realice ninguna actividad maliciosa desde su cuenta.
Problema: tenemos que reconstruir esta implementación asumiendo que el teléfono del usuario es robado y el pirata informático nos ha enviado una solicitud para restablecer la contraseña y el usuario no nos ha informado que su teléfono fue robado en 24 horas. ¿Cómo podemos identificar lograr esta tarea sin identificar que el usuario es legítimo o no y que la cuenta del usuario sigue siendo segura?
Un par de soluciones:
- Comenzamos a proporcionar tokens de hardware (token RSA, token VASCO) a nuestros usuarios para que, incluso si el teléfono es robado, para restablecer y usar una nueva contraseña, el pirata informático tendrá que acceder físicamente a estos tokens para iniciar sesión. (Problema: es imposible para nosotros proporcionar 500000 tokens de hardware para nuestros usuarios.
- Números de confianza: mientras se registra, el usuario agrega dos números de confianza que se almacenan en nuestra base de datos. Con la solicitud de restablecimiento de contraseña, proporcionamos la contraseña en dos partes separadas en esos números confiables y el usuario puede acceder a la aplicación combinándolos. (Problema: la experiencia del usuario se vuelve difícil e inaceptable)
- Mientras nos registramos, proporcionamos algunas preguntas de seguridad (no preguntas tradicionales sobre la fecha de nacimiento, el apellido de soltera de la madre, etc.), como seleccionar 1 de cada 4 colores. Seleccione 1 de 5 alimentos, etc. Mientras restablecemos la contraseña, les proporcionamos estas preguntas para responder, ya que el pirata informático no sabrá todo esto. (Problema: si me registro ahora y olvido el PIN después de 1 año, no recordaré estas respuestas, solo el caso en el que recuerdo estas respuestas es si tomé una captura de pantalla de esas respuestas mientras las registro, lo que nuevamente es una preocupación en el teléfono robado )
- Código de copia de seguridad: proporcionamos un código de copia de seguridad a diferencia de Google durante el registro y el usuario tendrá que agregarlos para restablecer la contraseña. (Problema: en la mayoría de los casos, el usuario toma una captura de pantalla de los códigos de respaldo o almacena en la aplicación de notas, lo que nuevamente es una preocupación en el teléfono robado)
Además de estas, necesitamos otras sugerencias a través de las cuales podamos implementar alguna solución sólida y, aun así, la experiencia del usuario intente mantener la fluidez.
Estamos completamente de acuerdo en que la seguridad y la complejidad del usuario son inversamente proposicionales. Si queremos implementar seguridad a prueba de balas, la experiencia del usuario irá mal. Sin embargo, quiero respuestas de la comunidad si hay alguna manera de hacerlo.
Se agradecen las sugerencias.