Almacenar contraseñas generadas por el servidor

El riesgo inherente de las contraseñas es que los usuarios son malos para elegir buenas contraseñas y tienden a reutilizar las contraseñas. En un escenario como este, parece que su contraseña generada por el sistema nunca se envía al usuario. Usted no controla su contraseña en el lado de Facebook. Solo te importa autenticarte con el sistema de Facebook. Sus riesgos son significativamente más bajos, a menos que comparta su contraseña generada por el sistema con el usuario, en cuyo momento todas las apuestas están desactivadas.

Siguiendo las buenas prácticas de seguridad, aún debe codificar las contraseñas (nunca las almacene en texto claro, a menos que existan razones técnicas válidas para que no lo haga, o siempre que tenga otros controles de compensación para proteger esas contraseñas) , y cambiarlos regularmente. Debería tener un mecanismo para generar tokens nuevos con Facebook, así que tal vez programe un proceso para hacerlo automáticamente cada 30 días aproximadamente ...

Una pregunta interesante, aquí es cómo abordaría este problema (tenga en cuenta que todos estos pasos son teóricos).

NEWAPP, como lo describe, no es una forma de un sitio web, sino una aplicación; por lo tanto, asumiré que tiene una ejecución de código en el host del cliente y tiene acceso a la identificación del hardware del dispositivo.

La complejidad y la facilidad de uso dependerán de la seguridad involucrada, y tal diseño puede parecer no muy fácil de usar. La idea básica es usar el ID de hardware (cadena única para cada dispositivo) como semilla para generar un par de claves público + privado, y almacenarlo en el dispositivo cliente. La verificación de la identidad del usuario se realiza mediante la firma de mensajes entre el cliente y el servidor con una clave correcta.

Hay tres escenarios básicos para el uso de este diseño:

1. El usuario crea una cuenta, y su dispositivo genera el par de claves y envía la clave pública al servidor, junto con la identificación inicial del hardware. El servidor genera un nombre de usuario al incluir la clave pública con el ID de hardware como sal. Este nombre de usuario se envía al cliente y se almacena localmente.
2. El usuario agrega un nuevo dispositivo a la lista autorizada y verifica su identidad y propiedad de la cuenta a través de un canal lateral, ya sea correo electrónico, sms, solicitud desde la aplicación. Por ejemplo, el usuario ingresa una dirección de correo electrónico asociada con la cuenta y recibe un correo electrónico con una cadena única generada por el servidor. El usuario copia esta cadena en NEWAPP, que lo identifica, y se inicia un proceso similar a crear una nueva cuenta (la nueva clave pública agrega una nueva clave, sin eliminar la anterior).
3. Un usuario inicia sesión desde un dispositivo autorizado, el servidor y el cliente utilizan PKI para transmitir y firmar varios mensajes aleatorios para verificar la identidad del cliente, y el usuario está autenticado.

De esta manera, el cliente solo podrá iniciar sesión una vez que su dispositivo esté autenticado y no se necesitará una contraseña. Incluso podría permitir una seguridad mejorada y permitir que los clientes usen una frase de contraseña para su par de claves.

Este diseño es vulnerable al robo de identificaciones de hardware o claves por malware, pero esa es una historia completamente diferente.