是否需要密碼輸入消毒？

我試圖通過確保數據對特定字段有效（例如名稱不能包含特殊字符/數字等）來清理輸入的任何數據。但是，我不確定在什麼時候該做什麼它來到一個密碼字段。我甚至需要打擾任何消毒，因爲密碼只是散列？如果用戶通過密碼文本框注入任何惡意內容，我是否應該檢查任何可疑內容？ AFAIK，一些用戶可能（應該）具有特殊字符，如'<>'，這通常會觸發潛在的攻擊警報。我應該只保留密碼字段的unsanitized？限制密碼輸入對我來說是最後的選擇，因爲我覺得用戶應該在他們的密碼中使用各種各樣的字符。是否需要密碼輸入消毒？

謝謝

來源

2010-01-11 XSL

謝謝你考慮這件事，並做正確的事（tm）。我非常厭倦網站，將您限制爲特定字符集或僅限10個字符或更少。是的，我正在談論白癡的銀行網站。 – NotMe 2010-01-11 21:56:16

大聲笑，我知道你的意思。我仍然沒有看到一個有效的理由來阻止用戶的密碼。 – XSL 2010-01-11 23:21:06

這可能是值得禁止（但可能不會剝離）一些字符。例如控制字符，雖然有些人習慣把製表符放在UNIX密碼中（我相信）。 – 2010-01-11 23:29:08

只要你在應用程序中散列它，你應該沒問題。

一點題外話考慮您正在使用asp.net，但如果你正在使用PHP和MySQL做這樣一個值得注意的例外，這將是：

UPDATE users SET password = PASSWORD('$pwd') WHERE userid = $uid

在這種情況下，你會想先清理$ pwd。

來源

2010-01-11 21:53:21

感謝您的回覆。我正在使用ASP.NET會員控制來完成所有這些操作，所以希望我不必進行任何手動密碼更改。因此，只有散列纔會被存儲，我猜這意味着沒有威脅。 – XSL 2010-01-11 23:22:59

在PHP \ MySQL的情況下，爲什麼需要清理$ pwd，如果它被哈希？ – Ubeogesh 2017-09-29 13:35:32

@Ubeogesh $ pwd不被散列。 MySQL中的PASSWORD（）函數爲你散列。也就是說，我不推薦使用MySQL的PASSWORD函數，因爲有更好的密碼散列可供選擇。 – 2017-09-29 19:50:10

如果您擔心SQL注入攻擊，則應該開始使用參數化查詢與數據庫交互。因爲確定密碼的有效字符是一個商業規則，所以我不會剝奪任何東西，而我的客戶不會這樣說。

所有其他輸入都應進行消毒，因爲它們也可能會顯示在您的頁面輸出中，並可能導致XSS攻擊。

來源

2010-01-11 21:53:59

嗨。我正在使用ASP.NET控件來允許用戶註冊和更改密碼，所以我相信查詢會自動進行參數化。我在UserCreated事件之前手動清理其他輸入，但密碼輸入可能會被編碼，從而更改實際密碼。（例如<成爲＆lt）。 – XSL 2010-01-11 23:25:35

底線是：它不重要，因爲它總是會取代<由< – 2010-01-11 23:28:14

這是一個公平點，只要我在項目上工作，沒關係。我只是想從長遠來看，如果項目易手，其他開發人員可能會開始直接與密碼進行交互，而不是使用可能導致混淆的相同方法對其進行編碼。雖然這是不太可能的，但我喜歡在謹慎的方面犯錯。 – XSL 2010-01-11 23:32:09

是否需要密碼輸入消毒？

回答

相關問題