Tôi không biết liệu mã hóa dữ liệu bằng hàm băm mật khẩu của người dùng có nhiều ý nghĩa hay không, đặc biệt là nếu bạn giữ chính hàm băm trong cơ sở dữ liệu. Trong trường hợp đó, bất kỳ ai có thể truy cập vào dữ liệu được mã hóa cũng có thể truy cập hàm băm mật khẩu và giải mã dữ liệu.
Một cách tiếp cận khác sẽ là mã hóa dữ liệu bằng khóa dành riêng cho ứng dụng được kết hợp với một số dữ liệu dành riêng cho người dùng. Tuy nhiên, sau đó bạn phải đối mặt với một vấn đề khác:làm thế nào để lưu trữ khóa ứng dụng một cách an toàn. Đối với câu hỏi đó, tôi không biết một câu trả lời dễ dàng, nhưng giữ nó trong mã nguồn của bạn có lẽ là đủ tốt nếu bạn sợ rằng dữ liệu cơ sở dữ liệu của mình có thể bị xâm phạm, nhưng không phải chính mã nguồn, ví dụ:nếu cơ sở dữ liệu của bạn được lưu trữ bên ngoài trang web (hãy nghĩ đến Amazon S3).
Việc trộn khóa ứng dụng với mật khẩu của người dùng sẽ giúp ích nếu bạn chỉ giữ hàm băm của mật khẩu trong cơ sở dữ liệu, nhưng có thể tạo ra một lỗ hổng bảo mật khác:bạn phải giữ mật khẩu của người dùng ở dạng văn bản rõ ràng trong phiên ứng dụng.
Về giải pháp kỹ thuật, nó khá đơn giản và mã mẫu có sẵn . Bạn có thể sửa đổi nó như sau để mã hóa dữ liệu với mật khẩu ứng dụng được ướp muối với mật khẩu băm:
INSERT INTO secure_table VALUES (
1,
AES_ENCRYPT(
'plain text data',
CONCAT(@application_password, @user_password))
);
Trong mọi trường hợp, bạn sẽ phải lưu trữ mật khẩu ứng dụng của mình ở đâu đó vì vậy tôi không nghĩ rằng có một cách tiếp cận dễ dàng cung cấp bảo mật hoàn hảo.
Một cách tiếp cận khác mà tôi có thể nghĩ đến là yêu cầu người dùng cung cấp một mã PIN ngắn mà bạn có thể sử dụng làm khóa mã hóa. Mã PIN sẽ không được lưu trữ trong cơ sở dữ liệu, nhưng bạn sẽ cần yêu cầu người dùng cung cấp nó mỗi khi bạn truy cập vào dữ liệu của họ.
Và tất nhiên bạn phải nghĩ đến tính khả thi của mã hóa. Bạn sẽ không thể lập chỉ mục hoặc tìm kiếm nó mà không giải mã. Nó có thể được yêu cầu đối với một bộ dữ liệu giới hạn (ví dụ:số thẻ tín dụng), nhưng tôi sẽ không đi xa với nó.
