Debería usar una API web para permitir un cambio de contraseña en el servidor y activar esa API desde la aplicación. De esa manera, el usuario solo debería poder cambiar su contraseña desde la aplicación y mientras está conectado al servidor. Pero la contraseña del usuario no debe usarse para cifrar directamente la base de datos, sino solo para cifrar una clave (grande y aleatoria). El flujo de trabajo general podría ser:
- el usuario solicita un cambio de contraseña en la aplicación
- la aplicación solicita la contraseña antigua y nueva
- la aplicación confirma la contraseña anterior con el servidor a través de una conexión segura (cifrada con SSL) - opcional
- la aplicación le pide al servidor que cambie la contraseña dando las antiguas y las nuevas a través de una conexión segura
- la aplicación decodifica la clave de la base de datos con la contraseña anterior
- la aplicación codifica la clave de la base de datos con la nueva contraseña y la guarda en un almacenamiento permanente
De esa manera, la experiencia del usuario es correcta porque solo declaró su cambio de contraseña una vez y, después de eso, la aplicación y el servidor siguen sincronizados.
Desafortunadamente, esto es solo un flujo de trabajo general, ya que incluso si es inmune a una falla de conexión temprana (simplemente mantenga la contraseña antigua si el servidor no pudiera cambiarla), el peor caso sería si el servidor pudiera cambiar su contraseña pero perder La conexión antes de reconocerlo a la aplicación. Como de costumbre, el diablo está oculto en los detalles de la falla del peor de los casos y el protocolo real debe garantizar que ambas partes regresen al estado anterior si ocurre un problema antes del final.