9

我想製作一個用於學習目的的用戶登錄系統。我有幾個問題。實現用戶登錄系統的正確方法

我做了一些研究,發現實現用戶登錄系統的正確方法是記住數據庫中的用戶名/密碼和密碼的加密/散列版本。當用戶登錄時,客戶端代碼將通過MD5或SHA-1或類似方式加密密碼,然後將此加密密碼發送到服務器端,然後將其與數據庫中的密碼進行比較。如果它們匹配,則用戶登錄成功。

這種實現方式可以防止數據庫管理員或程序員在數據庫中看到密碼的真實文本。它還可以防止黑客在互聯網上傳輸過程中攔截真正的密碼。但是,我有一些我不明白的東西。

  1. 我的第一個問題是,如果黑客知道密碼的哈希/加密版本(由黑客數據庫)或數據庫管理員,程序員通過只是簡單地看到在數據庫中的文本獲得密碼的哈希版本,那麼他們可以很容易地創建一個程序,將這個散列版本的密碼發送到服務器端,然後進行比較,然後成功登錄。如果他們能這樣做,加密密碼似乎沒有用。我想我在這裏誤解了一些東西。

  2. 第二個問題是,這是(我上面描述的方式)在當前行業中實現用戶登錄功能的最流行和最恰當的方式?我是否必須手動執行所有操作,或者某些數據庫是否有一些內置功能來執行相同的操作?有沒有最常見的方式/方法爲用戶登錄網站或Web應用程序?如果是這樣,請給我提供一些細節。

  3. 我以前的公司使用couchDB存儲用戶登錄信息,包括密碼。他們沒有太多關於加密的東西。他們說couchDB會自動加密密碼並將其保存在文檔中。我不確定這是否安全。如果是這樣,那麼對於程序員來說非常方便,因爲它可以節省大量工作。

  4. 這種方式(點3)足夠安全的正常使用?像mySQL這樣的其他數據庫系統有這種能夠做同樣事情的能力嗎?如果是這樣,是否意味着使用mySQL內置方法足夠安全?

我不是在尋找一種非常安全的方式來實現用戶登錄功能。我正在尋找一種適用於大多數網絡應用程序的流行,易於實施,適當和安全的方式。請給我一些建議。提供的細節將非常感激。

回答

4

一些澄清:

  1. 不要使用MD5。它被認爲是壞的。使用SHA,但我會推薦一些比SHA1更好的東西。 - https://en.wikipedia.org/wiki/MD5
  2. 您沒有提到任何有關醃製密碼的信息。這對保護彩虹桌非常重要。 - https://en.wikipedia.org/wiki/Rainbow_tables
  3. salting/hashing密碼的想法並不真正保護您自己的應用程序。這是因爲大多數用戶都有一些用於多個站點的密碼。散列/醃製可以防止任何獲得數據庫訪問權限的人知道這些密碼是什麼,並使用它們登錄到他們的銀行應用程序或類似的東西。一旦有人獲得了對數據庫的直接訪問,您的應用程序的安全性已經完全受到影響。 - http://nakedsecurity.sophos.com/2013/04/23/users-same-password-most-websites/
  4. 不要使用數據庫的內置安全性來處理登錄。這很不好,給了他們更多的應用程序訪問權限。使用一張桌子。
  5. 你沒有提到有關SSL的任何信息。即使設計良好的認證系統也是無用的,如果密碼以明文形式通過線路發送的話。還有其他方法,如質詢/響應,但不幸的是,當用戶註冊或更改密碼時,密碼仍然必須以純文本發送到服務器。 SSL是防止這種情況的最佳方式。
8

當用戶登錄時,客戶端代碼將通過加密MD5或SHA-1或類似的東西的密碼,然後發送該加密的密碼到服務器端,然後將其與一個數據庫進行比較。如果它們匹配,則用戶登錄成功。

不,客戶端需要發送不帶密碼的密碼。如果你在客戶端散列密碼,那麼這個散列就是密碼。這將使密碼散列的安全性無效。散列必須在服務器一側完成。

爲了保護傳輸中的明文密碼,它需要通過安全通道(如加密的TLS(SSL)連接)發送。


密碼應鹽醃用一塊額外數據是爲每個帳戶不同。通過消除明文和散列之間的直接相關性,鹽分抑制了彩虹桌攻擊。鹽不需要保密,也不需要非常大。即使4個隨機字節的鹽也會使彩虹表攻擊的複雜性增加40億倍。


行業的黃金標準,現在是Bcrypt。除了醃製之外,bcrypt還通過設計減速因子來進一步提高安全性。

除了包含鹽,以防止彩虹表攻擊,bcrypt是一種自適應功能:隨着時間的推移,迭代次數可以增加,使其更慢,所以它仍然有抗性的增加窮舉搜索攻擊,甚至計算能力....在密碼學理論上,這並不比標準的Blowfish密鑰計劃更強大,但更新密鑰回合的數量是可配置的;這個過程因此可以任意慢,這有助於防止對散列或鹽的暴力攻擊。

+0

如果系統會使用公開密碼散列密碼客戶端,然後用私有密鑰重新密碼服務器端(即存儲在服務器上的字符串或服務器端隨機生成的鹽) )?這樣,服務器永遠不會知道實際的純文本密碼,密碼的純文本版本在任何時候都不會被髮送到服務器供黑客獲取。我知道,一箇中間人仍然可以獲取密碼哈希值,並嘗試用javascript中的salt強制它,但是,它仍然會使他的生活變得更加困難,不是嗎? –

+0

如果客戶端向服務器發送散列密碼,那麼*哈希密碼*實際上就是真正的密碼。如果黑客截獲了散列密碼,他們可能會將其發送到服務器,而無需知道原始的未加密密碼,並且服務器會接受它。 –

+0

是的,但對於發送到服務器的純文本密碼也是如此。如果黑客攔截它,它可以簡單而簡單地使用它來登錄帳戶。然而,如果明文密碼被散列,如果黑客截獲該密碼,他只能登錄到該特定網站,而不能登錄到客戶端可能擁有相同密碼的任何其他網站。 –