2008-10-24 12 views
10

Tôi định sử dụng MySQL và chức năng mã hóa được tích hợp sẵn để mã hóa/giải mã các cột nhất định trong một số bảng nhất định. Mối quan tâm tôi có là tôi cần lưu trữ chìa khóa ở đâu đó. Tôi chắc chắn có thể lưu trữ chìa khóa trong một tập tin và kiểm soát các điều khoản của tập tin đó và các quyền của ứng dụng truy cập nó, nhưng là đủ? Tôi cũng có thể tạo một dịch vụ web để lấy chìa khóa hoặc thứ gì đó.Phương pháp tốt nhất để sử dụng/lưu trữ khóa mã hóa trong MySQL

Tôi đang ở một cửa hàng nhỏ, nơi tôi sẽ là người duy nhất (có thể là một người khác) có quyền truy cập vào máy mà ứng dụng đã bật. Chỉnh sửa: Tôi nên thêm rằng có một trang web phải đối mặt với một phần của ứng dụng này sẽ cần phải giải mã dữ liệu trừ khi tôi thêm một tầng.

Tôi đã xem xét tạm dừng quảng cáo, nhưng dường như không ai có câu trả lời chống đạn.

Đây có phải là một trong những vấn đề mà bạn phải giải quyết đủ tốt không? Cho rằng tôi đang sử dụng MySQL và PHP (có thể Python) là có một cách tốt hơn để tiếp cận này?

+0

Mục đích mã hóa cột là gì? Chắc chắn điều thông minh cần làm là mã hóa dữ liệu nhạy cảm của hàng thông qua ứng dụng của bạn và lưu trữ một muối cùng với hàng để khó giải mã hơn. – Aupajo

+0

Tôi đoán tôi có nghĩa là mã hóa một trường nhất định trong mỗi hàng bằng AES_ENCRYPT. Vì vậy, việc mã hóa và giải mã ứng dụng tốt hơn các chức năng của MySQL hoặc bạn chỉ nói rằng tôi nên có một khóa muối duy nhất cho mỗi hàng khi gọi các hàm MySQL –

Trả lời

6

Tôi không chắc chắn nếu sử dụng MySQL xây dựng trong mã hóa sẽ là giải pháp tốt nhất cho vấn đề của bạn.

Gói M_CRYPT của PHP được cho là khá tốt và nó mang lại cho bạn sự linh hoạt để chọn thuật toán phù hợp nhất với nhu cầu của bạn.

Lưu trữ khóa của bạn trên một số máy chủ khác có một lợi thế lớn: khóa không nằm trên cùng một máy với dữ liệu được mã hóa *).Vì vậy, miễn là kẻ tấn công không có đủ quyền kiểm soát máy bị xâm nhập, họ không thể lấy chìa khóa.
Nếu kẻ tấn công có toàn quyền điều khiển máy, dữ liệu được lưu trữ, họ rất có thể sẽ truy vấn dịch vụ web cho khóa.

Tuy nhiên, truyền chìa khóa từ máy này sang máy khác sẽ mở ra toàn bộ khu vực mới cần được bảo mật. Có thể liên quan đến nhiều lớp mã hóa và nhiều khóa hơn, do đó làm tăng cơ hội mắc lỗi.

*) Tùy chọn khác là nhập mật khẩu khi máy chủ web khởi động và chỉ giữ nó trong bộ nhớ.

giải pháp có thể
Nếu nhìn thấy một giải pháp tuyển dụng mà sử dụng các phương pháp sau đây để mã hóa các tập tin cho người dùng với quyền truy cập web (Tôi không chắc chắn của môi trường của bạn, nhưng nó có thể là hữu ích):

  • Khi người dùng tạo, một khóa ngẫu nhiên dài được gán cho người dùng mới.
  • Khóa ngẫu nhiên này được lưu trữ trong cột được mã hóa trong hồ sơ người dùng.
    (chỉ cột này được mã hóa để không ảnh hưởng đến hiệu suất của phần còn lại của kỷ lục!)
  • Các mã hóa của cột ngẫu nhiên-key được thực hiện với 1 mật khẩu chủ, lưu trữ trong một tập tin hoặc trong bộ nhớ.
    (Các lựa chọn tốt hơn là nhập mật khẩu khi nhìn chằm chằm máy chủ web và chỉ lưu trữ nó trong bộ nhớ.)
    (cách tiếp cận khác là cho phép người dùng nhập mật khẩu và sử dụng để mã hóa/giải mã random- cột khóa, nhưng tôi không chắc liệu điều đó có tăng hoặc giảm bảo mật)
  • Mọi tài liệu cần được mã hóa đều được mã hóa bằng khóa ngẫu nhiên cho người dùng đó và sau đó được lưu trữ trên đĩa.
  • Tài liệu được lưu trữ với các quyền tối thiểu trong hệ thống tệp.

Những lợi thế của phương pháp này là:
1. ngẫu nhiên-key được mã hóa trong cơ sở dữ liệu. Vì vậy, bạn vẫn có thêm bảo mật của máy chủ cơ sở dữ liệu, kết hợp với cột được mã hóa. 2. Tài liệu được lưu trữ với các khóa khác nhau, nếu kẻ tấn công nắm giữ chìa khóa, chỉ một phần tài liệu bị xâm phạm.

Tuy nhiên:
Nếu kẻ tấn công được tổ chức của Master Password đã đọc truy cập vào sử dụng bảng, toàn bộ hệ thống là, một lần nữa, bị hỏng.

1

Dường như bạn đang xem xét việc sử dụng khóa 'cụ thể theo cột' để sử dụng với 'AES_ENCRYPT' và 'AES_DECRYPT'. Như người bình luận đã nói, đây là một ý tưởng tồi, bởi vì mọi xâm nhập sẽ có quyền truy cập vào tất cả dữ liệu.

Nếu bạn sử dụng mật khẩu 'do người dùng cung cấp', có/không có muối, bạn sẽ an toàn hơn nhiều.

Điều đó nói rằng, nếu khóa mã hóa chỉ có thể đọc được bằng ứng dụng sử dụng nó, có thể bạn 'đủ tốt'. Nếu máy bị hỏng, chúng sẽ lấy dữ liệu của bạn nhanh hơn với một phím duy nhất.

4

Tôi có thể lưu trữ tệp đó trong một tệp nằm trong thư mục không thể truy cập web và được khóa với quyền của hệ thống tệp càng nhiều càng tốt.

Tập lệnh trên web của bạn không được mở bất kỳ tệp hệ thống tệp nào bằng các biến, đặc biệt là các biến do người dùng cung cấp. Thậm chí không cung cấp cho họ tùy chọn trượt một cái gì đó thông qua bộ lọc đầu vào của bạn (bạn đang lọc dữ liệu người dùng cung cấp của bạn phải không?) Và có thể từ bỏ các nội dung của tập tin quan trọng. Giữ đường dẫn tệp tới các chuỗi được mã hóa cứng và chỉ định(). Vì hầu hết dữ liệu của bạn được lưu trữ trong MySQL, đây không phải là vấn đề.

Khi thực hiện giải mã, hãy đọc khóa thành biến được khởi tạo sạch, thực hiện giải mã, sau đó ghi đè biến khóa (nói bằng chuỗi x) và không đặt biến. Điều này có thể nghe có vẻ hơi hoang tưởng nhưng nếu bạn giảm thiểu thời gian chìa khóa trong bộ nhớ và cô lập nó khỏi tất cả các biến khác xung quanh kịch bản PHP của bạn, nó không thể làm cho bạn bất kỳ số an toàn nào là .

Nếu bạn và người kia là người duy nhất có quyền truy cập vật lý vào máy, điều này có thể là tốt. Nếu ai đó đột nhập vào và đánh cắp hộp, tốt, họ đã có tất cả dữ liệu của bạn để trò chơi kết thúc.