十年網(wǎng)站開發(fā)經(jīng)驗 + 多家企業(yè)客戶 + 靠譜的建站團隊
量身定制 + 運營維護+專業(yè)推廣+無憂售后,網(wǎng)站問題一站解決
當今互聯(lián)網(wǎng)給人們的生活帶來便利的同時,也讓網(wǎng)絡安全、信息安全成為當下熱議的話題。比如,數(shù)據(jù)泄露問題或者密碼泄露問題都給大眾帶來了極大的擔憂。就密碼管理而言,如今許多公司都會制定密碼管理策略,但是在制定密碼管理策略時,會有哪些常見的問題也需要引起高度關注。

成都創(chuàng)新互聯(lián)公司是一家專注于成都網(wǎng)站設計、網(wǎng)站建設與策劃設計,富順網(wǎng)站建設哪家好?成都創(chuàng)新互聯(lián)公司做網(wǎng)站,專注于網(wǎng)站建設十多年,網(wǎng)設計領域的專業(yè)建站公司;建站業(yè)務涵蓋:富順等地區(qū)。富順做網(wǎng)站價格咨詢:18980820575
雖然現(xiàn)在身份驗證技術已經(jīng)更加成熟,但是密碼仍然是保護我們最敏感信息的主要途徑。密碼是防御潛在入侵者試圖模仿另一個用戶的第一道防線,但這樣的防護往往比較弱。用戶通常想創(chuàng)建易于記憶的密碼,使用出生日期或紀念日,甚至寫下來。開發(fā)人員則想盡可能少地投入密碼管理策略中。畢竟,研發(fā)新功能比密碼管理和存儲更令人興奮、更有趣。
許多密碼本身安全性非常弱,很容易猜得到,攻擊者就會有機可乘。最糟糕的是,我們信任的密碼存儲系統(tǒng)和其它關鍵信息的系統(tǒng)也面臨著許多安全挑戰(zhàn)。黑客會反復嘗試密碼數(shù)據(jù)庫進行盜竊,攻擊者同伙經(jīng)常會破壞那些保護數(shù)據(jù)的模式。
我們探討一下公司在密碼管理策略方面做出的一些常見錯誤。讓在下面的討論中,我們將提到“在線攻擊”和“離線攻擊”。在線攻擊是對應用程序登錄頁面的攻擊,攻擊者試圖猜測用戶的密碼;離線攻擊是攻擊者獲取密碼數(shù)據(jù)庫副本,并嘗試計算存儲在其中的用戶密碼的攻擊。
您已限制用戶可以使用的字符數(shù)量或種類
但是SQL注入、跨站點腳本,命令注入和其它形式的注入攻擊呢?如果遵循密碼存儲最佳做法,您將在收到密碼后立即計算密碼的哈希值。然后,您將只處理哈希密碼,不必擔心注入攻擊。
您在使用密碼組合規(guī)則
您沒有安全地存儲密碼
存儲密碼的常用方法是使用加密哈希函數(shù),對密碼進行哈希處理。如果最終用戶選擇完全隨機的20+字符密碼,這種方法將是完美的。例如密碼設成:/K`x}x4%(_.C5S^7gMw)。不幸的是,人們很難記住這些密碼。如果簡單地對密碼進行哈希處理,則使用彩虹表攻擊就很容易猜到用戶選擇的典型密碼。
阻止彩虹表攻擊通常需要在對每個密碼進行散列之前添加隨機“鹽”?!胞}”可以與密碼一起存儲在清除中。不幸的是,加鹽的哈希并沒有多大幫助。 GPU非常擅長快速計算加鹽哈希值。能夠訪問大量加鹽哈希和GPU的攻擊者將能夠使用暴力破解和字典攻擊等攻擊合理且快速地猜測到密碼。
有太多不安全的密碼存儲機制,值得專門寫篇文章去探討。不過,我們先來看看您應該如何存儲密碼。
為了使哈希計算更加昂貴,請使用自適應哈希函數(shù)或單向密鑰派生函數(shù),而不是密碼哈希函數(shù)來進行密碼存儲。加密哈希函數(shù)的一個特性是它們可以被計算出來;這個屬性導致它們不適合用于密碼存儲。攻擊者可以簡單地猜測密碼并快速散列以查看生成的哈希值是否與密碼數(shù)據(jù)庫中的任何內(nèi)容匹配。
另一方面,自適應哈希函數(shù)和單向密鑰導出函數(shù)具有可配置的參數(shù),這些參數(shù)可用于使哈希計算更加資源密集。如果使用得當,它們可以有助于充分減緩離線攻擊,以確保您有時間對正在受到攻擊的密碼數(shù)據(jù)庫做出反應。
這種方法的問題在于,每次要對用戶進行身份驗證時,都必須自己計算這些哈希值。這會給服務器帶來額外負擔,并可能使應用程序更容易受到DoS(拒絕服務)攻擊。
或者,您可以添加一些不可猜測的密碼哈希值。例如,如果要生成一個長隨機密鑰,將其添加到密碼哈希值以及唯一的隨機鹽,并且穩(wěn)妥地保護密鑰,那么被盜密碼數(shù)據(jù)庫對攻擊者來說將毫無用處。攻擊者需要竊取密碼數(shù)據(jù)庫以及能夠使用離線攻擊計算出用戶密碼的密鑰。當然,這也產(chǎn)生了一個需要解決的非常重要的密鑰管理問題。
您完全依賴密碼
此外,用戶成為網(wǎng)絡釣魚攻擊的受害者,因為一些用戶無論密碼要求如何都會選擇安全性弱的密碼,等等。
如果必須僅使用密碼進行身份驗證,用戶則還必須采取某種類型的設備身份驗證。這可能涉及設備/瀏覽器指紋識別,檢測用戶是否從不尋常的IP地址登錄,或類似的方式。
結論
如您所見,處理用戶密碼時需要考慮很多事項。我們還沒有談到密碼輪換策略、帳戶鎖定、帳戶恢復、速率限制,防止反向暴力攻擊等等。
有一個很重要的問題需要考慮:您是否可以將用戶身份驗證轉給其他人?如果你是一家金融機構,答案可能是否定的;如果您要把最新的貓咪寵物視頻給別人看,在此之前需要驗證,那這種情況下答案應該是可以的;如果您正在開發(fā)面向企業(yè)員工內(nèi)部使用的應用程序,請考慮基于SAML的身份驗證或LDAP集成;如果您正在開發(fā)面向公眾的應用程序,請考慮使用社交登錄(即使用Google,F(xiàn)acebook等登錄)。許多社交網(wǎng)站已經(jīng)投入大量精力來保護其身份驗證機制,并為用戶提供各種身份驗證選項。您不需要全盤重來。
在不必要的情況下實施用戶身份驗證會給企業(yè)和用戶都帶來麻煩,甚至有潛在危險。創(chuàng)建安全的用戶驗證機制困難且耗時??赡钦娴南胍幚肀槐I用的密碼數(shù)據(jù)庫,還是攻擊者在身份驗證機制中發(fā)現(xiàn)漏洞?而且用戶有更重要的事情要做,而不是記住另一個密碼!