2012-01-24 10 views
7

Tôi có một trang web mà người dùng gửi dữ liệu cá nhân của họ và tôi đang nghĩ đến việc mã hóa các dữ liệu này bằng aes-256 và mật khẩu của họ được sử dụng làm khóa cho mã hóa đó và sau đó tôi lưu trữ dữ liệu được mã hóa trong cơ sở dữ liệu mysql. ..Làm thế nào để thay đổi khóa aes-256 sau khi mã hóa?

Bây giờ nếu người dùng thay đổi mật khẩu của mình thế nào tôi sẽ thay đổi quan trọng của dữ liệu được mã hóa

tôi có nên thu thập tất cả các dữ liệu từ cơ sở dữ liệu sau đó giải mã dữ liệu của họ với phím cũ sau đó mã hóa nó một lần nữa với một chìa khoá mới?

Trả lời

13

Bạn không cần phải mã hóa lại tất cả dữ liệu của người dùng khi họ thay đổi mật khẩu của họ.

Tạo khóa bí mật để mã hóa dữ liệu của người dùng; gọi đây là "khóa mã hóa nội dung". Lấy chìa khóa từ mật khẩu của người dùng; gọi đây là "khóa mã hóa khóa". Mã hóa "khóa mã hóa nội dung" bằng cách sử dụng "khóa mã hóa khóa". Lưu trữ khóa được mã hóa cùng với muối và số lần lặp được sử dụng cho dẫn xuất khóa.

Nếu họ thay đổi mật khẩu, hãy giải mã khóa mã hóa nội dung bằng mật khẩu cũ và mã hóa lại bằng khóa có nguồn gốc từ mật khẩu mới. Bạn nên chọn một muối mới cho mật khẩu mới và đảm bảo bạn lưu trữ nó cùng với khóa được mã hóa mới.

Vì khóa mã hóa nội dung được chọn ngẫu nhiên từ một không gian rộng lớn, bạn có thể sử dụng ECB một cách an toàn làm chế độ mã hóa khi mã hóa nó.

Không chỉ đơn giản là băm mật khẩu, ngay cả khi bạn sử dụng muối, ngay cả khi bạn sử dụng thuật toán chưa được giải mã. Bạn cần lặp lại thao tác băm hàng ngàn lần. Có các thư viện để thực hiện việc này (chính xác) trên hầu hết các nền tảng. Sử dụng thuật toán dẫn xuất khóa (PBKDF2, từ PKCS # 5) để tạo khóa bí mật từ mật khẩu.

Khái niệm này sau the draft for password-based S/MIME encryption.

+0

Mã khóa được lưu trữ ở đâu? Trong bộ nhớ trên máy chủ ứng dụng, hoặc trong lưu trữ vật lý trên máy chủ cơ sở dữ liệu? – dimiguel

+0

@dimgl Được lưu trữ trong một số lưu trữ đáng tin cậy, liên tục, có bản sao lưu. Chắc chắn không có trong bộ nhớ. Trừ khi bạn không quan tâm nếu nội dung bị phá hủy không thể thu hồi bằng cúp điện. – erickson

0

Thats ngớ ngẩn.

AES sử dụng khóa 256 bit để khi bạn nói rằng bạn sẽ sử dụng mật khẩu của họ cho khóa, nó sẽ không được gần như miễn là yêu cầu kích thước khóa.

+0

Tôi sẽ băm mật khẩu của họ để cung cấp cho tôi 256 byte sau đó sử dụng nó trong mã hóa –

+0

Ok, vậy định dạng của bạn để tạo khóa là gì? –

3

Trước tiên, bạn thường không nên sử dụng mật khẩu làm khóa AES. Có lẽ một cái gì đó giống như một băm mật mã (không phải MD5) của mật khẩu + một muối (bạn sẽ lưu trữ muối nhưng không phải là băm trong trường hợp này).

Một điều bạn có thể làm là mã hóa từng tệp của người dùng bằng một khóa ngẫu nhiên, sau đó mã hóa khóa đó bằng mật khẩu băm + muối. Nếu người dùng thay đổi mật khẩu, bạn chỉ phải mã hóa lại khóa.

2

Một khả năng để xem xét tách riêng chìa khóa dùng để mã hóa dữ liệu từ chính được sử dụng để truy cập vào dữ liệu. Thực hiện cẩn thận, điều này cho phép người dùng thay đổi mật khẩu của họ thường xuyên như họ mong muốn, trong khi bạn chỉ thay đổi một bản ghi trong cơ sở dữ liệu. Riêng biệt, bạn có thể lên lịch thay đổi (các) khóa mã hóa dữ liệu của chúng khi nó thuận tiện cho bạn.

Tính năng này hoạt động như thế nào?

  • Bạn mã hóa dữ liệu D cho người dùng U bằng khóa được tạo ngẫu nhiên, K U, D.
  • Bạn mã hóa phím K U, D với K1 chìa khóa riêng biệt U, K tạo ra từ một muối ngẫu nhiên, S1 U (mà bạn lưu giữ hồ sơ của) và mật khẩu của người dùng P1 U (mà bạn có thể hoặc không thể theo dõi). Khóa được mã hóa là E1 U.
  • Bạn lưu trữ S1 U và K1 U, K sẵn sàng cho thời điểm người dùng muốn truy cập dữ liệu của họ.
  • Khi người dùng U muốn truy cập dữ liệu của họ, họ cung cấp cho bạn mật khẩu của họ, P1 U, và bạn nhìn lên S1 U và tái tạo K1 U, K từ dữ liệu đó, và sử dụng để giải mã E1 U, cung cấp cho bạn K U, D một lần nữa, khi đó bạn giải mã dữ liệu thực của họ.
  • Bạn đảm bảo rằng bạn có thể phát hiện khi mật khẩu được cung cấp chính xác, do đó bạn không cần phải sử dụng mã nhị phân nếu người dùng nhập sai mật khẩu.

Ưu điểm của mức độ vô hướng này xuất hiện khi người dùng muốn thay đổi mật khẩu của họ. Nếu bạn không sử dụng một số kỹ thuật tương tự như vậy, bạn sẽ phải nhận và xác nhận mật khẩu cũ và mật khẩu mới, giải mã tất cả dữ liệu bằng mật khẩu cũ và mã hóa lại tất cả bằng mật khẩu mới.

Với mức độ gián tiếp, bạn vẫn nhắc nhở người dùng nhập mật khẩu cũ của họ (P1 U) và mật khẩu mới của họ (P2 U) và xác nhận chúng, nhưng bạn chỉ cần giải mã E1 U và sau đó tái mã hóa nó với một K2 khóa mới U, K tạo ra từ một muối mới S2 U và mật khẩu mới P2 U. Bạn không cần phải chạm vào dữ liệu được mã hóa.

Với mức độ gián tiếp, hệ thống S cũng có thể giữ bản sao mã hóa thứ hai của khóa dữ liệu K U, D, được mã hóa bằng mật khẩu của hệ thống. Nếu nó trở nên cần thiết hoặc mong muốn thay đổi khóa được sử dụng để mã hóa dữ liệu, hệ thống có thể sử dụng bản sao mã hóa của khóa để mã hóa. Nó có thể giữ một bản ghi khóa nào được người dùng ghi lại lần cuối trong khóa của họ, vì vậy khi người dùng quay lại xem dữ liệu, nó có thể sắp xếp để thay đổi khóa đã lưu K2 U, D vì tại thời điểm đó có mật khẩu của họ (phần còn lại của thời gian, nó không).

Đây là một biến thể nhẹ về một số ý tưởng trong "Cryptography in the Database: The Last Line of Defense" của Kevin Kenan. Các phím Kn U, K là ví dụ về KEK, Khóa mã hóa khóa. Bạn cũng có thể đọc về các gia đình chính trong cuốn sách, điều này sẽ giúp quản lý dữ liệu được mã hóa.