2010-01-11 91 views
4

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

謝謝

+4

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

+0

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

+0

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

回答

3

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

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

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

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

+0

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

+0

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

+1

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

3

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

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

+0

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

+0

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

+0

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