No sé si tiene mucho sentido cifrar datos con el hash de la contraseña del usuario, especialmente si mantiene el hash en la base de datos. En ese caso, cualquiera que pueda acceder a los datos cifrados también puede acceder al hash de la contraseña y descifrar los datos.
Otro enfoque sería cifrar los datos con la clave específica de la aplicación combinada con algunos datos específicos del usuario. Sin embargo, entonces se enfrenta a otro problema:cómo almacenar de forma segura la clave de la aplicación. No sé una respuesta fácil para esa pregunta, pero mantenerla en su código fuente probablemente sea lo suficientemente bueno si teme que los datos de su base de datos puedan verse comprometidos, pero no el código fuente en sí, p. si su base de datos está almacenada fuera del sitio (piense en Amazon S3).
Saltar la clave de la aplicación con la contraseña del usuario ayuda si mantiene solo el hash de la contraseña en la base de datos, pero puede introducir otra falla de seguridad:debe mantener la contraseña del usuario en texto sin cifrar en la sesión de aplicaciones.
En cuanto a la solución técnica, es bastante simple y el código de muestra está disponible . Puede modificarlo de la siguiente manera para cifrar los datos con la contraseña de la aplicación salteada con hash de contraseña:
INSERT INTO secure_table VALUES (
1,
AES_ENCRYPT(
'plain text data',
CONCAT(@application_password, @user_password))
);
En cualquier caso, tendría que almacenar la contraseña de su aplicación en algún lugar, por lo que no creo que haya un enfoque fácil que brinde una seguridad perfecta.
Otro enfoque que se me ocurre es pedirle al usuario un PIN corto que podría usar como clave de cifrado. El PIN no se almacenaría en la base de datos, pero deberá pedírselo al usuario cada vez que acceda a sus datos.
Y, por supuesto, debe pensar en la viabilidad del cifrado. No podrá indexarlo ni buscarlo sin descifrarlo. Probablemente sea necesario para un conjunto limitado de datos (por ejemplo, número de tarjeta de crédito), pero no iría tan lejos.
