Nie wiem, czy szyfrowanie danych hashem użytkownika ma sens, zwłaszcza jeśli przechowujesz sam hash w bazie danych. W takim przypadku każdy, kto ma dostęp do zaszyfrowanych danych, może również uzyskać dostęp do skrótu hasła i odszyfrować dane.
Innym podejściem byłoby zaszyfrowanie danych za pomocą klucza specyficznego dla aplikacji połączonego z niektórymi danymi specyficznymi dla użytkownika. Jednak wtedy stajesz przed kolejnym problemem:jak bezpiecznie przechowywać klucz aplikacji. Na to pytanie nie znam łatwej odpowiedzi, ale trzymanie jej w kodzie źródłowym jest prawdopodobnie wystarczające, jeśli obawiasz się, że dane Twojej bazy danych mogą zostać naruszone, ale nie sam kod źródłowy, np. jeśli Twoja baza danych jest przechowywana poza witryną (pomyśl o Amazon S3).
Zasolenie klucza aplikacji hasłem użytkownika pomaga, jeśli w bazie danych przechowujesz tylko skrót hasła, ale może wprowadzić inną lukę w zabezpieczeniach:musisz zachować hasło użytkownika w postaci zwykłego tekstu podczas sesji aplikacji.
Jeśli chodzi o rozwiązanie techniczne, jest ono dość proste i przykładowy kod jest dostępny . Możesz go zmodyfikować w następujący sposób, aby zaszyfrować dane za pomocą hasła aplikacji połączonego z hashem hasła:
INSERT INTO secure_table VALUES (
1,
AES_ENCRYPT(
'plain text data',
CONCAT(@application_password, @user_password))
);
W każdym razie musiałbyś gdzieś przechowywać hasło aplikacji, więc nie sądzę, że istnieje łatwe podejście, które zapewnia doskonałe bezpieczeństwo.
Innym podejściem, jakie przychodzi mi do głowy, jest poproszenie użytkownika o krótki kod PIN, którego można użyć jako klucza szyfrowania. Kod PIN nie byłby przechowywany w bazie danych, ale będziesz musiał prosić o to użytkownika za każdym razem, gdy uzyskujesz dostęp do jego danych.
I oczywiście musisz pomyśleć o możliwości szyfrowania. Nie będzie można go indeksować ani przeszukiwać bez odszyfrowania. Jest to prawdopodobnie wymagane w przypadku ograniczonego zestawu danych (np. numeru karty kredytowej), ale nie posunąłbym się z tym zbyt daleko.