近年來，您可能聽說過一些有關無密碼身份驗證的討論——十多年來，科技行業(yè)領導者一直游說將其作為消費者網絡應用程序的?標準做法。
即使無密碼身份驗證的概念對你來說很新，在 2023 年從事科技行業(yè)的人也很難不知道 LastPass 遭受的網絡攻擊。對于許多人，無論是科技行業(yè)的專業(yè)人士還是普通消費者，這都是一個警鐘。這不僅是一次大規(guī)模的數(shù)據(jù)泄露——超過 3000 萬用戶的密碼被泄露——而且最初是由密碼盜竊造成的。
如果連密碼管理器都無法安全地管理登錄憑據(jù)，那么對我們其他人來說意味著什么？也許現(xiàn)在正是無密碼身份驗證成為焦點的最佳時機。
從消費者的角度來看，現(xiàn)在絕對是采取措施實施更安全的密碼管理措施的時候了。
應用程序開發(fā)人員顯然有必要改變其身份驗證模型。基于瀏覽器的無密碼身份驗證比以往任何時候都更加簡單，消費者也已準備好為其最敏感的在線活動采用更好的安全實踐。
但是 API 團隊呢？基于瀏覽器的身份驗證實踐不會徹底改變在數(shù)據(jù)層工作和生活的團隊的實踐，但對于 API 開發(fā)人員和產品經理來說，仍然有一些重要的收獲。?
這聽起來像是來自治療師的建議，但任何對網絡安全感興趣的人都需要注意這個警告：人們會犯錯，你無法阻止他們——但你可以改變你的環(huán)境，讓錯誤造成的危害更小。
不過，我們并不是要責怪用戶！產品團隊應該：
安全設計，無論是面向消費者的應用程序、面向開發(fā)人員的 API 還是介于兩者之間的任何應用程序，都必須將安全負擔從個人用戶身上轉移開。OWASP十大安全問題備受關注，但規(guī)劃網絡安全的人為因素比檢查該列表中的任何項目都更為重要。至少 80% 的網絡攻擊涉及人為錯誤。是的，遵循 OWASP 原則將有助于您避免這些錯誤 – 這些原則的存在是為了服務于創(chuàng)建和使用技術產品的人們。?
密碼特別容易受到人為錯誤的影響，因為從安全因素的角度來看，它們是“你知道的東西”。API 密鑰也類似——這是否意味著我們也應該擺脫它們？幸運的是，答案是否定的。
我們不太可能完全取代密碼。使用加密密鑰或 MFA 來保護您的 wifi 將是毫無意義的麻煩——它是一個低價值目標，需要由多個人和設備訪問，并且當它同時擴展到太多用戶時最容易受到攻擊。密碼完全沒問題。
API 密鑰也有適當?shù)挠猛尽？紤]一個免費的天氣數(shù)據(jù) API。API 密鑰對于速率限制和使用指標最為重要，而更繁重的身份驗證方法則不會帶來回報。它與 Wi-Fi 網絡有類似的約束 – 未經授權訪問的缺點非常低，提供易于訪問很重要，而最重要的風險來自流量激增或 DDOS攻擊。如果這描述了您的 API，請隨意使用速率限制密鑰！
但是，一旦涉及任何專有數(shù)據(jù)或財務信息，就必須開始詢問有關安全設計的問題。API 消費者首先如何訪問他們的密鑰？它是否受到基于密碼的身份驗證方法的保護？API 密鑰是否與任何財務數(shù)據(jù)或個人身份信息相關？任何敏感數(shù)據(jù)是否保存在托管公共端點的同一臺服務器上？依靠 API 消費者適當?shù)毓芾磉@些風險并不理想。
安全“左移”的勢頭正在強勁。在許多情況下，這意味著轉向“ DevSecOps”模式，從開發(fā)生命周期一開始就將安全性集成到自動化流程中。這是一種實際的轉變，也是一種文化的轉變——安全性不是事后的想法或障礙，而是每個階段不可或缺的考慮因素。如果做得正確，DevSecOps 會更安全、更高效。
當 DevSecOps 方法導致開發(fā)團隊將安全性視為主要運營問題時，這種方法可能會失敗。運營問題很重要，我們將在下文中進一步討論這些問題 – 但任務應該是從設計上保證安全性。這意味著在設計產品和流程的每個方面時都要考慮到安全性。
安全性設計與以人為本的設計密不可分。無論您是在查看數(shù)據(jù)層的架構、如何在代碼 linter 中實施安全實踐，還是對不同資源使用哪些身份驗證協(xié)議，目標都是限制人為錯誤的可能性，并在有人不可避免地犯錯時將損害降至最低。
竊取密碼和其他敏感數(shù)據(jù)的最常見手段之一是“中間人”攻擊。在這一領域，應用程序開發(fā)人員開始意識到大多數(shù) API 開發(fā)人員已經知道的事實：加密至關重要！
至少，在 2023 年，任何人都不應該通過不安全的 HTTP 連接傳輸任何數(shù)據(jù)。到目前為止，HTTPS For Everything已成定局。大多數(shù) API 通信可能應該通過某種額外的加密來保護。在大多數(shù)情況下，TLS是一個不錯的選擇。
WebAuthn 是業(yè)界最佳的無密碼身份驗證瀏覽器標準，它使用與 TLS 相同的加密方法：
WebAuthn與多因素身份驗證不同，需要注意的是，MFA/2FA 方法失寵的部分原因是缺乏加密。短信是許多 MFA 流程中的流行選項，但它無法加密，而且很容易被攔截，因為蜂窩網絡的設計并不安全。?
您仍然可以使用智能手機作為 WebAuthn 流程的一部分。在任何具有認證身份驗證器的設備上，您都可以生成公鑰/私鑰對并將其注冊到應用程序或服務中。私鑰永遠不會離開設備，使用公鑰加密的數(shù)據(jù)只能由私鑰解密，反之亦然。相關數(shù)據(jù)以JSON 對象的形式傳輸。
如果您是一名 API 開發(fā)人員，這聽起來很熟悉，可能是因為您以前使用過JWT。WebAuthn的大部分數(shù)據(jù)流與 JWT 身份驗證類似。JWT并不完美，WebAuthn 和 JWT 之間的差異說明了原因。?
JWT 的一個風險來源是，在預設的過期時間之前，很難撤銷令牌。在令牌有效期間，客戶端應用程序控制會話。即使客戶端開始執(zhí)行可疑或惡意操作，服務器也無法終止單個令牌。這使得 JWT不適合基于會話的身份驗證，盡管這是一種常見做法。相比之下，WebAuthn 允許客戶端和服務器應用程序隨時終止身份驗證。客戶端應用程序從不直接處理密鑰，但必須具有加密的有效證明才能完成任何請求。通過撤銷公鑰，服務器可以隨時 強制進行新的注冊。
值得強調的第二個區(qū)別是加密。在 WebAuthn 應用程序中，除注冊儀式期間的公鑰外，所有流量都經過加密。可以加密JWT 身份驗證流程中的所有通信，但此行為不是默認行為。除非您選擇使用JSON Web 加密(JWE)，否則 JSON 令牌是簽名的但未加密。簽名可保護消息免遭篡改，但不能防止通過中間人攻擊進行攔截。
雖然這些選項本身都不是壞的（也許除了 SMS 2FA），但 API 團隊需要注意加密的內容和時間。對所有請求使用完全非對稱加密是有成本的，但在某些情況下，這是值得投資的。在金融和醫(yī)療保健領域，監(jiān)管指南會告訴您何時需要傳輸加密或靜態(tài)加密。但即使在監(jiān)管較少的行業(yè)，您也需要小心選擇能夠妥善保護數(shù)據(jù)的身份驗證和加密協(xié)議。
優(yōu)秀 API 產品最有價值的屬性之一是它與客戶端無關。如果您正在構建 API，您無疑會考慮一些特定的用例，但 API 使用者會做一些您從未預料到的事情，而且通常會帶來令人印象深刻的結果。雖然這種創(chuàng)造力可能會導致一些問題，但對于 API 產品團隊來說，重要的是優(yōu)先考慮安全性，同時為優(yōu)雅的錯誤留出空間并培養(yǎng)靈活性。?
一些 API 團隊可能傾向于將使用其 API 的客戶端應用程序視為事后考慮或未知數(shù)。但是，與客戶端無關并不意味著您可以對前端安全性漠不關心或松懈。這些客戶端應用程序是進入 API 的門戶，您需要建立護欄以確保流量安全。
過去 15 年，單頁應用風靡一時，但最近，一些應用卻從邊緣退縮。退縮的原因之一是 SPA 的攻擊面非常大，后端邏輯和數(shù)據(jù)有很多可能潛入前端的位置。
一種在客戶端復雜性和數(shù)據(jù)安全性之間取得更好平衡的設計模式是Backend For Frontend。API 產品團隊可以成為實現(xiàn) BFF 的強大合作伙伴，BFF 是 API 網關模式的一種變體。雖然 API 網關將客戶端和服務器之間的連接集中在單個訪問點，但 BFF 會為每個客戶端創(chuàng)建一個特定的協(xié)調層，從而減少膨脹并限制前端暴露。?
作為 BFF 架構成功組件的 API 需要遵循一些最佳實踐：
無論您的客戶使用何種架構，大多數(shù)這些實踐都將獲得回報，但您的設計越能圍繞實際用例，您就越能夠創(chuàng)建既安全又靈活的 API 產品。
為了支持更安全的客戶端應用程序，API 設計人員可以做的最重要的事情就是在盡可能少的位置存儲盡可能少的敏感數(shù)據(jù)。無密碼身份驗證之所以成為一種圣杯，原因之一是它涉及的數(shù)據(jù)交換盡可能少——您實際上可以在不傳輸用戶名的情況下進行身份驗證，而客戶端應用程序根本不會處理任何身份驗證憑據(jù)。如果您將其擴展到數(shù)據(jù)層，這種嚴格程度會是什么樣子？
與加密一樣，一些行業(yè)對數(shù)據(jù)隔離有明確的標準。此外，任何希望在歐盟開展業(yè)務的公司都需要遵守《通用數(shù)據(jù)保護條例》（GDPR），該條例要求進行適當?shù)臄?shù)據(jù)隔離。即使這些因素不適用于您，合乎邏輯且一致的數(shù)據(jù)隔離實踐也將幫助您創(chuàng)建我們一直在談論的緩沖區(qū)！
人為錯誤是不可避免的，但如果你限制任何一個地方的敏感數(shù)據(jù)量，你就可以限制這些錯誤造成的后果。
您已盡最大努力確保您的 API 在設計上是安全的。您已與客戶合作，了解他們的需求并支持他們構建安全的前端應用程序。您已反復閱讀 OWASP Top 10。您已盡可能為您的個人帳戶啟用安全的 MFA 或無密碼身份驗證。但還有一個領域我們還需要討論。
2022 年秋季和 2023 年冬季發(fā)生的 La??stPass 事件始于一名惡意行為者截獲了主密碼。只有四個人知道這個密碼，但對于一個有動機的黑客來說，找出哪些員工可能值得攻擊并不難。一點點社交工程就可以迅速將攻擊者引向高價值的網絡釣魚目標。如果這些人使用不安全的身份驗證方法，很快就會造成巨大的損失。
您如何為內部團隊制定安全措施？您如何篩選供應商？您采取了哪些措施來確保您的關鍵員工免受社交工程和網絡釣魚攻擊？
如果你的生產系統(tǒng)不安全，那么你的產品也不安全。安全設計不僅包括保護你的設計資產、設計工具，還要確保設計師的訪問憑證安全。人為錯誤在所難免。
技術行業(yè)面臨的挑戰(zhàn)是繼續(xù)支持協(xié)作和創(chuàng)新（API 經濟的標志和優(yōu)秀 API 產品的目標），同時將安全性作為頂級功能和設計重點。好消息是，您所需的知識和工具已經存在，Stoplight 和 Smartbear 等合作伙伴可以幫助您將它們付諸實踐。
文章來源：API?Passwords?Stink!?Freshen?Up?Your?Security?Practices