Je ne sais pas s'il y a beaucoup de sens à chiffrer les données avec le hachage du mot de passe de l'utilisateur, surtout si vous conservez le hachage lui-même dans la base de données. Dans ce cas, toute personne pouvant accéder aux données chiffrées peut également accéder au hachage du mot de passe et déchiffrer les données.
Une autre approche consisterait à chiffrer les données avec la clé spécifique à l'application salée avec des données spécifiques à l'utilisateur. Cependant, vous êtes alors confronté à un autre problème :comment stocker en toute sécurité la clé d'application. À cette question, je ne connais pas de réponse facile, mais la conserver dans votre code source est probablement suffisant si vous craignez que les données de votre base de données ne soient compromises, mais pas le code source lui-même, par ex. si votre base de données est stockée hors site (pensez à Amazon S3).
Saler la clé de l'application avec le mot de passe de l'utilisateur aide si vous ne conservez que le hachage du mot de passe dans la base de données, mais peut introduire une autre faille de sécurité :vous devez conserver le mot de passe de l'utilisateur en texte clair dans la session des applications.
Quant à la solution technique, elle est assez simple et un exemple de code est disponible . Vous pouvez le modifier comme suit pour chiffrer les données avec le mot de passe de l'application salé avec le hachage du mot de passe :
INSERT INTO secure_table VALUES (
1,
AES_ENCRYPT(
'plain text data',
CONCAT(@application_password, @user_password))
);
Dans tous les cas, vous devrez stocker votre mot de passe d'application quelque part, donc je ne pense pas qu'il existe une approche simple qui offre une sécurité parfaite.
Une autre approche à laquelle je peux penser consiste à demander à l'utilisateur un code PIN court que vous pourriez utiliser comme clé de cryptage. Le code PIN ne serait pas stocké dans la base de données, mais vous devrez le demander à l'utilisateur chaque fois que vous accéderez à ses données.
Et bien sûr, vous devez penser à la faisabilité du cryptage. Vous ne pourrez pas l'indexer ou le rechercher sans décryptage. Il est probablement nécessaire pour un ensemble limité de données (par exemple, un numéro de carte de crédit), mais je n'irais pas trop loin.
