Crypt và DES là những cypher cũ và không nên được sử dụng
DES cũ thuần túy là một thuật toán lỗi thời. Bạn thực sự không thể so sánh nó với AES128 một cách hữu ích; nó giống như phàn nàn rằng băm SHA256 lớn hơn băm MD5 - đúng vậy, nhưng chỉ một trong số chúng có thể làm chậm kẻ tấn công trong một thời gian. DES bị coi là yếu ngay cả vào năm 1999 và không bao giờ được sử dụng trong các ứng dụng mới. Không sử dụng nó.
Tôi không nghĩ rằng việc tìm kiếm một phương pháp mã hóa "cung cấp kích thước dữ liệu nhỏ nhất có thể" là một ý tưởng hay - vì về cơ bản, việc mã hóa dữ liệu bằng DES sẽ rất lãng phí thời gian. Tại sao không sử dụng ROT13 (caesar cypher)? Kết quả "được mã hóa" có cùng kích thước với đầu vào, tiếc là mã hóa có thể bị phá vỡ bởi một đứa trẻ 3 tuổi.
crypt là của một cổ điển tương tự. Thuật toán băm mã UNIX cũ là ... người cao tuổi ... và hoàn toàn không phù hợp với bất kỳ ứng dụng mới nào. Thực sự, hàm băm phải là SHA256.
Crypt là hàm băm một chiều
Về việc không thể tìm ra cách giải mã dữ liệu đã được mã hóa: crypt không phải là một thuật toán mã hóa, nó là một hàm băm mật mã hoặc "một cách băm". Hàm băm có một cách phù hợp để xác minh rằng dữ liệu không bị sửa đổi, so sánh với một được lưu trữ > băm để xác thực mật khẩu, để sử dụng trong xác thực phản hồi thử thách , v.v. Bạn không thể giải mã dữ liệu đã mã hóa.
Xử lý kích thước
Sử dụng một chức năng mật mã tốt và sống với sự gia tăng kích thước. bf hoặc aes128 là yếu nhất mà bạn có thể sử dụng một cách hợp lý.
Cá nhân tôi thích thực hiện mã hóa / giải mã của mình trong ứng dụng, không phải trong DB. Nếu nó được thực hiện trong DB, các khóa có thể được tiết lộ bởi pg_stat_statements , trong nhật ký của log_statement hoặc lỗi, v.v. Tốt hơn hết là khóa không bao giờ ở cùng một vị trí với dữ liệu được lưu trữ.
Hầu hết các ngôn ngữ lập trình đều có các quy trình mật mã tốt mà bạn có thể sử dụng.
Thật khó để đưa ra bất kỳ lời khuyên nào nữa vì bạn chưa thực sự giải thích những gì bạn đang mã hóa, tại sao, yêu cầu của bạn là gì, (các) mối đe dọa là gì, v.v.
Mật khẩu?
Nếu bạn đang lưu trữ mật khẩu, có thể bạn đang làm sai.
-
Nếu có thể, hãy để người khác xác thực:
-
OAuth hoặc OpenID cho Internet
-
SSPI, Kerberos / GSSAPI, Active Directory, LDAP bind, SASL, HTTP DIGEST, v.v. cho mạng nội bộ
-
-
Nếu bạn thực sự phải tự mình xác thực, hãy thêm muối vào mật khẩu và băm kết quả. Lưu trữ băm và muối. Khi bạn phải so sánh mật khẩu, hãy muối bản rõ mới từ người dùng với chính muối bạn đã sử dụng cho hàm băm đã lưu trữ, băm mật khẩu + muối mới và xem liệu hàm băm có giống với những gì bạn đã lưu trữ hay không. Nếu đúng, họ đã cung cấp đúng mật khẩu.
-
Bạn gần như chắc chắn không cần khôi phục mật khẩu văn bản rõ ràng. Thực hiện đặt lại mật khẩu an toàn thay thế. Nếu bạn thực sự, thực sự phải sử dụng một thuật toán an toàn tuyệt đối như aes để mã hóa chúng và suy nghĩ cẩn thận về việc lưu trữ và quản lý khóa. Xem các bài đăng khác trên SO về lưu trữ / quản lý khóa với pgcrypto.
Xem thêm:
