簡單的加密和解密使用PHP

我的PHP應用程序使用的URL像這樣：簡單的加密和解密使用PHP

http://domain.com/userid/120 
http://domain.com/userid/121

鍵和URL的末尾基本上是MySQL數據庫表的主鍵。

我不希望這個增加的數字是公開的，我也不希望有人能夠通過交互Id來抓取用戶配置文件。

所以我想加密這個ID用於顯示的方式，我可以很容易地再次解密它。字符串不應該變得更長。

什麼是最好的加密方法？

來源

2010-12-13 norwald2

我會建議在url中使用用戶名，例如http://domain.com/user/jsmith。這是更多的Web 2.0，你保持你的主鍵的祕密，你不會通過加密/解密主鍵超載服務器 – aletzo 2010-12-13 14:19:55

我真的想抵制說*你做錯了*的衝動。首先，誰在乎用戶配置文件是否可以被抓取？谷歌無論如何都會發現它們，所以沒有什麼真正的辦法可以阻止它將它們放在登錄頁面後面（即使這樣，有人希望信息也能得到它）。其次，爲什麼在網址中使用ID？爲什麼不使用唯一的用戶名（用戶名是唯一的，不是嗎？）？它提供了比數字更多的語義含義，並且效率不應該低得多（假設你在用戶名列中設置了'UNIQUE'）... – ircmaxell 2010-12-13 14:22:21

模糊URL永遠不會保護它。它使閱讀變得更難，但操作起來並不困難。你可以使用十六進制數字表示或類似的東西來掩蓋它。這些誰可以讀取十六進制可以改變你的URL在幾秒鐘，反正：

$hexId = dechex($id); // to hex 
$id = hexdec($hexId); // from hex

來源

2010-12-13 14:17:05 jwueller

一個更好的方法（從可用性和SEO的角度來看）是使用一個獨特的詞組，而不是模糊的ID。在這種情況下，用戶的用戶名似乎是理想的解決方案，並且也是不可猜測的。也就是說，如果你不想使用這種方法，你可以使用用戶的用戶名的散列（可能爲md5），這些用戶名將存儲在數據庫中以及其他詳細信息中。因此，您可以直接在該領域進行查詢。（即：具有加密和解密的URL的一部分可能是矯枉過正。）

來源

2010-12-13 14:19:35

-1

生成每個用戶的唯一的字符串，並在網址

http://domain.com/user/ofisdoifsdlfkjsdlfkj，而不是用它http://domain.com/userid/121

來源

2010-12-13 14:19:49 user187291

簡單模糊： Base64使用base64_encode對它們進行編碼。
現在，您的http://domain.com/userid/121變爲：http://domain.com/userid/MTIx
想要了解更多信息，請再次添加一些字母。

堅韌模糊：使用任何使用MCrypt庫的加密方法。

來源

2010-12-13 14:20:54 shamittomar

你會如何區分簡單和難以加密的加密？ – 2010-12-13 14:23:53

@Sandeepan，Simple很容易解密，並且不使用密鑰，但是難以解密。 – shamittomar 2010-12-13 14:25:27

您如何區分易於解密和難以解密？ ;-) – 2010-12-13 15:00:21

最簡單但功能強大的加密方法：與密鑰異或。 http://en.wikipedia.org/wiki/XOR_cipher 沒有實際的性能下降。

Base64表示不是加密！這是另一種說法。

希望這會有所幫助。

來源

2010-12-13 14:21:40 hmassad

謝謝你的base64評論，這不是一個加密。這需要說！ – 2016-05-11 11:34:07

-1

可以使用base64_encode和base64_decode功能加密和解密您的網址

來源

2010-12-13 14:21:51 Chandresh

+1來平衡誰給你反對票的人。你的答案並不是一個錯誤 – 2010-12-13 14:34:52

downvote不是我的，但是base64_（en | de）代碼不是（en | de）加密。它會稍微掩蓋身份證號碼，但以可預測的方式。 – Aether 2010-12-13 14:45:34

base64不進行加密，任何開發人員都將輕鬆識別並能夠解密該值，從而能夠抓取頁面。 – JohnSmith 2010-12-13 14:58:58

你有多種選擇這裏：

生成並存儲在數據庫中的標識符。這很好，因爲你可以擁有保證唯一的可讀密鑰。這很糟糕，因爲它會導致數據庫模式更改，並且每次要生成鏈接時都必須實際查詢該表。
運行實際的基於密鑰的加密，例如基於PHP的MCrypt。您可以訪問功能強大的加密算法，但大多數安全算法傾向於輸出比您期望的時間長得多的字符串。異或做你想要的，但它不阻止訪問順序值（並且鑑於關於數字的先驗知識，關鍵字很容易確定）。
運行基於散列的驗證：而不是使用121爲您的標識，使用121-a34df6其中a34df6是121的md5（或其他HMAC）和密鑰的前六個字符。您將提取121並重新計算六個字符，而不是解碼，以查看它們是否與用戶發送的內容匹配。這並不隱藏121（它仍然在連字符之前），但不知道密鑰，訪問者將無法生成六個字符來實際查看編號爲121的文檔。
在混洗中使用XOR：將30位標識符中的位進行混洗，然後應用XOR。這使得XOR難以識別，因爲洗牌模式也被隱藏起來。
使用XOR與按需鍵：使用fb37cde4-37b3爲你的鑰匙，其中第一部分是121和md5('37b3'.SECRET)的XOR（或生成基於37b3的XOR密鑰和私密的另一種方式）。

不要使用BASE64，很容易進行反向工程：如果MTIx是121，然後MTIy是122 ...

最終，你將不得不接受您的解決方案將是不安全的：用戶不僅可以泄漏有效的URL（通過瀏覽器歷史記錄，HTTP引用程序或將它們發佈到Twitter上），而且您要求標識符適合少量字符，這意味着可能會發生暴力攻擊（並且隨着您開始擁有更多文檔變得更容易）。

來源

2010-12-13 14:43:36

我可能會說，爲每個用戶創建一個隨機字符串並將其存儲在數據庫中比使用散列獲得一個更好。如果你使用一個常見的哈希，它仍然是很容易遍歷所有頁面;-)

我會寫在評論中，但沒有代表它（但？）。

來源

2010-12-13 19:19:20 marcusklaas

當用戶點擊一個鏈接時，你不應該使用主鍵，你可以在會話中使用pkey並從該會話中獲取。請不要使用查詢字符串....

來源

2013-04-23 05:55:31

簡單的加密和解密使用PHP

回答

相關問題