Google和Yubico剛剛宣布遵循FIDO U2F規範提供加密安全令牌。
具體來說:
- 這是什麼方式?只是另一個2FA選項,還是比SecureID和TOTP等解決方案好得多? U2F與OTP根本不同嗎?
- 與OTP系統相比,U2F對網絡釣魚攻擊的可行性有何影響?
- 針對U2F的非交互式攻擊(例如蠻力,等)?
- 我可以安全地將單個U2F令牌與多個獨立服務一起使用嗎?
- U2F如何與其他商業產品相結合?有更好的解決方案嗎?
Google和Yubico剛剛宣布遵循FIDO U2F規範提供加密安全令牌。
具體來說:
我得到的答案很好,但是我想提供更多的深度,特別是系統為什麼存在的原因,這應該進一步解釋它的優點。
免責聲明:在我現在為Google工作時,撰寫此答案時我對該項目一無所知。此處報告的所有內容均來自公共資源。這篇文章是我自己的觀點,看法和評論,並不代表Google的觀點,看法或意圖。
儘管值得指出,我一直在使用這個問題並進行了一段時間的修改,作為一個在社會工程和帳戶接管方面做了大量工作的人,我對這裡所取得的成就印象深刻。
考慮一下:很久以前,Google部署了兩因素身份驗證。這是一家非常關注安全性的公司,他們的安全性一直很高。儘管他們已經在使用最好的技術,但是 U2F在傳統2要素之上提供的額外安全性是如此重要,值得公司花時間和金錢進行設計,開發,部署和支持他們甚至自己都不賣的替代系統。是的,這是他們走這條路的極具社會意識的舉動,但這不僅關乎社區。 Google之所以這樣做,是因為他們自己需要U2F本身提供的安全性。許多人以他們最寶貴的信息信任Google,有些人在危險的政治環境中甚至以自己的生活( )信任Google。 Google需要安全性以能夠實現這種信任。
這歸結為網絡釣魚。網絡釣魚非常重要。這是非常常見且超級有效。對於針對硬化目標的攻擊,網絡釣魚和類似攻擊確實是攻擊者的最佳選擇,他們也知道。而且更重要的是:
我們的網絡釣魚防護是可笑的。我們具有兩因素身份驗證,但是實現很少提供防禦。諸如SecurID,Google Authenticator,電子郵件,電話和SMS循環之類的常見系統-所有這些系統對使用時間的網絡釣魚攻擊均完全沒有提供保護。一次性密碼仍然是密碼,可以將其公開給攻擊者。
這不僅是理論上的。我們已經看到這些攻擊實際上是在進行的。實際上,攻擊者確實捕獲了發送到網絡釣魚站點的第二因素響應,並立即在真實的登錄頁面上播放它們。 這實際上發生在現在。
因此,您是Google。您已經部署了最好的保護措施,您會發現它們還不夠。你是做什麼?沒有其他人可以為您解決這個問題。您必須弄清楚。
創建一個不能被誘騙的第二因素解決方案非常簡單。您所要做的只是涉及瀏覽器。在U2F的情況下,設備會為每個站點創建一個公鑰/私鑰對,並將站點的身份刻錄到該站點用來請求身份驗證的“密鑰句柄”中。然後,每次嘗試進行身份驗證之前,瀏覽器都會驗證該站點身份。站點身份甚至可以綁定到特定的TLS公共密鑰。而且由於它是一種挑戰響應協議,因此也無法重播。而且,如果服務器在數據庫洩漏中意外洩漏了您的“密鑰句柄”,它仍然不會影響您的安全性或洩露您的身份。 使用此設備有效地消除了網絡釣魚的可能性,這對安全敏感的組織來說意義重大。
加密技術及其應用都不是新事物。兩者都是很好理解和信任的。技術從來都不是難題,難題是採用。但是,谷歌是能夠克服通常阻礙此類解決方案發展的障礙的少數參與者之一。由於Google是最受歡迎的瀏覽器,因此他們可以確保默認情況下兼容。由於他們是最受歡迎的移動操作系統,因此可以確保它也能正常運行。而且,由於他們運行最受歡迎的電子郵件服務,因此他們可以確保該技術具有相關的用例。
當然,Google可以利用這一優勢來賦予自己在市場上的競爭優勢,但事實並非如此。那太酷了。 每個人都需要這種級別的保護,包括Yahoo和Microsoft及其競爭的電子郵件產品。很棒的是,它的設計使得即使競爭對手也可以安全地製造自己的產品。谷歌沒有與這項技術相關的任何東西-即使硬件完全與使用無關。
系統設計時假設您不會僅將其用於Google。該協議的主要特徵是令牌在任何時候都不能識別自身。實際上,規範指出,選擇這種設計是為了防止創建“超級cookie”的可能性,該跟踪可用於在合用服務之間跟踪您。
因此,您可以獲得單個令牌,並且不僅可以在Gmail上安全使用它,而且可以在支持U2F的任何其他服務上安全地使用它。這給了您更多的理由來花一分錢。而且自從Yubico 發布了參考的PHP,Java和Python服務器軟件實現以來,即使在小型商店中,也可以安全地在自己的服務器上啟動並運行身份驗證。
U2F能夠使用使用公鑰加密的加密通道來確保只有正確的服務器才能獲得一次性令牌。這意味著在網絡釣魚站點上插入它意味著什麼也沒發生-他們無法進入您的帳戶。相反,他們必須依靠XSS和本地惡意軟件之類的技術攻擊。
應該可以掩蓋您將同一設備用於多種服務這一事實,因此控制站點A和站點B的人看不到您在同一設備上使用了同一設備都。應該是安全的。
這似乎是目前可用的最佳選擇,主要是因為正在進行的標準化過程以及對其的廣泛支持和發展勢頭。
在註冊在線服務期間,用戶的客戶端設備會創建一個新的密鑰對。它保留私鑰,並在在線服務中註冊公鑰。客戶端設備通過簽署挑戰來證明擁有服務私鑰,從而完成身份驗證。客戶端的私鑰只有在用戶在設備上本地解鎖後才能使用。本地解鎖是通過用戶友好且安全的操作來完成的,例如,滑動手指,輸入PIN,對著麥克風講話,插入輔助設備或按下按鈕。
我還沒有完全探索規範。但是:
U2F與OTP有什麼根本區別?
U2F不使用OTP。它實際上是關於站點身份驗證以及將擁有私鑰作為因素的。
與OTP系統相比,U2F對網絡釣魚攻擊的可行性有何影響?
有時限的OTP系統在對抗網絡攻擊方面表現出色網絡釣魚(竊取憑據),因為它們很難被竊取。 U2F確實旨在抵抗MiTM攻擊。
針對U2F的非交互式攻擊(例如蠻力等)如何可行?
蠻力攻擊真的不是要走的路。您可能想從服務器或客戶端上竊取密鑰。它如何處理惡意軟件等是關鍵。實施非常重要。
我可以安全地將單個U2F令牌與多個獨立服務一起使用嗎?
確定-這就是為什麼公共/私有密鑰比共享機密更好。
U2F如何與其他商業產品相提並論?有更好的解決方案嗎?
我只能與我們交流,無論是在商業版還是在開源版中。主要區別在於,我們將目標站點的ssl證書的哈希存儲在身份驗證服務器中,並提供由身份驗證服務器的私鑰加密的OTP。在用戶獲得OTP之前,軟件令牌會通過用戶的連接獲取目標站點的證書,對其進行哈希處理並進行比較。如果它們匹配,則會顯示OTP,然後將其複製到剪貼板,然後將瀏覽器啟動到URL。如果沒有,則給出錯誤。
因此,無需更改服務器或瀏覽器。密鑰存儲在與Web服務器不同的服務器上。 OTP是該過程的一部分(儘管可以將其刪除/隱藏)。它是開源的。另一方面,U2F確實有發展動力,儘管它是一個“按需付費”財團。 U2F在某些“安全”硬件產品上可用。我們可以在它們上實現(例如,加密USB驅動器)。 YMMV。
有關WiKID相互身份驗證的更多信息,請參見: https://www.wikidsystems.com/learn-more/technology/mutual_authentication和此處的操作方法: http://www.howtoforge.com/prevent_phishing_with_mutual_authentication。
我剛剛閱讀了一些規格,因為我想知道設備是否存儲了實際的(專用)密鑰。我可以嘗試回答一些問題。
OTP只是一次性令牌,而U2F基於公鑰加密;更具體地說,Yubico Fido U2F密鑰似乎使用了橢圓曲線密碼。
U2F應該有助於防止網絡釣魚攻擊,因為您必須通過手動干預(即按按鈕)來確認交易。竊取密鑰將需要竊取設備本身,這可能比OTP針更難,具體取決於人們將其存儲在哪裡。當然,這兩種方法在某種程度上仍然容易受到MitM攻擊;如果攻擊者可以某種方式進入您與服務之間,干擾正在進行的會話,那麼您將無能為力。流量應該經過加密,端點驗證,並且沒有人可以完全訪問您的計算機;
我認為破壞U2F密鑰的可行性將取決於特定硬件密鑰上已實現的公共密鑰算法的強度。 Yubico鍵似乎在P-256 NIST橢圓曲線上使用ECDSA。判斷一下自己的位數(以及曲線的來源)是否足夠安全和可靠...
FIDO的概述文檔中提到“廉價的U2F設備”,它不存儲實際的私鑰,但將它們加密(包裝)存儲在“密鑰句柄”中,這是將私鑰和公鑰鏈接在一起並發送到遠程服務的標識符。 因此,如果我對它的理解正確,那麼遠程服務會同時獲取公共密鑰(按原樣)和私有密鑰(在密鑰句柄中加密),因此,安全性實際上取決於硬件設備上使用的算法的安全性。遠程站點具有您的私鑰!從某種意義上講,這是將用戶的會話加密後存儲在cookie中的相反過程–此處,遠程站點保留密鑰,私鑰部分被加密,並且理論上只能由硬件設備解密。有趣的是,這種Yubico設備本身就是這樣一種設備,即密鑰離開了設備而不是包含在其中。
我了解經濟且易於使用的動機–存儲很多密鑰在這類設備中,芯片上的成對存儲會更昂貴-但我不確定我是否喜歡這種方法。
因此,請回到您關於將令牌與多個獨立服務一起使用的問題:設備由於密鑰對保存在服務本身上,因此可以生成任意數量的對。登錄時,設備將解開私鑰並檢查簽名。該消息包含來源,因此密鑰應僅適用於該特定服務。
出於高度安全的目的,最好使用一種以私鑰方式存儲(或生成)私鑰的設備。根本無法檢索,也永遠不會離開設備。我對這些設備的電子方面一無所知,但我假設,假設設備使用的芯片與現代智能卡使用的芯片相同,那麼這將需要相當複雜的攻擊者竊取然後破解物理硬件來獲取密鑰。 ,sims和其他形式的硬件加密。
來源:
U2F令牌使用公鑰密碼術實現挑戰響應算法。它提供了兩個功能:註冊新來源和計算對挑戰的響應。
因此,它不實現一次性密碼(OTP)生成。
(起源字符串標識遠程系統,例如,遠程服務器的主機名。)
註冊新起源時,令牌使用起源字符串作為輸入並返回
使用新創建的私鑰。證明密鑰對在同一供應商生產的一組設備之間共享,並且通常由著名的CA簽名。密鑰句柄是標識KA的字符串。所有這些項目都發送到起點。
在簽署挑戰(即生成響應)時,令牌將獲取原始字符串,挑戰數據(包含會話信息) ,並輸入一個密鑰句柄。
有效的U2F令牌實現具有可能較大的可寫關聯數組其中密鑰句柄映射到私鑰和原始信息。該數組不得保留該令牌,因此應防止其被讀出。
U2F規範不允許將私鑰重用於不同的來源;因此,需要一個大數組。
或者,也可以使用沒有任何讀寫內存的U2F令牌實現:而不是存儲私有密鑰和令牌內部的來源,令牌使用內部密鑰(K0)對稱地對其進行加密。然後將結果作為鍵句柄返回。在理智的硬件設計中,K0不能離開令牌。換句話說,私鑰和原始字符串是從外部存儲的,因為它們被用作密鑰句柄,所以它們被分配到原始位置-只要加密不中斷就可以了。
基本上,大多數可用的U2F令牌都實現了第二種方法,因此生產起來相對便宜(在亞馬遜上起價為5歐元左右:搜索“ FIDO U2F”)。 Yubikey U2F是這種實現的示例。
在通常情況下,蠻力攻擊是不可行的。一種這樣的攻擊是當您知道公鑰時嘗試強行使用特定於源的專用密鑰。當您知道特定於起點的琴鍵手柄時,按下琴鍵(K0)。僅當令牌供應商犯了設計錯誤時,這才可行。例如,當供應商使用相同的內部密鑰運送每個令牌並且密鑰以某種方式洩漏時。
我認為令牌的用戶無法通過按令牌上的按鈕來查看他/她實際上同意的行為是非常糟糕的。否則,在不受信任的公共PC上感染了OS的用戶可以不經意地將惡意程序放到自己的銀行帳戶中,而無需登錄Facebook。
但是,U2F協議包含有關當前操作的信息(URI, AppID和可選的TLS通道ID)。我認為,在開始使用這些設備之前,請先等待帶有小液晶屏的U2F令牌的出現,該小屏幕將顯示這些信息(至少是AppID),然後在發現事實並非如此的情況下允許採取不同意見如您所願。