受JavaScript密碼保護的網站

Question

我有一個簡單/愚蠢或不是:)的問題。 換句話說，我不知道是否公平或完全是愚蠢的想法。 只是一些自由的想法。

如果我通過JavaScript進行登錄（如果我知道的話），那會怎么樣，但是安全哈希算法會通過密碼。 例如：

我生成一個SHA的傳遞，看起來像

var = 0xc1059ed8... //etc

並粘貼到代碼中。 還有兩個功能。 一個將比較兩個值（由我與用戶給出），第二個將生成sha形式用戶的輸入。

這在理論上是否安全，或者這是一個可怕的模式和愚蠢的想法？ JS能處理嗎？

編輯：我並不是說像銀行一樣嚴重認證。 就在我有我的照片並且只想要幾個人看他們的時候，地球上99.9％的人不能看他們:) thx for responses

Answer 1

抱歉，沒有骰子:)單獨使用客戶端Javascript無法進行安全身份驗證，因為可能會偽造正面身份驗證結果。 您將始終需要服務器端實例進行身份驗證。

Answer 2

常見的答案是“不，你不能做客戶端身份驗證”和正確的傳統方案，但我可以想到至少兩種方法使它工作：

1. 使用SHA密碼哈希重定向到靜態HTML頁面（0xc1059ed8 ... html）。 只要虛擬目錄不允許文件列表，就沒有人能夠猜出要保護的文件的名稱。 雖然這很快就笨拙了。

2. 在Javascript中使用加密算法（AES等）的實現來解密構成頁面實際內容的文本塊。 真的只適用於一個非常有價值的頁面。

服務器端身份驗證確實是最好的，但是說客戶端無法完成是不正確的。

Answer 3

您無法單獨使用Javascript來保護您的網站。 您需要某種方法來驗證服務器上的請求。

因為您的網站的所有消費者都清楚地看到您的所有JavaScript代碼。 潛在的攻擊者需要做的就是查看您網站的源名，他們可以繞過您的javascript的密碼檢查位並查看其背后的內容。

您需要在服務器端實施安全性，期限結束。 ASP.NET有一種內置的方法來執行此操作，稱為“表單身份驗證”。 或者你可以在php腳本中使用Session變量。

Answer 4

無論如何，你的JS源都是可見的，任何人都可以輕易偽造它。 您必須進行服務器端驗證

Answer 5

由於哈希將駐留在用戶的計算機上（在瀏覽器中），我會說這是一個糟糕的主意。 操縱它很容易。

Answer 6

您可以使用此類模式通過純文本鏈接隱藏密碼，並避免https登錄，但不能保持原樣。

問題是攻擊者可以竊取散列密碼並使用它來登錄服務器，她不需要真正的密碼。

這可以通過質詢響應來阻止，其中服務器向頁面發送“鹽”：隨機密碼與密碼混雜然后散列，因此響應總是不同的。

不幸的是，這有效的是服務器現在需要有明文密碼，這是一個壞主意（好吧，這有一些技巧）。 所以你可能不得不最終發送一個鹽，哈希你的密碼，通過哈希再次哈希並將其發送到服務器來混淆哈希值。 服務器使用salt對用戶數據庫中存儲的密碼哈希值進行哈希處理並對兩者進行比較。

隨着安全問題變得越來越復雜，在復雜的事情中潛伏着壞人。 更多地使用經過良好測試的模式，具有經過驗證的跟蹤記錄的算法以及精心實施這些模式的庫的原因。

無論如何，它將是服務器hwo最后說誰可以訪問。

Answer 7

你最好不要嘗試進行身份驗證 - 至少那樣你就不會給任何人帶來危險的錯覺，即所涉及的內容可能是安全的。

假設您正在處理共享秘密情況，身份驗證非常簡單。 您使用相當簡單的質詢 - 響應算法。 基本上，客戶端向服務器發送一條消息，說它要登錄。服務器通過發回一個隨機數來響應。 客戶端使用正確的密碼加密該隨機數，然后將其發回。 服務器自身加密隨機數，並將結果與​​客戶端發送的結果進行比較。 如果匹配，則驗證成功 - 您已確認客戶端具有正確的密碼。

這樣做的好處是：首先，密碼本身永遠不會以任何形式通過網絡發送，因此攻擊者在嘗試發現密碼時幾乎沒有任何材料可用。 其次，由於服務器為每次登錄生成新的隨機數，因此攻擊者無法通過重新發送從先前登錄中捕獲的數據包來成功進行身份驗證。

幾乎所有對安全有任何期望的服務器都已經內置了類似的內容。這純粹是設置客戶端與您關心的服務器支持的表單正確交互的問題。