題:
無狀態密碼生成器的缺點是什麼？
Cookiecutter
2019-07-30 00:13:01 UTC
view on stackexchange narkive permalink

是否有人有像 Getpass這樣的無狀態密碼生成器（管理器）的動手經驗？

似乎它完成了云密碼管理器的大部分工作，但是精益在安全性方面要付出更多的努力，因為沒有服務器可以穿透密碼。

有很多使用本地存儲的密碼管理器。您可以使用自己選擇的雲服務（Dropbox，Box，iCloud，Drive，OneDrive等）同步或完全不同步。由你決定
“更傾向於安全方面” –這不是一個公平的評估。它們全都靠安全方面-這種工具具有減輕一種風險的功能。
如果不依賴狀態，它依賴什麼？是否包含漏洞？
我使用keepass。優點之一是它不只是存儲我的密碼。我可以存儲有關某個帳戶的許多其他數據，包括“附件”。顯然，無狀態密碼管理器不能用於除密碼之外的任何東西，對我而言，這是一個很大的限制
@Alexander Dropbox最近更改了免費計劃，將其限制為3台設備，它過去非常適合同步Keepass。iCloud僅是蘋果，Google Drive是Meh，OneDrive是基於Microsoft的。
@JMK還有mega.nz（所有者過去曾被FBI燒掉並吸取了教訓。現在，這是一種偏執狂的服務，以用戶數據的隱私為中心：他們不想知道您在自己的存儲的內容服務，這樣就不會因為託管它而受到指責。如果他們的網絡搜尋器找到了私鑰，他們會自動刪除關聯的數據，而無需進行調查。）
另外，如果您不信任雲服務，則可以使用Syncthing或Resilio Sync之類的同步程序在設備之間同步本地密碼數據庫（例如，來自KeePass）。
@JMK我設法保留了3個設備，並通過保管箱同步了我的KeePass文件。但是還有另一個缺點：Android客戶端不會自動上傳更改的文件。有第三方的客戶。直到它們破碎。
六 答案:
Benoit Esnard
2019-07-30 00:24:47 UTC
view on stackexchange narkive permalink

多年以來，我一直使用無狀態密碼生成器，但我認為它有很多缺點：

  • 如果您的主密碼被盜，那麼您所有的密碼都會被盜。 / strong>相比之下，標準密碼管理器要求攻擊者同時破壞主密鑰 並獲得對密碼存儲區的訪問權限。
  • 如果網站有密碼政策，則您可以
  • 如果出於某種原因需要更新其中一個密碼，則需要將該狀態保留在某個地方。
  • 例如，您需要記住為“ StackExchange2”而不是“ StackExchange”生成密碼。
  • 如果您已經擁有一些無法更改的密碼（由於各種原因），則使用靜態密碼生成器出於所有這些原因，

我認為您應該最終使用標準的密碼管理器。

謝謝！因此，您切換到標準密碼管理器了嗎？在我看來，可以通過將數據綁定到網站變量來解決除您的最後一點之外的所有問題
無狀態密碼管理器的最大優點是您不必保留額外的文件。如果最終還是必須為所有這些特定於站點的變量維護一個額外的文件，那有點無奈地使用了無狀態密碼管理器。
確實是@LieRyan。通過使用其中之一，您將不得不通過移動文件來在所有計算機和設備之間手動同步。最好的情況是極端繁瑣，最壞的情況是嚴重的安全問題，甚至可能是不可能的（考慮到安全環境中引入外部文件的限制）。
最不利的條件可能是所有人中最糟糕的。最好將其排在首位並進一步強調它，因為人們會使用一些非常糟糕的密碼（也用於密碼管理器），而密碼管理器本身必須受到損害（沒有密碼數據庫，主密碼是無用的），那麼密鑰的妥協將是災難性的，此外，如果任何網站所有者願意，密鑰可以被任何網站所有者強行使用（如果他們對您的密碼哈希設置做出了正確的假設，這在Kerckhoff的原理下並不是秘密）。
-1
我推出了自己的無狀態密碼管理器（https://vks.ai/ppm），但沒有任何問題。只有這樣的事實：如果我的主密碼確實遭到破壞，並且人們對技術的了解足以濫用它。但這是我願意承擔的風險。解決這些問題：到目前為止，我從未遇到過我的方法不符合密碼策略的問題（並且我已經使用了幾年）。關於StackExchange和StackExchange2的最酷的事情是，通常您確實記得這個數字。但是，如果您不這樣做，則可以在3次嘗試中輕鬆對其進行暴力破解（我達到的最高值為5）。
您可能要考慮使用@PascalVKooten進行適當的審核...使用當前的實現，可以在每個站點上設置Rainbow表以破解主密碼
@Qwerty01破解太慢或太昂貴-這就是慢散列函數（如scrypt和較長的主密碼）的想法。這樣可以做到，沒有必要嘗試彩虹攻擊。
@PascalVKooten彩虹表的要點是一次執行昂貴的計算-目前唯一阻止其他人這樣做的事情是因為您的實現沒有被廣泛使用以使其盈利。
@Qwerty01僅在可以重複使用計算時才使用Rainbow表，在這裡不是這種情況。但是請注意，人們不會嘗試為慢速哈希函數創建彩虹表，因為這根本負擔不起。是的，這個主意聽起來不錯...重複使用計算...但是緩慢的哈希函數實在太昂貴了（除非您假設主密碼很短）。
@PascalVKooten可以在實現中重用它...您使用的salt是站點名稱，因此使用該站點的其他任何人都將擁有相同的salt。
@Qwerty01是的，但是鹽的確不是秘密。它完全依靠主密碼來保證安全性。因此，可以說您確實知道我的網站名稱（其他所有人也都使用它），但是您仍然必須進行大量昂貴的計算，這是不值得的。
讓我們[繼續聊天中的討論]（https://chat.stackexchange.com/rooms/96816/discussion-between-qwerty01-and-pascalvkooten）。
回复：第3點，LessPass（另一個無狀態密碼管理器）支持將選項哈希化並用作生成的一部分；一個這樣的選項是可以增加的數字。他們允許您保留用戶名/站點/選項的數據庫，從而解決了“必須記住”的問題，但是密碼生成本身是無狀態的，並且數據庫只是一種便利
*“標準密碼管理器要求同時破壞加密的密碼和主密鑰。” *-我不明白。當然，由於用戶只需要輸入主密鑰（+ MFA）即可訪問加密的密碼，因此必須僅破壞主密鑰（可能還包括任何MFA）。否則，這聽起來像是您使用的標準密碼管理器要求用戶記住其所有密碼才能訪問其密碼。還是您的意思是，攻擊者必須既破壞主密鑰又獲得對數據庫的訪問權限？
@8bittree:如果我告訴了我我的主密鑰，除非您已經可以訪問我的加密密碼數據庫，否則您將無能為力：您無法解密自己沒有的東西。這就是為什麼兩者都是必要的！
@BenoitEsnard此處的困惑可能在於構成“標準”密碼管理器的原因。最好是更明確一些，例如“基於文件的密碼管理器”，以區別於您可以遠程訪問數據庫的“基於雲的密碼管理器”（如1Password）。
@BenoitEsnard這更有意義。我建議進行編輯，使措詞更清晰。
@BenoitEsnard，但是大多數人在每次註冊新頁面時都不會將密碼管理器中的文件手動複製到他們正在使用的所有設備上嗎？您很可能將文件存儲在在線位置，您可以使用主密碼訪問該文件。因此，只有一件事需要妥協，否則您將很難通過USB傳輸文件。
Sjoerd
2019-07-30 13:04:40 UTC
view on stackexchange narkive permalink

以下是兩個很少提及的問題。

  • 確定網站很困難。您想要為a.github.io和b.github.io使用不同的密碼，但是要為microsoft.com和live.com或Wikipedia.org和wikimedia.org使用相同的密碼。
  • 更改任何內容都會破壞密碼。釋放密碼管理器並讓人們開始使用它後，您將無法進行任何更改，或者用戶無法登錄。即使域更改所有權，域的處理方式也必須保持不變。即使算法中發現了漏洞，密碼散列的方式也必須保持不變。

另請參見我的博客文章。

如果發布了可選的新版本，則人們必須在所有頁面上一次更改密碼才能使用新版本。這不會很有趣，但是可以做到。-如果我的基於文件的密碼管理器的masterpassword被盜（由於通常可以在線訪問文件），我可能會做同樣的事情
Kolappan N
2019-07-30 08:47:55 UTC
view on stackexchange narkive permalink

1。密碼管理器提供了其他選項

使用無狀態密碼管理器和密碼管理器之間的主要區別在於密碼管理器可以存儲其他數據，例如

  • 安全性問題
  • 信用卡/借記卡號
  • 身份證號
  • 加密密鑰
  • WiFi密碼
  • API密鑰等等...

2。無法容納現有密碼

密碼管理器可以容納現有密碼。但是，無狀態密碼管理器將強制您更改所有現有站點的密碼。

如果您要為任何無權更改密碼的帳戶存儲密碼，這非常重要。這可以是共享的辦公室郵箱，服務器密碼等...

3。確定性密碼生成器無法適應不同的密碼策略。

某些站點將需要帶有密碼的強制性符號，但是某些站點不允許密碼中使用符號。某些網站（如Payback）僅支持數字PIN。

用戶需要調整生成的密碼或更改設置。無論哪種情況，他們都需要將調整或設置保留在內存中，這是不好的。

對於＃3，您還需要記錄創建密碼時的密碼策略。我至少有一個帳戶的密碼違反了他們的新密碼策略，但是舊帳戶仍然有效。
Daniel Darabos
2019-07-30 20:16:23 UTC
view on stackexchange narkive permalink

除了已經提到的那些問題之外，還有一個問題是您無法更改主密碼。切換到新的主密碼將需要在使用過生成器的所有網站上更改密碼。

MechMK1
2019-07-30 00:45:01 UTC
view on stackexchange narkive permalink

問題在於它並沒有增加太多有意義的安全性。

您可以直接使用公開可用的功能來代替密碼，而不必直接使用密碼。讓我們用他們網站上的示例進行演示：

登錄：andromeda
網站：milkyway.com
秘密關鍵字： 2,52m光年遠

產生密碼： 3q_q（MFWaMGeao + [CX

block> e>

您可能會說 3q_q（MFWaMGeao + [CX 是您的密碼，但實際上不是。它實際上是 2,52m光年遠，不是很熵。它比僅使用 2,52m光年遠要好>？是，但不是那麼多。

相反，請使用脫機密碼管理器並生成一個實際上隨機密碼，這將為您完成大量工作，並為您提供更真實的安全性。

公平地說，距離“ 2520萬光年”本身不是您的密碼。距“ 2.52百萬光年”，加上您使用Getpass的知識。當然，第二個組件很容易被暴力破解，因為它只是前者的一小部分（因為只有少數流行的密碼生成算法
@Alexander https: // zh.wikipedia.org / Wiki / Kerckhoffs％27s_principle
-1“它不會給您提供任何額外的安全性”是不正確的。安全屬性類似於通用客戶端哈希（甚至所有軟件都應執行此操作），甚至比通用客戶端哈希稍強。這不是一個完美的解決方案，但也不是沒有用。
只要您的主密碼非常熵，它就可以為您提供額外的安全性。無狀態密碼管理器可以防止（太常見的）情況，即以純文本形式存儲您的密碼的網站遭到破壞，然後使用相同的密碼登錄您經常訪問的其他網站（是的，密碼重用很差，但是普通人記不起2個或3個以上的高熵密碼）。
@Luc我敢打賭，使用getpass所獲得的安全性遠低於使用實際的隨機密碼。
@James_pic阻止密碼重用**是使用密碼管理器的重點。
@MechMK1是的，只要主密碼具有足夠的熵，無狀態密碼管理器仍會阻止密碼重用。
@James_pic是和否。如果您假設密碼/口令足夠強大而不會被破解，那麼您最好*對所有內容使用該密碼*而不會損失太多。是的，您面臨使用純文本密碼的網站的危險，但是這些網站很快就會消失。即使是最嚴重的罪犯，現在也至少使用MD5。
@MechMK1“ *我敢打賭，使用getpass獲得的安全性遠低於使用實際的隨機密碼。*”這不是賭注，您對此完全正確。隨機顯然比派生更好。但是，答案的“它不會給您增加任何安全性”部分還是不正確的，或者至少比它更細微的差別。使用純文本密碼將使您無法重複使用它。通過發送加鹽的哈希（站點名稱為鹽），您將為每個站點擁有唯一的登錄令牌。比重用密碼更好，因此絕對不要“不增加安全性”。
因此，這就是我拒絕投票的原因，我認為這樣做可能有害，這是錯誤的。某些人可能不想使用密碼管理器（出於超出此註釋範圍之外的原因），但對於無狀態的pwdgenerator可能沒問題。您可能會阻止它們，並基本上告訴他們使用純文本。因此，這不是私人的，並且如果答案被更改以反映這一點（假設您明白我的觀點的邏輯），那麼我也將更改投票（假設我看到了修改內容）。
@Luc我更改了措辭以反映這一點。我說這並沒有增加太多的安全性，但是仍然比使用低熵密碼更好。
Ben
2019-07-31 22:01:44 UTC
view on stackexchange narkive permalink

我還沒有看到另外一個明確提及的內容（在編寫所有現有答案時也很有意義）：

如果攻擊者掌握了您生成的密碼之一，現在他們可以嘗試以此來破解您的主密碼，獲得對 all 您的帳戶的訪問權限。

無論是通過網絡釣魚，明文密碼洩漏（甚至Google顯然也不能倖免），在公用計算機上進行鍵盤記錄，在未使用https的網站上打開WiFi等。使用密碼管理器的全部要點是，一個網站的不良安全性不應在以下方面提供任何優勢：

當然，足夠強大的主密碼可以防止出現此問題。但是“傳統”密碼管理器根本沒有這種攻擊媒介。

+1這是真正重要的唯一缺點。所有其他僅僅是不便之處。
我基本上同意，但是如果主密碼足夠強，並且密碼管理器使用了良好的單向功能（理想情況下是像scrypt之類的密碼散列功能），那麼它應該不容易/不能被暴力破解-力。就是說，這與我們通常在服務器上進行密碼哈希處理的原因相同。唯一的區別是：您控制/知道影響因素，並且可以（理論上）估計暴力攻擊是否成功。


ⓘ
該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到，我們感謝它分發的cc by-sa 4.0許可。
Loading...