2011-04-18 19 views
5

我想在用戶登錄時使用JavaScript加密用戶的密碼和用戶名(使用Ajax)。我知道存在幾個JavaScript不對稱加密庫。這是安全通信密碼的可行策略嗎?是否使用JavaScript進行不對稱加密?

我知道SSL存在,但這不是問題。

+0

感謝您的校對,Michael Petrotta;我想我的拼寫檢查器畢竟不是:) – 2011-04-18 15:08:33

+3

爲什麼你不使用HTTPS? – 2011-04-18 15:09:23

+1

@Alin Purcaru:問題已更新 – 2011-04-18 15:11:16

回答

3

否。如果攻擊者獲取密碼或加密密碼,兩者都發送到服務器「未加密」,則不會有任何區別,因此可以使用加密密碼進行登錄。

JavaScript不能用於安全性。你有使用HTTPS。

+1

如果該加密算法是以私有化方法進行的,該怎麼辦? – GAgnew 2011-04-18 15:14:28

+1

爲什麼這一定是這種情況?如果我安裝了一個SHA1庫(例如:http://pajhome.org.uk/crypt/md5/sha1),該怎麼辦?HTML),並只通過網絡發送密碼散列?如果這是不安全的,那麼不存儲SHA1哈希數據庫不安全? – 2011-04-18 15:16:06

+0

如果加密數據包包含時間戳,則會限制加密密碼有效的時間。更好的辦法是首先向服務器請求一個在加密之前添加到密碼中的令牌,每個令牌只能使用一次。 – 2011-04-18 15:16:16

1

我不認爲你會從這樣做中獲得很多收益,當然這比JavaScript這樣一個數學密集的部分所強加的性能要少。如果您在通過HTTP將數據發送到服務器之前使用它來加密一段數據,那麼儘管您會保護黑客確切地發現密碼,但是您不會阻止他們通過簡單訪問用您發送的同一條加密數據運行重播攻擊。

保護表單提交的唯一可行方法是使用HTTPS。我知道設置HTTPS是一件麻煩事,證書只能在一個域中運行,但是如果信息確實非常重要,那麼與嘗試使用JavaScript進行加密相比,這是一個更好的投資時間。

+0

JavaScript中的數學實際上已經很快了,JavaScript被認爲是很慢的,因爲它通常與難以抽象和複雜的DOM操作過程有關。請參閱[本演示](http://bitwiseshiftleft.github.com/sjcl/demo/)(對稱加密)。 – 2012-03-06 20:00:48

1

該模型仍然存在問題,因爲您仍然只是在連接上傳遞文本。如果沒有加密/解密/比較過程中的某個日期,您仍然有可能發生重播攻擊。即使超出仍然普遍存在的中間人攻擊,你仍然會有這樣一個事實:你的加密算法和公鑰將會在那裏。如果有人想獲得一個加密密碼,他們就會有一個永久性的來源,從而輕而易舉地強制該密碼。

5

第一步:不要相信互聯網上的人,我會提出一個弱的算法來確保我能打破它。

第二步:不要設計自己的算法,或實現任何人在生產系統中,直到你在計算機安全PHD

加密是不夠的,以防止重放攻擊,如果攻擊者獲得加密的密碼,如果它足以進行身份​​驗證,那麼對於他們來說,它就像未加密的密碼一樣有用。

我建議:

  1. 用戶輸入有密碼
  2. 客戶端請求從服務器令牌
  3. 服務器返回一個唯一的隨機令牌,並將其存儲對用戶會話(按Cookie存儲在鍵控服務器)
  4. 客戶端使用您的公鑰加密密碼+令牌並將其傳遞給服務器。
  5. 服務器使用您的私鑰對此進行解密,並檢查與此會話相匹配的令牌,之前沒有使用過,並且之前沒有使用過30秒。
  6. 服務器檢查密碼的散列值與存儲在數據存儲區中的用戶密碼的散列值相匹配。

傳輸的所有數據仍然可見,所以用戶不會獲得任何隱私(就像在https中那樣)。您的加密算法,加密實施和公鑰將公開。對於大量當前的密碼學來說就是這種情況,大量的算法被設計爲在攻擊者知道這一點的情況下是安全的。

這不會防止任何鍵盤記錄程序或間諜軟件攻擊,因爲它們將在密碼加密之前進行目標鎖定。

我不知道在JavaScript中實現的非對稱加密的實現,但沒有什麼根本不安全的方法。

+0

30秒?如果我必須查看我的密碼,因爲我使它變得如此強烈,我不記得它的內心呢? – 2011-04-18 15:35:21

+1

所以,根據你的第一點,我應該相信你提出的系統嗎? – 2011-04-18 15:35:53

+0

@SimpleCoder Nope :)我有一個興趣不安全感,我相信這會讓它更安全,但我只是邪惡的鮑勃欺騙你。我認真地說,我相信我說的是正確的,但是你只有我的話,而且我可能弄錯了。 – 2011-04-18 15:41:23

4

您可以使用諸如Secure Remote Password protocol之類的算法來提供您知道密碼的零知識證明。竊聽者將無法使用它來複制您的登錄信息。但是,要小心一個積極的攻擊者,用直接向他發送密碼的東西替換你的Javascript代碼。

有SRP的幾個JavaScript實現:

0

如果你從一開始非認證通信你的風險是始終中間人-中間。

無論如何,傳輸一個密碼是總是比傳輸明文密碼要好。因爲可能你的登錄系統很弱,但至少你沒有分享用戶的密碼(可以與另一個系統共享,可能用於銀行帳戶

此外,不要存儲該值,但不要再存儲該值。

如果您還使用非對稱加密,您可以添加防止竊聽的保護。但是,不要反對中間人。

相關問題