清理用戶密碼在散列它們并將它們存儲在我的數據庫中之前，我應該如何逃避或清除用戶提供的密碼？當PHP開發人員考慮出于安全目的而考慮哈希用戶的密碼時，他們往往會像使用任何其他用戶提供的數據一樣考慮這些密碼。這個主題經常出現在與密碼存儲相關的PHP問題中; 開發人員經常希望使用諸如escape_string()（在各種迭代中）等功能清理密碼htmlspecialchars()，addslashes()然后再對其進行散列并將其存儲在數據庫中。
2 回答
慕雪6442864
TA貢獻1812條經驗 獲得超5個贊
你應該永遠不會逃避，修剪或使用任何其他清理機制，你將使用PHP進行散列password_hash()，原因有很多，其中最大的一個是因為對密碼進行額外的清理需要不必要的額外代碼。
您將爭辯（并且您在用戶系統中接受用戶數據的每個帖子中都會看到它）我們應該清理所有用戶輸入，并且您對我們接受用戶的其他所有信息都是正確的。密碼不同。散列密碼不能提供任何SQL注入威脅，因為字符串在存儲到數據庫之前會變為散列。
散列密碼的行為是使密碼安全存儲在數據庫中的行為。散列函數對任何字節都沒有特殊含義，因此出于安全原因，不需要清理其輸入
如果您遵循允許用戶使用他們想要的密碼/短語的咒語，并且您不限制密碼，允許任何長度，任意數量的空格和任何特殊字符散列將使密碼/密碼安全無論內容中包含什么密碼。截至目前最常見的哈希值（默認值），PASSWORD_BCRYPT將密碼轉換為60字符寬的字符串，其中包含隨機鹽以及散列密碼信息和成本（創建哈希的算法成本）：
PASSWORD_BCRYPT用于使用CRYPT_BLOWFISH算法創建新的密碼哈希值。這將始終導致使用“$ 2y $”crypt格式的哈希值，該格式總是60個字符寬。
存儲哈希的空間要求會隨著不同的哈希方法添加到函數中而發生變化，因此最好在列類型上更大的存儲哈希值，例如VARCHAR(255)或TEXT。
您可以使用完整的SQL查詢作為您的密碼，它將被散列，使SQL引擎無法執行，例如，
SELECT * FROM `users`;
可以哈希到 $2y$10$1tOKcWUWBW5gBka04tGMO.BH7gs/qjAHZsC5wyG0zmI2C.KgaqU5G
讓我們看看不同的消毒方法如何影響密碼 -
密碼是I'm a "dessert topping" & a <floor wax>!（密碼末尾有5個空格，這里沒有顯示。）
當我們應用以下修剪方法時，我們會得到一些不同的結果：
var_dump(trim($_POST['upassword']));var_dump(htmlentities($_POST['upassword']));var_dump(htmlspecialchars($_POST['upassword'])); var_dump(addslashes($_POST['upassword']));var_dump(strip_tags($_POST['upassword']));
結果：
string(40) "I'm a "dessert topping" & a <floor wax>!" // spaces at the end are missing
string(65) "I'm a "dessert topping" & a <floor wax>! " // double quotes, ampersand and braces have been changed
string(65) "I'm a "dessert topping" & a <floor wax>! " // same here
string(48) "I\'m a \"dessert topping\" & a <floor wax>! " // escape characters have been added
string(34) "I'm a "dessert topping" & a ! " // looks like we have something missing
當我們發送這些內容時會發生什么password_hash()？它們都被散列，就像上面的查詢一樣。當您嘗試驗證密碼時，會出現此問題。如果我們采用這些方法中的一種或多種，我們必須在比較它們之前重新使用它們password_verify()。以下將失?。?/p>
password_verify($_POST['upassword'], $hashed_password); // where $hashed_password comes from a database query
在密碼驗證中使用結果之前，您必須通過您選擇的清理方法運行發布的密碼。這是一組不必要的步驟，并且會使哈希變得更好。
慕尼黑5688855
TA貢獻1848條經驗 獲得超2個贊
在對密碼進行散列之前，您應該按照RFC 7613第4節中的說明對其進行規范化。特別是：
附加映射規則：任何非ASCII空間的實例必須映射到ASCII空間（U + 0020）; 非ASCII空間是具有Unicode常規類別“Z”的任何Unicode代碼點（U + 0020除外）。
和：
規范化規則：Unicode規范化表格C（NFC）必須應用于所有字符。
這會嘗試確保如果用戶鍵入相同的密碼但使用不同的輸入法，則仍應接受密碼。
添加回答
舉報
0/150
提交
取消