用戶身份驗(yàn)證是每個(gè)Web應(yīng)用程序共享的功能。 我們已經(jīng)實(shí)現(xiàn)了很多次，所以很早以前就應(yīng)該完善它。 然而，錯(cuò)誤無(wú)時(shí)無(wú)刻不在發(fā)生。

造成這種情況的部分原因是，可能出問題的清單很長(zhǎng)。 您可能會(huì)錯(cuò)誤地存儲(chǔ)密碼，可能會(huì)具有脆弱的密碼重置功能，可能使會(huì)話遭受CSRF攻擊，會(huì)話可能被劫持，等等。因此，我將嘗試匯編有關(guān)用戶身份驗(yàn)證的最佳做法列表。 每年， OWASP TOP 10總是您應(yīng)該閱讀的內(nèi)容。 但這可能還不夠。

所以，讓我們開始吧。 我會(huì)盡量簡(jiǎn)明扼要，但我會(huì)盡可能涵蓋所有相關(guān)的陷阱-例如，用戶會(huì)話登錄后可能出什么問題：

• 使用bcrypt / scrypt / PBKDF2存儲(chǔ)密碼。 沒有MD5或SHA，因?yàn)樗鼈儾焕诿艽a存儲(chǔ)。 長(zhǎng)鹽（每位用戶）是強(qiáng)制性的（上述算法已內(nèi)置）。 如果您不這樣做，并且有人控制了您的數(shù)據(jù)庫(kù)，那么他們將能夠提取所有用戶的密碼。 然后在其他網(wǎng)站上嘗試這些密碼。
• 使用HTTPS。 期。 （否則，用戶憑據(jù)可能會(huì)通過不受保護(hù)的網(wǎng)絡(luò)泄漏）。 如果用戶打開純文本版本，則強(qiáng)制使用HTTPS。 并確保僅使用最新的協(xié)議（目前使用TLS 1.2； TLS 1.1似乎沒有漏洞，因此也可以受支持）。 您可以進(jìn)行Qualys掃描以檢查支持的協(xié)議版本是否正確。
• 將Cookie標(biāo)記為secure 。 使餅干盜竊更加困難。
• 使用CSRF保護(hù)（例如，隨每個(gè)請(qǐng)求驗(yàn)證的CSRF一次性令牌）。 框架具有內(nèi)置的此類功能。
• 禁止取景（ X-Frame-Options: DENY ）。 否則，您的網(wǎng)站可能會(huì)以隱藏的iframe包含在另一個(gè)網(wǎng)站中，并通過javascript被“濫用”。
• 有一個(gè)同源政策
• 注銷–通過刪除所有cookie并使會(huì)話無(wú)效，讓您的用戶注銷。 這樣可以更安全地使用共享計(jì)算機(jī)（是的，用戶最好使用私有瀏覽會(huì)話，但并非所有人都那么聰明）
• 會(huì)話期滿–沒有永久的會(huì)話。 如果用戶關(guān)閉您的網(wǎng)站，則其會(huì)話應(yīng)在一段時(shí)間后到期。 取決于提供的服務(wù)，“一會(huì)兒”可能仍然是很大的數(shù)字。 對(duì)于ajax繁重的網(wǎng)站，您可以進(jìn)行常規(guī)的ajax輪詢，以在頁(yè)面保持打開狀態(tài)時(shí)使會(huì)話保持活動(dòng)狀態(tài)。
• 記住我-由于永久性cookie被盜的風(fēng)險(xiǎn)，（在這臺(tái)機(jī)器上）實(shí)現(xiàn)“記住我”功能實(shí)際上很困難。 Spring-security使用這種方法 ，如果您想實(shí)現(xiàn)更持久的登錄，我認(rèn)為應(yīng)該遵循。
• 忘記密碼流–忘記密碼流應(yīng)依賴于向用戶發(fā)送一次（或到期）鏈接，并在打開密碼時(shí)要求輸入新密碼。 0Auth在這篇文章中對(duì)此進(jìn)行了解釋 ，郵戳給了一些最好的事實(shí) 。 如何形成鏈接是一個(gè)單獨(dú)的討論，有幾種方法。 將密碼重置令牌存儲(chǔ)在用戶配置文件表中，然后將其作為參數(shù)發(fā)送到鏈接中。 或者不要在數(shù)據(jù)庫(kù)中存儲(chǔ)任何內(nèi)容，而是發(fā)送一些參數(shù)： userId:expiresTimestamp:hmac(userId+expiresTimestamp) 。 這樣，您將擁有過期的鏈接（而不是一次性鏈接）。 HMAC依賴于秘密密鑰，因此不能欺騙鏈接。 但是，由于OWASP指南的方法略有不同 ，因此在該主題上似乎尚未達(dá)成共識(shí)
• 一次性登錄鏈接–這是Slack使用的選項(xiàng)，它發(fā)送一次性登錄鏈接，而不是詢問用戶密碼。 這取決于您的電子郵件受到嚴(yán)格保護(hù)，并且您始終可以訪問它。 如果不經(jīng)常訪問您的服務(wù)，則可以使用該方法代替密碼（而不是除密碼之外）。
• 限制登錄嘗試–無(wú)法通過Web UI進(jìn)行暴力破解； 因此，如果登錄嘗試次數(shù)過多，則應(yīng)將其阻止。 一種方法是僅基于IP阻止它們。 另一個(gè)是根據(jù)嘗試的帳戶阻止它們。 （ 這里是Spring示例 ）。 哪一個(gè)更好-我不知道。 兩者實(shí)際上可以合并。 除了完全阻止嘗試之外，您還可以在第5次嘗試后添加驗(yàn)證碼。 但是，請(qǐng)勿在首次嘗試時(shí)添加驗(yàn)證碼-這是糟糕的用戶體驗(yàn)。
• 不要通過錯(cuò)誤消息泄漏信息–您不應(yīng)該允許攻擊者弄清楚是否已注冊(cè)電子郵件。 如果未找到電子郵件，則登錄后僅報(bào)告“憑據(jù)不正確”。 重置密碼時(shí)，可能類似于“如果已注冊(cè)電子郵件，您應(yīng)該已經(jīng)收到了重置密碼電子郵件”。 這通常與可用性不符–人們通常不記得他們過去用來(lái)注冊(cè)的電子郵件，因此在進(jìn)入之前檢查大量電子郵件的能力可能很重要。 因此，此規(guī)則不是絕對(duì)的，盡管它是理想的，尤其是對(duì)于更關(guān)鍵的系統(tǒng)。
• 確保僅在確實(shí)必要時(shí)才使用JWT，并要注意一些陷阱。
• 考慮使用第三方身份驗(yàn)證-OpenID Connect，Google / Facebook / Twitter的OAuth （但也要注意OAuth的缺陷 ）。 依靠第三方身份提供者存在相關(guān)風(fēng)險(xiǎn)，您仍然必須管理cookie，注銷等，但是簡(jiǎn)化了某些身份驗(yàn)證方面。
• 對(duì)于高風(fēng)險(xiǎn)或敏感應(yīng)用程序，請(qǐng)使用2因子身份驗(yàn)證 。 不過，Google身份驗(yàn)證器有一個(gè)警告-如果您丟失了手機(jī)，就會(huì)丟失帳戶（除非有手動(dòng)過程來(lái)恢復(fù)它）。 這就是為什么Authy似乎是存儲(chǔ)2FA密鑰的好解決方案。

我確定我想念什么。 您會(huì)發(fā)現(xiàn)它很復(fù)雜。 遺憾的是，我們?nèi)匀惶幵谧畛Ｒ姷墓δ?驗(yàn)證用戶身份-如此棘手和繁瑣的狀態(tài)，以至于您幾乎總是會(huì)誤解至少其中一些錯(cuò)誤。

翻譯自: https://www.javacodegeeks.com/2018/04/user-authentication-best-practices-checklist.html

總結(jié)

以上是生活随笔為你收集整理的用户身份验证最佳做法清单的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。