Autorización / control de acceso en un entorno de cifrado del lado del cliente

En resumen, necesita un mecanismo de autenticación independiente, es decir, el usuario debe iniciar sesión en su servidor de alguna manera. Su enfoque de identificación aleatoria tiene varios problemas -

• Como usted señaló, estos deben ser almacenados de forma segura por el usuario. También debe estar seguro de que no pueden ser interceptados.
• No tienes idea de lo que pertenece a quién. Si un usuario pierde su conjunto de ID, tiene documentos obsoletos en su servidor pero no tiene idea de qué documentos son esos. Tampoco puede restringir el espacio de almacenamiento de los usuarios, etc.

Supongo que porque ha pedido que no desee que los usuarios tengan que almacenar varias contraseñas. Lo que realmente deja tres enfoques: ambos requieren una identificación de usuario o nombre de usuario para el caso en el que múltiples usuarios eligen la misma contraseña.

1. En el lado del cliente, toma un hash criptográficamente seguro de la contraseña del usuario. Esto se convierte en la contraseña de autenticación de los usuarios (para que almacene un hash del hash en el servidor). Esto es bastante simple de implementar. En teoría, debería ser seguro, pero la reutilización de la frase de contraseña no es recomendable.

2. El usuario genera un par de clave privada / pública a partir de la contraseña de ID de usuario + (mediante el uso de una función de derivación de clave para generar la semilla a un CSPRNG que se utiliza para generar la clave privada). Luego, generará una clave de cifrado simétrica completamente aleatoria, cifrará esto con la clave privada y enviará tanto la clave simétrica cifrada como la clave pública asimétrica a su servidor. La clave privada se puede recuperar con la frase de contraseña. La aplicación obtiene la clave de cifrado al solicitar la versión cifrada del servidor y descifrarla con la clave privada. El usuario se autentica firmando mensajes con la clave privada, y el servidor puede verificarlos con la clave pública.

Puede almacenar una asignación de información de usuario asociada con cada clave en una base de datos y hacer una búsqueda y configurarla en una cookie de sesión cifrada que el cliente puede pasar de un lado a otro. Esto, por supuesto, es una solución horrible, pero se puede implementar. La forma correcta sería tener un mecanismo de inicio de sesión si necesita roles específicos del usuario. Lo que está describiendo es básicamente cómo funciona auth y no debe usarse en instancias como esta. Este tipo de descripción es generalmente para la autenticación de servicio a servicio sin restricciones.