2009-09-07 76 views
28

Ứng dụng của tôi (hiển nhiên) sử dụng một ID duy nhất để phân biệt các bản ghi. UID này được chuyển vào URL (ví dụ: ./examplepage.php?UID=$example_int), trong số những thứ khác.Mã hóa hai chiều trong PHP

Mặc dù tôi có xác thực phía máy chủ để đảm bảo khách hàng không truy cập dữ liệu của khách hàng khác, có phương pháp mã hóa hai chiều tôi có thể sử dụng trong PHP để chỉ chuyển UID được mã hóa (ví dụ: ./examplepage.php?EUID=$encrypted_int), để giảm thêm cơ hội của bất cứ ai nghĩ "hey, chuyện gì sẽ xảy ra nếu tôi tăng số nguyên này?"

TIA.

+0

đã bỏ phiếu vì tôi không nghĩ rằng cuộc trò chuyện kết thúc thực sự là về mã hóa hai chiều ... –

Trả lời

-3

Đặt một băm bên cạnh ID để đảm bảo bảo mật hoặc đệm ID với dữ liệu bổ sung hoặc thậm chí chuyển đổi ID thành hex sẽ hoạt động khá tốt.

+2

Cảm ơn bạn, hãy gọi điện để chuyển đổi thành hex. – benjy

+0

Mặc dù nó sẽ không bảo vệ từ bất cứ ai "hiểu biết về công nghệ" để thử số hex tiếp theo. Bạn chỉ đang thay đổi căn cứ, vấn đề "tiềm năng" vẫn còn. – rogeriopvl

+5

@benjy bất kỳ ai có sáng kiến ​​tăng UID, sẽ ngay lập tức nhận ra một phần tử hex hoặc đệm. Bạn thực sự nên làm những gì @caf đề xuất. Hoặc chỉ tạo UID không tăng, không thể dự đoán được. – bucabay

3

Trong khi PHP hỗ trợ nhiều thuật toán băm hai chiều, tôi không thấy nó hữu ích trong ví dụ này. Những gì bạn cần làm là:

  1. tải hàng từ lưu trữ bằng id cung cấp
  2. Kiểm tra rằng chủ sở hữu của hàng là người dùng xác thực và nếu không ném một ngoại lệ và thông báo cho người sử dụng không phải làm điều đó một lần nữa

Nhưng nếu trái tim của bạn được đặt trên băm chỉ cần chọn một trong các thuật toán provided.

+0

Cảm ơn bạn đã đề xuất. Tôi thực sự đã làm điều đó, nhưng tôi chỉ muốn một cách khác để ngăn cản người dùng làm rối tung với giá trị đó. – benjy

+0

Điều chắc chắn. Tôi thường không lo lắng về những thứ như thế. Có ít thiệt hại mà người dùng có thể làm bằng cách làm rối tung các id nếu bạn có ACL phù hợp. –

+0

sẽ không làm cho bước thứ 2 đầu tiên hiệu quả hơn? –

27

Bạn không cần mã hóa hai chiều - mã hóa để duy trì bảo mật, nhưng những gì bạn đang thực sự tìm kiếm ở đây là tính xác thực.

HMAC (về bản chất, băm có khóa) là một cách để nhận được tính xác thực mật mã. Đi kèm với UID với một HMAC của UID (PHP có một HMAC implementation), sử dụng một khóa mà chỉ có máy chủ biết. Khi bắt đầu mỗi yêu cầu, hãy kiểm tra HMAC.

Về cơ bản, hãy sử dụng đúng công cụ cho đúng công việc.

+0

NÀY YÊU CẦU MỘT L DBNH VỰC BỔ SUNG BỔ SUNG. Tôi đồng ý với điều này, nhưng điều này đòi hỏi phải lưu trữ nó trong một lĩnh vực bổ sung. –

+0

@AlexV: Không phải vì máy chủ có thể tính toán lại HMAC khi nhận được yêu cầu. – caf

85

PHP 5.3 đã giới thiệu một phương pháp mã hóa mới thực sự dễ sử dụng: openssl_encryptopenssl_decrypt. Tài liệu không được viết ở đây, vì vậy đây là một ví dụ đơn giản:

$textToEncrypt = "My super secret information."; 
$encryptionMethod = "AES-256-CBC"; // AES is used by the U.S. gov't to encrypt top secret documents. 
$secretHash = "25c6c7ff35b9979b151f2136cd13b0ff"; 

//To encrypt 
$encryptedMessage = openssl_encrypt($textToEncrypt, $encryptionMethod, $secretHash); 

//To Decrypt 
$decryptedMessage = openssl_decrypt($encryptedMessage, $encryptionMethod, $secretHash); 

//Result 
echo "Encrypted: $encryptedMessage <br>Decrypted: $decryptedMessage"; 

Tôi chọn 256-AES vì nó chắc chắn và nhanh. Nó đã được chính phủ Hoa Kỳ chấp nhận để mã hóa các tài liệu bí mật hàng đầu. Nó nhanh chóng xem xét máy và phần mềm.Dưới đây là danh sách các phương pháp mã hóa có sẵn:

AES-128-CBC, AES-128-CFB, AES-128-CFB1, AES-128-CFB8, AES-128-ECB, AES-128-OFB, AES- 192-CBC, AES-192-CFB, AES-192-CFB1, AES-192-CFB8, AES-192-ECB, AES-192-OFB, AES-256-CBC, AES-256-CFB, AES-256- CFB1, AES-256-CFB8, AES-256-ECB, AES-256-OFB, BF-CBC, BF-CFB, BF-ECB, BF-OFB, CAMELLIA-128-CBC, CAMELLIA-128-CFB, CAMELLIA- 128-CFB1, CAMELLIA-128-CFB8, CAMELLIA-128-ECB, CAMERA-128-OFB, CAMELLIA-192-CBC, CAMELLIA-192-CFB, CAMELLIA-192-CFB1, CAMELLIA-192-CFB8, CAMELLIA-192- ECB, CAMELLIA-192-OFB, CAMELLIA-256-CBC, CAMELLIA-256-CFB, CAMELLIA-256-CFB1, CAMELLIA-256-CFB8, CAMELLIA-256-ECB, CAMELLIA-256-OFB, CAST5-CBC, CAST5- CFB, CAST5-ECB, CAST5-OFB, DES-CBC, DES-CFB, DES-CFB1, DES-CFB8, DES-ECB, DES-EDE, DES-EDE-CBC, DES-EDE-CFB, DES-EDE- OFB, DES-EDE3, DES-EDE3-CBC, DES-EDE3-CFB, DES-EDE3-CFB1, DES-EDE3-CFB8, DES-EDE3-OFB, DES-OFB, DESX-CBC, RC2-40-CBC, RC2-64-CBC, RC2-CBC, RC2-CFB, RC2-ECB, RC2-OFB, RC4, RC4-40, SEED-CBC, SEED-CFB, SEED-ECB, SEED-OFB, aes-128-cbc, aes-128-cfb, aes-128-cfb1, a-128-cfb8, aes-128-ecb, aes-128-ofb, aes-192-cbc, aes-192- cfb, aes-192-cfb1, aes-192-cfb8, aes-192-ecb, aes-192-ofb, aes-256-cbc, aes-256-cfb, aes-256-cfb1, aes-256-cfb8, aes-256-ecb, aes-256-ofb, bf-cbc, bf-cfb, bf-ecb, bf-ofb, camellia-128-cbc, camellia-128-cfb, camellia-128-cfb1, camellia-128- cfb8, camellia-128-ecb, camellia-128-ofb, camellia-192-cbc, camellia-192-cfb, camellia-192-cfb1, camellia-192-cfb8, camellia-192-ecb, camellia-192-ofb, camellia-256-cbc, camellia-256-cfb, camellia-256-cfb1, camellia-256-cfb8, camellia-256-ecb, camellia-256-ofb, cast5-cbc, cast5-cfb, cast5-ecb, cast5- ofb, des-cbc, des-cfb, des-cfb1, des-cfb8, des-ecb, des-ede, des-ede-cbc, des-ede-cfb, des-ede-ofb, des-ede3, des- ede3-cbc, des-ede3-cfb, des-ede3-cfb1, des-ede3-cfb8, des-ede3-ofb, des-ofb, desx-cbc, rc2-40-cbc, rc2-64-cbc, rc2- cbc, r c2-CFB, RC2-ECB, RC2-ofb, rc4, rc4-40, hạt giống-CBC, hạt giống-CFB, hạt giống-ECB, hạt giống-ofb


CẬP NHẬT QUAN TRỌNG !!!

Cảm ơn Hobo và Jorwin đã chỉ ra rằng trong PHP 5.3.3> có một tham số mới làm cho chức năng này an toàn hơn một chút.

Jorwin tham chiếu liên kết này trong his comment, và đây là một đoạn trích đó là áp dụng:

Trong 5.3.3 họ đã thêm vào một tham số mới, string $iv (khởi vector) các thông số thực là: string openssl_encrypt (string $data , string $method , string $password, bool $raw_output = false, string $iv)

Nếu thiếu $iv, cảnh báo được đưa ra: "Sử dụng Vector khởi tạo trống (iv) có khả năng không an toàn và không được khuyến nghị".

Nếu $iv là quá ngắn, cảnh báo khác: "IV thông qua chỉ dài 3 byte, mật mã hy vọng một IV chính xác 8 byte, đệm với \ 0"

cùng IV nên được sử dụng trong openssl_decrypt()

+0

Sử dụng điều này như được hiển thị cho tôi một cảnh báo "Sử dụng Vector khởi tạo trống (iv) có khả năng không an toàn và không được khuyến nghị". Đó có phải là một tham số mới không? Câu trả lời này có nên được cập nhật không? – Hobo

+2

@Hobo - Bạn nói đúng, tôi đã gặp phải vấn đề tương tự. Đây là một lời giải thích chi tiết hơn. Cảm ơn espradley cho câu trả lời mặc dù. http://php.net/manual/en/function.openssl-encrypt.php#104438 – Joe

+0

@Jowin - hoàn toàn đúng. Tôi đang trên php 5.2.2 nhưng như 5.3.3 bạn thực sự sẽ cần phải vượt qua trong tham số thứ 5 hoặc nhận được một cảnh báo. Nó chỉ là một cảnh báo để nó sẽ không phá vỡ các ứng dụng cho mỗi nói, nhưng nó def an toàn hơn để vượt qua nó. – espradley

0

Đầu tiên, encrypting URL parameters is usually a bad idea và tra cứu riêng (dựa trên chỉ mục CHAR cột do CSPRNG tạo) tốt hơn cho 99,9% trường hợp sử dụng.

Với điều đó đã nói: Có, bạn có thể sử dụng phần mở rộng OpenSSL (don't use mcrypt) để mã hóa dữ liệu like espradley suggested, tuy nhiên tôi sẽ cảnh báo bạn không chỉ dừng lại ở mã hóa đơn thuần.

Encryption without message authentication is dangerous, đặc biệt là nếu bạn tin tưởng người dùng cuối bằng mật mã.

Giải pháp, do đó, là sử dụng authenticated encryption, có thể dễ dàng truy cập với libsodium, available on PECL.

Nếu bạn không thể vì bất kỳ lý do nào cài đặt phần mở rộng PECL, có hai thư viện PHP để chọn: defuse/php-encryptionzend-crypt. Cả hai đều cung cấp các tiêu chuẩn tuân thủ mã hóa xác thực và cả hai đều an toàn để sử dụng (cho những gì nó có giá trị, tôi thường xuyên thực hiện code audits for cryptography implementations trong PHP, tôi không phải là chỉ đơn thuần là một số người ngẫu nhiên trên internet).