security - 基於表單的網站身份驗證的權威指南




http authentication (8)

最終文章

發送憑據

100%安全地發送憑證的唯一實用方法是使用SSL 。 使用JavaScript來散列密碼是不安全的。 客戶端密碼散列的常見缺陷:

  • 如果客戶端和服務器之間的連接未加密,那麼您所做的一切都容易受到中間人攻擊 。 攻擊者可以替換傳入的javascript以打破散列或將所有憑據發送到他們的服務器,他們可以聽取客戶端響應並完美地模仿用戶等等。具有可信證書頒發機構的SSL旨在防止MitM攻擊。
  • 如果您不在服務器上執行其他冗餘工作,則服務器收到的散列密碼安全性較低

還有另一種稱為SRP的安全方法,但它已獲得專利(儘管它是免費許可的 )並且幾乎沒有可用的良好實現。

存儲密碼

不要將密碼作為純文本存儲在數據庫中。 即使您不關心自己網站的安全性也不會。 假設您的某些用戶將重複使用其在線銀行帳戶的密碼。 因此,存儲哈希密碼,並丟棄原始密碼。 並確保密碼不會顯示在訪問日誌或應用程序日誌中。 OWASP 建議使用Argon2作為新應用的首選。 如果不可用,則應使用PBKDF2或scrypt。 最後,如果以上都不可用,請使用bcrypt。

哈希本身也是不安全的。 例如,相同的密碼意味著相同的哈希 - 這使得哈希查找表成為一次破解大量密碼的有效方法。 相反,存儲鹽漬哈希。 salt是在散列之前附加到密碼的字符串 - 每個用戶使用不同的(隨機)salt。 salt是一個公共值,因此您可以將它們與哈希存儲在數據庫中。 有關詳細信息,請參閱here

這意味著您無法向用戶發送他們忘記的密碼(因為您只有哈希)。 除非您已對用戶進行身份驗證,否則請勿重置用戶的密碼(用戶必須證明他們能夠閱讀發送到存儲(和驗證的)電子郵件地址的電子郵件。)

安全問題

安全問題是不安全的 - 避免使用它們。 為什麼? 安全問題,密碼做得更好。 閱讀第三部分:@Jens Roland中 使用秘密問題在這個維基中回答這裡。

會話cookie

用戶登錄後,服務器會向用戶發送會話cookie。 服務器可以從cookie中檢索用戶名或id,但是沒有其他人可以生成這樣的cookie(TODO解釋機制)。

Cookie可能被劫持 :它們只能與客戶機器的其他部分和其他通信一樣安全。 它們可以從磁盤中讀取,在網絡流量中嗅探,由跨站點腳本攻擊解除,從中毒的DNS中刪除,以便客戶端將其cookie發送到錯誤的服務器。 不要發送持久性cookie。 Cookie應在客戶端會話結束時過期(瀏覽器關閉或離開您的域)。

如果要自動登錄用戶,可以設置持久性cookie,但它應與完整會話cookie不同。 您可以設置用戶已自動登錄的附加標誌,並且需要為真正的敏感操作登錄。 這對於希望為您提供無縫,個性化購物體驗但仍保護您的財務詳細信息的購物網站而言非常受歡迎。 例如,當您返回訪問亞馬遜時,他們會向您顯示一個看起來像您已登錄的頁面,但當您下訂單(或更改您的送貨地址,信用卡等)時,他們會要求您確認你的密碼。

另一方面,諸如銀行和信用卡之類的金融網站僅具有敏感數據,並且不應允許自動登錄或低安全性模式。

外部資源清單

基於表單的網站身份驗證

我們認為Stack Overflow不僅應該是非常具體的技術問題的資源,而且還應該是關於如何解決常見問題變化的一般指導原則。 “基於表單的網站身份驗證”應該是這種實驗的一個很好的主題。

它應包括以下主題:

  • 如何登錄
  • 如何退出
  • 如何保持登錄狀態
  • 管理cookie(包括推薦設置)
  • SSL / HTTPS加密
  • 如何存儲密碼
  • 使用秘密問題
  • 忘記用戶名/密碼功能
  • 使用nonces來防止跨站點請求偽造(CSRF)
  • OpenID
  • “記住我”複選框
  • 瀏覽器自動完成用戶名和密碼
  • 秘密URL(受摘要保護的公共URL
  • 檢查密碼強度
  • 電子郵件驗證
  • 還有更多關於 基於表單的身份驗證 ...

它不應包括以下內容:

  • 角色和授權
  • HTTP基本身份驗證

請幫助我們:

  1. 建議副主題
  2. 提交有關此主題的好文章
  3. 編輯官方答案

第一部分:如何登錄

我們假設您已經知道如何構建登錄+密碼HTML表單,該表單將值POST到服務器端的腳本以進行身份驗證。 下面的部分將討論聲音實用auth的模式,以及如何避免最常見的安全陷阱。

HTTPS還是HTTPS?

除非連接已經安全(即通過HTTPS使用SSL / TLS進行隧道傳輸),否則您的登錄表單值將以明文形式發送,這允許任何竊聽瀏覽器和Web服務器之間的線路的人都可以在通過時讀取登錄信息通過。 這種類型的竊聽是由政府定期完成的,但總的來說,除了這樣說之外,我們不會解決“擁有”的電話:如果您要保護任何重要信息,請使用HTTPS。

實質上,在登錄期間防止竊聽/數據包嗅探的唯一實用方法是使用HTTPS或其他基於證書的加密方案(例如, TLS )或經過驗證和測試的質詢 - 響應方案(例如, Diffie-Hellman基於SRP)。 竊聽攻擊者可以輕易地繞過任何其他方法

當然,如果你願意變得有點不切實際,你也可以使用某種形式的雙因素身份驗證方案(例如Google身份驗證器應用程序,物理“冷戰風格”代碼簿或RSA密鑰生成器加密狗)。 如果應用正確,即使使用不安全的連接,這也可以工作,但很難想像開發人員願意實現雙因素身份驗證而不是SSL。

(不)滾動自己的JavaScript加密/散列

鑑於在您的網站上設置SSL證書的非零成本和感知技術難度,一些開發人員傾向於推出他們自己的瀏覽器內哈希或加密方案,以避免通過不安全的線路傳遞明文登錄。

雖然這是一個崇高的想法,但它基本上是無用的(並且可能是一個安全漏洞 ),除非它與上述之一相結合 - 也就是說,要么使用強加密來保護線路,要么使用久經考驗的挑戰 - 響應機制(如果你不知道那是什麼,只要知道它是最難以證明的,最難設計的,也是最難實現的數字安全概念)。

雖然散列密碼可以有效防止密碼洩露 ,但它很容易受到重放攻擊,中間人攻擊/劫持(如果攻擊者在到達你的不受保護的HTML頁面之前可以注入幾個字節)瀏覽器,他們可以簡單地註釋掉JavaScript中的哈希),或者暴力攻擊(因為你正在向攻擊者發送用戶名,鹽和哈希密碼)。

CAPTCHAS反人類

CAPTCHAs旨在阻止一種特定類型的攻擊:自動字典/暴力破解試驗和錯誤,沒有人類操作員。 毫無疑問,這是一個真正的威脅,但有一些方法可以無縫地處理它,不需要CAPTCHA,特別是正確設計的服務器端登錄限制方案 - 我們稍後會討論它們。

知道CAPTCHA實現不是一樣的; 它們通常不是人類可以解決的,其中大多數實際上對機器人無效,所有這些都對廉價的第三世界勞動力無效(根據OWASP ,目前的血汗工廠率為每500次測試12美元),並且一些實施可能是在某些國家/地區技術上非法(請參閱OWASP身份驗證備忘單 )。 如果你必須使用驗證reCAPTCHA ,請使用谷歌的reCAPTCHA ,因為它定義為OCR-hard(因為它使用已經OCR錯誤分類的書籍掃描)並且非常努力地使用戶友好。

就個人而言,我傾向於發現CAPTCHAS很煩人,並且當用戶多次登錄失敗並且限制延遲時間最多時,將它們用作最後的手段。 這種情況很少能夠被接受,並且它會加強整個系統。

存儲密碼/驗證登錄

在我們近年來看到的所有高度公開的黑客攻擊和用戶數據洩漏之後,這可能最終是常識,但必須說明:不要在數據庫中以明文形式存儲密碼。 用戶數據庫通常會通過SQL注入被黑客入侵,洩露或收集,如果您要存儲原始明文密碼,那麼即時遊戲結束也是為了您的登錄安全性。

因此,如果您無法存儲密碼,如何檢查登錄表單中登錄的登錄名+密碼組合是否正確? 答案是使用密鑰派生函數進行散列。 無論何時創建新用戶或更改密碼,您都會獲取密碼並通過KDF(例如Argon2,bcrypt,scrypt或PBKDF2)運行密碼,將明文密碼(“correcthorsebatterystaple”)轉換為長而隨機的字符串,這在您的數據庫中存儲更安全。 要驗證登錄,請對輸入的密碼運行相同的哈希函數,這次傳入salt並將生成的哈希字符串與存儲在數據庫中的值進行比較。 Argon2,bcrypt和scrypt已經將哈希值與哈希一起存儲。 有關更多詳細信息,請參閱sec.stackexchange上的這篇article

使用salt的原因是因為散列本身是不夠的 - 你需要添加一個所謂的'salt'來保護散列不受彩虹表的影響 。 salt有效地防止兩個完全匹配的密碼被存儲為相同的哈希值,從而防止在攻擊者執行密碼猜測攻擊時在一次運行中掃描整個數據庫。

加密哈希不應該用於密碼存儲,因為用戶選擇的密碼不夠強(即通常不包含足夠的熵),並且密碼猜測攻擊可以在相對較短的時間內由訪問哈希的攻擊者完成。 這就是使用KDF的原因 - 這些有效地“拉伸關鍵”意味著攻擊者猜測的每個密碼都涉及多次迭代哈希算法,例如10,000次,使攻擊者的密碼猜測速度慢10,000倍。

會話數據 - “您以Spiderman69身份登錄”

一旦服務器針對您的用戶數據庫驗證了登錄名和密碼並找到匹配項,系統就需要一種方法來記住瀏覽器已經過身份驗證。 這個事實應該只存儲在會話數據的服務器端。

如果您不熟悉會話數據,可以使用以下方法:單個隨機生成的字符串存儲在過期的cookie中,用於引用存儲在服務器上的數據集合 - 會話數據。 如果您使用的是MVC框架,那麼這無疑已經得到了解決。

如果可能的話,確保會話cookie在發送到瀏覽器時設置了安全和僅HTTP標誌。 httponly標誌提供一些保護,防止XSS攻擊讀取cookie。 安全標誌確保cookie僅通過HTTPS發回,因此可以防止網絡嗅探攻擊。 cookie的值不應該是可預測的。 如果呈現引用不存在的會話的cookie,則應立即替換其值以防止會話固定

第二部分:如何保持登錄 - 臭名昭著的“記住我”複選框

持久登錄Cookie(“記住我”功能)是一個危險區域; 一方面,當用戶了解如何處理它們時,它們完全像傳統登錄一樣安全; 另一方面,它們在粗心用戶手中是一個巨大的安全風險,他們可能在公共計算機上使用它們而忘記註銷,並且可能不知道瀏覽器cookie是什麼或如何刪除它們。

就個人而言,我喜歡定期訪問的網站的持久登錄,但我知道如何安全地處理它們。 如果您確信您的用戶知道相同的內容,則可以使用持久登錄並保持良心。 如果不是 - 那麼,你可以贊同這樣的理念:如果用戶被黑客攻擊,那麼他們的登錄憑證不小心的用戶會自行處理。 這並不像我們去我們用戶的房子並撕下所有那些引人注目的Post-It筆記,上面還有他們在顯示器邊緣排列的密碼。

當然,有些系統無法承受任何帳戶被黑客攻擊; 對於這樣的系統,你無法證明持久登錄的合理性。

如果您決定實施持久登錄cookie,請按以下步驟操作:

  1. 首先,花些時間閱讀Paragon Initiative關於這個主題的文章 。 你需要正確地獲得一堆元素,而且這篇文章很好地解釋了每一個元素。

  2. 只是為了重申一個最常見的陷阱, 不要在你的數據庫中存儲持久的登錄COOKIE(令牌) ,只是它的一大堆! 登錄令牌是密碼等效的,因此如果攻擊者抓住您的數據庫,他們可以使用令牌登錄任何帳戶,就像他們是明文登錄密碼組合一樣。 因此,在存儲持久登錄令牌時,使用散列(根據https://security.stackexchange.com/a/63438/5002 ,弱散列將為此目的做好)。

第三部分:使用秘密問題

不要實施“秘密問題” 。 “秘密問題”功能是一種安全反模式。 閱讀MUST-READ列表中鏈接號4的論文。 在雅虎之後,你可以向Sarah Palin詢問這個問題。 電子郵件帳戶在之前的總統競選期間被黑了,因為她的安全問題的答案是......“Wasilla High School”!

即使有用戶指定的問題,大多數用戶也很可能會選擇:

  • 一個'標準'秘密問題,如母親的娘家姓或寵物

  • 一個簡單的瑣事,任何人都可以從他們的博客,LinkedIn個人資料或類似的東西

  • 任何比猜測密碼更容易回答的問題。 對於任何體面的密碼,您可以想像的每一個問題

總之,安全問題本質上在其所有形式和變體中都是不安全的,並且不應出於任何原因在認證方案中使用。

安全問題甚至存在於野外的真正原因是它們可以方便地節省來自無法訪問其電子郵件以獲得重新激活代碼的用戶的一些支持呼叫的成本。 這是以犧牲安全性和Sarah Palin的聲譽為代價的。 值得? 可能不是。

第四部分:忘記密碼功能

我已經提到為什麼你不應該使用安全問題來處理忘記/丟失的用戶密碼; 不言而喻,您絕不應該通過電子郵件向用戶發送他們的實際密碼。 在這個領域至少還有兩個需要避免的常見缺陷:

  1. 不要忘記的密碼重置為自動生成的強密碼 - 這種密碼非常難以記住,這意味著用戶必須更改密碼或將其寫下來 - 例如,在顯示器邊緣的亮黃色Post-It上。 不要設置新密碼,只需讓用戶立即選擇一個新密碼 - 這也是他們想要做的事情。 (例外情況可能是用戶普遍使用密碼管理器來存儲/管理通常無法記住的密碼而不將其寫下來)。

  2. 始終在數據庫中散列丟失的密碼代碼/令牌。 再次 ,此代碼是密碼等效的另一個示例,因此必須進行哈希處理,以防攻擊者抓住您的數據庫。 當請求丟失的密碼代碼時,將明文代碼發送到用戶的電子郵件地址,然後對其進行哈希處理,將哈希值保存在數據庫中 - 然後丟棄原始密碼。 就像密碼或持久登錄令牌一樣。

最後一點:始終確保用於輸入“丟失的密碼代碼”的界面至少與登錄表單本身一樣安全,或者攻擊者只是使用它來獲取訪問權限。 確保生成很長的“丟失密碼代碼”(例如,16個區分大小寫的字母數字字符)是一個良好的開端,但請考慮添加與登錄表單本身相同的限制方案。

第五部分:檢查密碼強度

首先,您需要閱讀這篇小文章進行實際檢查: 500個最常用的密碼

好吧,也許這個列表不是任何 地方 任何系統上最常見密碼的規範列表,但它很好地表明當沒有強制執行的策略時,人們會選擇密碼的能力有多差。 此外,當您將該列表與最近被盜密碼的公開分析進行比較時,該列表看起來非常貼近家庭。

因此:沒有最低密碼強度要求,2%的用戶使用前20個最常用的密碼之一。 含義:如果攻擊者只獲得20次嘗試,則您網站上50個帳戶中的1個將被破解。

阻止這一點需要計算密碼的熵,然後應用閾值。 美國國家標準與技術研究院(NIST) 特刊800-63提出了一系列非常好的建議。 當與字典和鍵盤佈局分析相結合時(例如,'qwertyuiop'是一個錯誤的密碼),可以在18位熵的水平上拒絕99%的所有選擇不當的密碼 。 簡單地計算密碼強度並向用戶顯示視覺強度計是好的,但是不夠。 除非強制執行,否則許多用戶很可能會忽略它。

為了獲得高熵密碼的用戶友好性,強烈建議使用Randall Munroe的密碼強度xkcd

第六部分:更多 - 或者:防止快速登錄嘗試

首先,看看數字: 密碼恢復速度 - 您的密碼會持續多長時間

如果您沒有時間瀏覽該鏈接中的表,請按以下列表列出:

  1. 即使你用算盤破解密碼,也幾乎沒時間破解弱密碼

  2. 如果它不區分大小寫 ,則幾乎沒有時間破解字母數字9個字符的密碼

  3. 如果長度小於8個字符 ,則幾乎沒有時間破解複雜的符號和字母和數字大小寫密碼(台式PC可以搜索整個密鑰空間,最多7個字符)幾天甚至幾小時的問題)

  4. 但是, 如果每秒限制為一次嘗試那麼即使是6個字符的密碼也需要花費大量的時間

那麼我們可以從這些數字中學到什麼呢? 好吧,很多,但我們可以專注於最重要的部分:阻止大量快速連續登錄嘗試(即暴力攻擊)的事實並不那麼困難。 但是, 正確防止它並不像看起來那麼容易。

一般來說,您有三種選擇可以有效抵禦暴力攻擊(以及字典攻擊,但由於您已經採用了強密碼策略,因此它們應該不是問題)

  • 在N次嘗試失敗後出現一個CAPTCHA (令人討厭並經常無效 - 但我在這裡重複自己)

  • 在N次嘗試失敗後鎖定帳戶並要求電子郵件驗證(這是等待發生的DoS攻擊)

  • 最後, 登錄限制 :也就是說,在N次失敗嘗試之後設置嘗試之間的時間延遲(是的,DoS攻擊仍然可能,但至少它們的可能性要小得多,而且更難以完成)。

最佳實踐#1:短時間延遲隨著失敗嘗試次數的增加而增加,例如:

  • 1次失敗嘗試=沒有延遲
  • 2次失敗嘗試= 2秒延遲
  • 3次失敗嘗試= 4秒延遲
  • 4次失敗嘗試= 8秒延遲
  • 5次失敗嘗試= 16秒延遲
  • 等等

DoS攻擊這個方案是非常不切實際的,因為結果鎖定時間略大於先前鎖定時間的總和。

澄清一下:在將響應返回給瀏覽器之前,延遲不是延遲。 它更像是超時或不應期,在此期間,根本不會接受或評估特定帳戶或特定IP地址的登錄嘗試。 也就是說,正確的憑據將不會在成功登錄時返回,並且不正確的憑據不會觸發延遲增加。

最佳實踐#2: N次嘗試失敗後生效的中等時間延遲,如:

  • 1-4嘗試失敗=沒有延遲
  • 5次嘗試失敗=延遲15-30分鐘

DoS攻擊這個計劃是非常不切實際的,但肯定是可行的。 此外,可能需要注意的是,如此長的延遲對於合法用戶來說可能非常煩人。 忘記用戶會不喜歡你。

最佳實踐#3:結合兩種方法 - 在N次嘗試失敗後生效的固定短時間延遲,如:

  • 1-4嘗試失敗=沒有延遲
  • 5次失敗嘗試= 20秒延遲

或者,具有固定上限的增加延遲,例如:

  • 1次失敗嘗試= 5秒延遲
  • 2次失敗嘗試= 15秒延遲
  • 3次失敗嘗試= 45秒延遲

最終方案取自OWASP最佳實踐建議(來自MUST-READ列表的鏈接1),並且應該被認為是最佳實踐,即使它是公認的限制性方面。

但是,作為經驗法則,我會說:您的密碼策略越強,您就越不會對延遲的用戶造成錯誤。 如果您需要強大的(區分大小寫的字母數字+所需的數字和符號)9個以上的字符密碼,您可以在激活限制之前為用戶提供2-4次非延遲密碼嘗試。

DoS攻擊這個最終登錄限制方案將是非常不切實際的。 作為最後的觸摸,始終允許持久(cookie)登錄(和/或驗證CAPTCHA的登錄表單)通過,因此合法用戶甚至不會在攻擊進行中被延遲。 這樣,非常不切實際的DoS攻擊變成了一種非常不切實際的攻擊。

此外,對管理員帳戶進行更積極的限制是有意義的,因為這些是最具吸引力的切入點

第七部分:分佈式暴力攻擊

同樣,更高級的攻擊者會試圖通過“傳播他們的活動”來規避登錄限制:

  • 分發殭屍網絡上的嘗試以防止IP地址標記

  • 他們不會挑選一個用戶並嘗試使用50.000最常用的密碼(由於我們的限製而無法使用),他們會選擇最常用的密碼,然後嘗試對抗50.000用戶。 這樣,他們不僅可以解決CAPTCHA和登錄限制等最大限度嘗試措施,他們的成功機率也會提高,因為最常見的1號密碼比49.995更容易發生。

  • 將每個用戶帳戶的登錄請求間隔為30秒,以便潛入雷達

在這裡,最佳做法是記錄系統範圍內的失敗登錄次數 ,並使用站點的錯誤登錄頻率的運行平均值作為您對所有用戶施加的上限的基礎。

太抽象了? 讓我重新說一下:

假設您的網站在過去3個月內平均每天有120次不良登錄。 使用它(運行平均值),您的系統可能將全局限制設置為3倍 - 即。 在24小時內完成360次嘗試失敗。 然後,如果所有帳戶中的失敗嘗試總數在一天內超過該數量(甚至更好,監控加速率並觸發計算的閾值),則會激活系統範圍的登錄限制 - 這意味著所有用戶的短暫延遲(仍然,cookie登錄和/或備份CAPTCHA登錄除外)。

我還發布了一個更詳細的問題和一個非常好的討論,討論如何避免棘手的pitfals抵禦分佈式暴力攻擊

第八部分:雙因素身份驗證和身份驗證提供程序

憑據可能會受到損害,無論是利用漏洞,密碼被記錄下來還是丟失,密鑰被盜的筆記本電腦,還是用戶登錄釣魚網站。 可以使用雙因素身份驗證進一步保護登錄,該身份驗證使用帶外因素,例如通過電話,SMS消息,應用程序或加密狗接收的一次性代碼。 一些提供商提供雙因素身份驗證服務。

身份驗證可以完全委託給單點登錄服務,其中另一個提供程序處理收集憑據。 這會將問題推送給受信任的第三方。 谷歌和Twitter都提供基於標準的SSO服務,而Facebook則提供類似的專有解決方案。

必讀鏈接關於Web身份驗證

  1. OWASP身份驗證指南 / OWASP身份驗證備忘單
  2. Web上的客戶端身份驗證的注意事項(非常易讀的麻省理工學院研究論文)
  3. 維基百科:HTTP cookie
  4. 後備身份驗證的個人知識問題:Facebook時代的安全問題(非常易讀的伯克利研究論文)

我以為我會分享這個我發現工作得很好的解決方案。

我稱之為Dummy Field(雖然我沒有發明這個,所以不要相信我)。

簡而言之:您只需將此插入到您的<form>身份並在驗證時檢查它是否為空:

<input type="text" name="email" style="display:none" />

訣竅是欺騙機器人認為必須將數據插入必填字段,這就是為什麼我將輸入命名為“電子郵件”。如果您已經有一個名為email的字段,那麼您應該嘗試將虛擬字段命名為“company”,“phone”或“emailaddress”。只需選擇一些您不需要的東西,以及人們通常認為可以填充到網絡表單中的內容。現在input使用CSS或JavaScript / jQuery 隱藏字段 - 無論什麼最適合你 - 只是不要設置輸入typehidden否則機器人不會為它而墮落。

當您驗證表單(客戶端或服務器端)時,檢查您的虛擬字段是否已填滿,以確定它是由人還是機器人發送的。

例:

如果是人:用戶將看不到虛擬字段(在我的情況下命名為“email”)並且不會嘗試填充它。因此,在發送表單時,虛擬字段的值仍應為空。

在機器人的情況下:機器人將看到一個字段的類型text和名稱email(或你稱之為它的任何名稱),並將邏輯上嘗試用適當的數據填充它。它並不關心你是否用一些奇特的CSS設計輸入表格,網絡開發人員一直這樣做。無論虛擬場中的值是什麼,只要它比0字符大,我們就不在乎。

我在留言簿上使用這種方法與CAPTCHAs結合使用,之後我沒有看過任何一封垃圾郵件。我之前使用過CAPTCHA解決方案,但最終每小時產生了大約5個垃圾郵件。在表單中添加虛擬字段已停止(至少到現在為止)所有垃圾郵件都會出現。

我相信這也可以用於登錄/身份驗證表單。

警告:當然這種方法不是100%萬無一失。可以將機器人編程為忽略display:none應用了樣式的輸入字段。您還必須考慮使用某種形式的自動完成功能的人(如大多數瀏覽器內置的!)來自動填充所有表單字段。他們可能也會選擇一個虛擬場。

您也可以通過讓虛擬區域可見但在屏幕邊界之外可以稍微改變一下,但這完全取決於您。

要有創意!


我想補充一點非常重要的評論:

  • “在公司 內部網絡環境中,”如果不是所有上述內容都可能不適用!

許多公司部署“僅供內部使用”的網站,這些網站實際上是恰好通過URL實現的“公司應用程序”。這些URL可以(據說......)僅在“公司內部網絡”中解析。(哪個網絡神奇地包括所有與VPN連接的“公路戰士”。)

當用戶盡職地連接到上述網絡時,他們的身份(“身份驗證”) [已經......]“最終知道”,以及他們允許(“授權”)做某些事情......例如。 ..“訪問這個網站。”

這種“身份驗證+授權”服務可以由幾種不同的技術提供,例如LDAP (Microsoft OpenDirectory)或Kerberos。

從您的角度來看,您只需要知道:任何合法地在您的網站上結束的人必須伴隨著[一個環境變量神奇地包含......]一個“令牌”。(沒有這樣的代幣必須是直接的理由404 Not Found。)

令牌的價值對你沒有意義,但是,如果需要,“存在適當的手段”,你的網站可以“[權威地]詢問知道(LDAP ......等)的人”任何一個( !)你可能有的問題。換句話說,你沒有利用任何 “本土邏輯”。相反,你詢問管理局並​​暗中信任其判決。

嗯......這是相當從精神開關“野生和毛茸茸的互聯網。”


首先,一個強烈的警告,這個答案不是最適合這個問題的答案。 絕對不應該是最好的答案!

我將繼續提及Mozilla提出的BrowserID (或者更確切地說,可能是已驗證的電子郵件協議 ),其目的是尋找未來更好的身份驗證方法的升級途徑。

我會這樣總結一下:

  1. Mozilla是一個非盈利組織,其values與找到解決此問題的良好解決方案非常吻合。
  2. 今天的現實是大多數網站使用基於表單的身份驗證
  3. 基於表單的身份驗證有一個很大的缺點,即增加了phishing風險。 要求用戶將敏感信息輸入到由遠程實體控制的區域,而不是由其用戶代理(瀏覽器)控制的區域。
  4. 由於瀏覽器是隱式信任的(用戶代理的整個想法是代表用戶行事),因此它們可以幫助改善這種情況。
  5. 這裡阻礙進展的主要力量是部署僵局 。 必須將解決方案分解為自己提供一些增量收益的步驟。
  6. 用於表達內置於互聯網基礎設施中的身份的最簡單的分散方法是域名。
  7. 作為表達身份的第二級,每個域管理自己的一組帳戶。
  8. “account @ domain”形式簡潔明了,並受到各種協議和URI方案的支持。 當然,這種標識符最普遍地被認為是電子郵件地址。
  9. 電子郵件提供商已經是在線事實上的主要身份提供商。 如果您可以證明您控制該帳戶的關聯電子郵件地址,則當前密碼重置流程通常允許您控制帳戶。
  10. 建議使用經驗證的電子郵件協議,以提供基於公鑰加密的安全方法,以簡化向域B證明您在域A上擁有帳戶的過程。
  11. 對於不支持已驗證電子郵件協議(當前所有這些)的瀏覽器,Mozilla提供了一個在客戶端JavaScript代碼中實現協議的填充程序。
  12. 對於不支持已驗證電子郵件協議的電子郵件服務,該協議允許第三方充當可信中間人,聲稱他們已驗證用戶對帳戶的所有權。擁有大量此類第三方是不可取的; 此功能僅用於允許升級路徑,並且更優選的是電子郵件服務本身提供這些斷言。
  13. Mozilla提供自己的服務,充當這樣一個值得信賴的第三方。實施經過驗證的電子郵件協議的服務提供商(即依賴方)可能會選擇信任Mozilla的斷言。Mozilla的服務使用傳統方式發送帶有確認鏈接的電子郵件來驗證用戶的帳戶所有權。
  14. 當然,除了他們可能希望提供的任何其他身份驗證方法之外,服務提供商還可以提供此協議作為選項。
  15. 這裡尋求的大用戶界面好處是“身份選擇器”。當用戶訪問網站並選擇進行身份驗證時,他們的瀏覽器會向他們顯示他們可能用來向網站標識自己的電子郵件地址(“個人”,“工作”,“政治激進主義”等)。
  16. 作為此項工作的一部分,正在尋求的另一個重大用戶界面優勢是幫助瀏覽器更多地了解用戶的會話 - 他們當前主要登錄的是誰 - 因此它可以在瀏覽器chrome中顯示。
  17. 由於該系統的分佈式特性,它避免了對Facebook,Twitter,Google等主要網站的鎖定。任何個人都可以擁有自己的域,因此可以充當自己的身份提供者。

這不是嚴格的“基於表單的網站身份驗證”。但是,這是從當前基於表單的身份驗證規範過渡到更安全的東西:瀏覽器支持的身份驗證。



我想根據防禦深度添加一個我使用過的建議。您不需要為常規用戶提供與管理員相同的auth&auth系統。您可以在單獨的URL上使用單獨的登錄表單,為要授予高權限的請求執行單獨的代碼。這個可以做出對普通用戶來說完全痛苦的選擇。我使用的一個實際上是加密管理員訪問的登錄URL並通過電子郵件向管理員發送新URL。由於您的新網址可能是任意困難(非常長的隨機字符串),因此立即停止任何暴力攻擊,但您的管理員用戶唯一的不便是關注其電子郵件中的鏈接。攻擊者不再知道POST到哪裡。


散列時,不要使用快速哈希算法,如MD5(存在許多硬件實現)。使用像SHA-512這樣的東西。對於密碼,較慢的哈希值更好。

創建哈希值的速度越快,任何強力檢查器都可以工作得越快。較慢的哈希因此會減慢暴力迫使。慢速哈希算法會使更長時間的密碼(8位+)變得不切實際





article