Trabajo para una empresa de alojamiento y estoy a punto de diseñar una API de descanso para un tercero para que puedan crear cuentas de usuario de Active Directory.
También quiero que esta API sea lo suficientemente asíncrona y robusta como para sobrevivir al reciclaje y reinicio del grupo de aplicaciones. Para hacer eso, tengo que guardar estado. Para las nuevas cuentas de usuario, eso incluiría la contraseña inicial, a menos que pueda convencer a la tercera parte de que acepte devoluciones de llamada o sondeo.
Mis opciones de diseño son:
- Async dispara y olvida donde tengo que guardar la contraseña para nuevas cuentas.
- Async con devolución de llamada. Se pueden crear nuevas cuentas con una contraseña aleatoria. La tercera parte se restablece cuando se recibe la devolución de llamada.
- Igual que 2. pero con sondeo.
No puedo usar el hash de contraseña recomendado, porque el objetivo no es usarlo para una autenticación posterior, sino pasarlo a Active Directory.
La api se implementará con el estilo CQRS, por lo tanto, la contraseña no puede formar parte de ningún evento de dominio. Eso sería lo mismo que guardarlo.
Opción 1: almacene contraseñas temporales en una base de datos separada y deje que maneje el cifrado.
Estaré usando el servidor Sql, y pensé que podría dejar que eso maneje el cifrado:
- Guardar las contraseñas en la base de datos cifrada.
- Guarde la identificación en el evento de dominio.
Cuando la cuenta de usuario está a punto de ser creada:
- Lee la contraseña.
- Crea la cuenta.
- Eliminar la contraseña de la base de datos.
Opción 2: almacene contraseñas temporales en una base de datos separada, pero cifre cada entrada con una clave diferente.
La idea es que si la base de datos está comprometida, sería más difícil hacer algo útil con ella porque cada contraseña tiene una clave diferente. ¿Es esto útil, o es una variación de seguridad por oscuridad?
- Crear una clave aleatoria
- Cifrar la contraseña
- Guardar la contraseña cifrada en la base de datos
- Guarda la clave y la identificación en el evento de dominio.
De lo contrario, igual que la Opción 1.
Nota
La base de datos de contraseñas debería estar casi vacía en condiciones normales. Es cuando algo falla en el backend de la API y se acumulan nuevas solicitudes de cuentas de usuarios, las cosas se están poniendo peligrosas. Las contraseñas iniciales permanecerán en la base de datos hasta que se solucionen los problemas.
Los nuevos usuarios deben cambiar la contraseña en el primer inicio de sesión.
¿Recomendaciones?
Probablemente sea obvio que no soy un experto en seguridad. ¿Son estas ideas simplemente estúpidas? ¿Existen métodos aceptables para almacenar contraseñas temporalmente?