2009-07-17 127 views
12

也許標題是措辭嚴厲,但想不出更好的表達方式。使用AJAX發送純文本密碼有多安全?

我目前在登錄系統上工作(沒有正式的,只是試驗),並計劃使用PHPLiveX(一個AJAX庫)的一些功能。基本上你創建了一些PHP函數,然後通過JavaScript調用。您可以將參數(getElementById)添加到傳遞到PHP函數的JavaScript中。

我真正想知道的是,只要先調用JavaScript函數而不先加密密碼,然後讓PHP函數加密它(本例中是SHA256),是否安全。可以通過AJAX傳輸的數據被攔截嗎?如果是這樣的可能性有多大?

+0

除了使用SSL之外,什麼是保證這一點的最佳方式?如果可以在JavaScript中加密密碼,這是一個可重用的解決方案嗎? – j82374823749 2009-07-17 19:15:29

+1

如果在JavaScript中對密碼進行哈希處理,那麼任何嗅探流量的人都會看到它(它只會被哈希)。攻擊者可以使用哈希密碼來重播此請求 – 2009-07-17 19:27:13

+0

而SSL將解決此問題? – j82374823749 2009-07-17 19:31:03

回答

45

沒有更多或小於由瀏覽器發出的正常HTTP POST請求的安全(如在從<form>

「修復」爲這是相同的「固定」用於非AJAX請求 - 使用SSL。

1

AJAX調用只是簡單的HTTP請求。

它的行爲像普通的HTTP請求,並且還帶有它的所有優點和缺點。它並不安全。

爲了讓您的AJAX調用安全,有幾種方法可以嘗試:

  1. 使用SSL。 SSL將加密用戶和服務器之間的消息。 SSL的缺點是您必須爲有效的SSL證書支付額外費用。無效的SSL證書可用時,不會爲用戶提供相同級別的安全保證。
  2. 在客戶端發送之前加密請求。例如:在通過網絡發送之前散列用戶密碼。大多數情況下,您不需要用戶的純文本密碼。當用戶不允許運行客戶端腳本時,這是不可用的。
  3. 除了POST比GET更安全的常見誤導性信息之外,事實並非如此。兩者同樣對攻擊者開放。
7

無論您是通過AJAX還是通過正常形式發送密碼,它仍然通過HTTP POST(希望)請求發送。所以你沒有增加或刪除任何安全明智的。

防止某人攔截您的密碼的唯一方法是使用SSL(通過AJAX或不通過)。

1

這只是爲具有不SSL保護的登錄表單安全通過電話發送,就像幾乎所有的論壇一樣!

0

這是不安全的。不要發送未加密的密碼。很有可能他們會在某個時候被攔截,你會遇到重大問題。

這裏是一個捕獲telnet密碼的示例video。 Telnet以純文本形式發送,這很好地說明了如果你甚至想到這樣做的主要問題。任何兩位腳本kiddie都可以比你更快地截取純文本密碼。「哦,我的上帝,我的數據庫去了哪裏?」

1

確保您的AJAX調用的目標是受信任的HTTPS://頁面,並且您已將其與其他應用程序正在執行的相同信息的其他任何發送一樣安全。大多數庫/框架不會僅限於HTTP://用於您的AJAX調用。

0

你發送的是明文,所以任何有嗅探/收聽/等客戶端網絡的人都可以很容易地看到密碼。 AJAX調用只是一個普通的舊HTTP消息。如果你想看到這個動作,請激活一個wireshark的副本,並將請求發送給你自己。您將能夠在HTTP數據包中看到密碼。

1

是的,它可以被讀取。就像沒有某種安全層的所有其他東西一樣(請參閱SSL)

要像自己的AJAX命令一樣運行一個像WireShark這樣的工具。

可能性有多大?不是,但用戶的密碼可能會以純文本形式保存在某人的日誌文件中。如果有人最終找到了它,那麼這可能是個壞消息。回到大學,我的網絡課程可以使用一些(半)花式路由器。我們有我們在隨機網站上註冊帳戶的任務。正如我們所做的那樣,我們注意到了路由器中的日誌文件中的一些非常可怕的事情。這讓我大開眼界,想想如何跟蹤每個通信,並且很可能記錄在某個地方。

20

正如其他人所提到的,從表單發送HTTP帖子並沒有什麼更危險的。事實上,這是一回事。

但是,如果HTTPS不是一個選項,您可以始終在未加密的連接上使用質詢/響應方案。基本上它的工作原理是這樣的:

  • 服務器有一個用戶密碼的SHA(或其他散列算法)。
  • 客戶端有密碼。 (使用未加密的AJAX)服務器發送挑戰
  • 客戶端請求(字節的隨機字符串;字符都很好。)
  • 服務器創建一個挑戰,也是一個挑戰ID,並有過期保存它。
  • 客戶端收到挑戰和挑戰ID。
  • 客戶端使用SHA對密碼進行散列。
  • 客戶端通過以某種方式附加挑戰來散列生成的散列。
  • 客戶端發送挑戰ID(不是挑戰本身)和第二個結果散列。
  • 如果服務器存在且未過期,服務器將使用ID查找質詢。
  • 服務器將挑戰附加到存儲的密碼散列,並使用與客戶端相同的方案創建散列。
  • 服務器將其散列與客戶端進行比較。如果相同,則用戶通過身份驗證。

一旦你明白了,設置起來其實很簡單。 Wikipedia有一些額外的信息。

編輯:我發現我忘了提,認證是否是成功的,你必須刪除的挑戰,不管。讓客戶多次嘗試一個挑戰可能會導致安全問題。

0

如前所述,SSL是這裏最好的解決方案。但是,您可以在客戶端散列密碼。如果你是谷歌,你會發現大量的md5的JavaScript實現。

0

該死的你們讓我擔心。 SSL不能防止arp中毒MITM攻擊。像你們一樣崇拜SSL將是致命的。你必須有一種方法來加密客戶端的密碼,甚至一次跳躍,否則即使是新手黑客也能夠以明文方式截獲密碼。