Não sei se há muito sentido em criptografar dados com o hash de senha do usuário, especialmente se você mantiver o próprio hash no banco de dados. Nesse caso, qualquer pessoa que possa acessar os dados criptografados também pode acessar o hash de senha e descriptografar os dados.
Outra abordagem seria criptografar os dados com a chave específica do aplicativo com alguns dados específicos do usuário. No entanto, você enfrenta outro problema:como armazenar com segurança a chave do aplicativo. Para essa pergunta, não sei uma resposta fácil, mas mantê-la em seu código-fonte provavelmente é bom o suficiente se você tem medo de que seus dados de banco de dados possam ser comprometidos, mas não o próprio código-fonte, por exemplo. se seu banco de dados estiver armazenado fora do local (pense no Amazon S3).
Saltar a chave do aplicativo com a senha do usuário ajuda se você mantiver apenas o hash da senha no banco de dados, mas pode introduzir outra falha de segurança:você precisa manter a senha do usuário em texto não criptografado na sessão do aplicativo.
Quanto à solução técnica, é bastante simples e o código de amostra está disponível . Você pode modificá-lo da seguinte forma para criptografar os dados com a senha do aplicativo salgada com hash de senha:
INSERT INTO secure_table VALUES (
1,
AES_ENCRYPT(
'plain text data',
CONCAT(@application_password, @user_password))
);
De qualquer forma, você teria que armazenar a senha do seu aplicativo em algum lugar, então não acho que exista uma abordagem fácil que forneça segurança perfeita.
Outra abordagem em que posso pensar é pedir ao usuário um PIN curto que você possa usar como chave de criptografia. O PIN não seria armazenado no banco de dados, mas você precisaria pedir ao usuário toda vez que acessar seus dados.
E é claro que você tem que pensar na viabilidade da criptografia. Você não poderá indexar ou pesquisá-lo sem descriptografia. Provavelmente é necessário para um conjunto limitado de dados (por exemplo, número do cartão de crédito), mas eu não iria muito longe com isso.