Jeg ved ikke, om der er meget mening i at kryptere data med brugerens adgangskode-hash, især hvis du beholder selve hashen i databasen. I så fald kan alle, der kan få adgang til de krypterede data, også få adgang til adgangskodehashen og dekryptere dataene.
En anden tilgang ville være at kryptere dataene med den applikationsspecifikke nøgle saltet med nogle brugerspecifikke data. Men så står du over for et andet problem:hvordan man sikkert opbevarer applikationsnøglen. På det spørgsmål kender jeg ikke et nemt svar, men at beholde det i din kildekode er nok godt nok, hvis du frygter at dine databasedata kan blive kompromitteret, men ikke selve kildekoden, f.eks. hvis din database er gemt off-site (tænk Amazon S3).
Saltning af app-nøglen med brugerens adgangskode hjælper, hvis du kun beholder hash for adgangskoden i databasen, men kan introducere en anden sikkerhedsbrist:du skal opbevare brugerens adgangskode i klartekst i applikationssessionen.
Med hensyn til teknisk løsning er den ret simpel og eksempelkode er tilgængelig . Du kan ændre det som følger for at kryptere dataene med applikationsadgangskoden saltet med password-hash:
INSERT INTO secure_table VALUES (
1,
AES_ENCRYPT(
'plain text data',
CONCAT(@application_password, @user_password))
);
Under alle omstændigheder bliver du nødt til at gemme din applikationsadgangskode et sted, så jeg tror ikke, der er en nem tilgang, der giver perfekt sikkerhed.
En anden fremgangsmåde, jeg kan komme i tanke om, er at bede brugeren om en kort PIN-kode, som du kan bruge som en krypteringsnøgle. PIN-koden ville ikke blive gemt i databasen, men du skal bede brugeren om det, hver gang du får adgang til deres data.
Og selvfølgelig skal du tænke på krypteringens gennemførlighed. Du vil ikke være i stand til at indeksere eller søge i det uden dekryptering. Det er sandsynligvis påkrævet for et begrænset sæt data (f.eks. kreditkortnummer), men jeg ville ikke gå så langt med det.