題:
我應該使用哪種類型的密碼作為密碼？
Chris
2015-10-29 18:20:08 UTC
view on stackexchange narkive permalink

我有很多帳戶，直到不久前，我對所有帳戶都使用通用密碼。現在，根據登錄的網站名稱，每個帳戶都有不同的密碼。我使用的是模式，模式之間的區別是網站域名。

我不想將密碼存儲在某種密碼管理器中。我只想記住一個模式，並根據密碼來設計密碼（以及一張紙，可以藏在房子安全的地方，以防萬一我很笨而忘了該模式）。

  1. 您能建議我一些好的模式嗎？因此，我可以選擇其中的一種或多種密碼以使密碼更好。

  2. 有沒有更好的方法來存儲密碼，但是如果您需要登錄，仍然可以訪問密碼從另一台計算機/設備？（我真的不信任密碼管理器）

    3. ol>
*您不信任密碼管理員的具體*什麼？如果您澄清這一點，我們或許可以緩解您的擔憂，或者*建議一種方法，該方法意味著特定的問題不是重大問題。
@MichaelKjörling我不知道密碼管理器是如何製成的。這就是為什麼我不信任他們。但是現在我正在閱讀有關它們的信息，也許我會選擇其中一個。
我希望有一個答案不是那麼嚴厲。我可能真正關心的任何地方都有5個帳戶，並且我已經記住了它們的唯一密碼。我有大約5000個隨機帳戶，我擁有用戶名（在我的電子郵件歷史記錄中），但忘記了密碼，因此每次都重新設置密碼。然後，我有大約50個我偶爾使用的帳戶。知道這些站點的“公式”將非常方便。 [被熊追趕時，我只想跑得比另一個傢伙快。]（http://bit.ly/1Oaeg4l）
克里斯蒂（Cristi），認為密碼管理器是專門為安全地管理密碼而寫的。這是針對特定工作的專用工具。實際上，這極大地降低了複雜性，從而降低了錯誤蔓延的可能性。（當然，它仍然可以發生，但是軟件越少打算執行的可能性就越小。）
在某人的某處是否沒有文章基本上是記住一個哈希方案+ salt然後僅將網站域+ salt作為他在每個服務上的密碼？現在找不到該文章，但聽起來確實與您想要的非常相似。我確實記得它需要大量記憶。
有時，這與信任無關，而與政策有關。我必須記住的大多數密碼是用於工作，銀行和金融以及政府站點。所有這些（a）都制定了禁止存儲密碼的策略，從欺詐的有限責任到簡單地被開除，（b）對於更改的頻率，內容和模式（最難記）具有最荒謬的規則。因此，有時密碼管理器是不可能的，而模式是唯一的方法。
我認識的某個人的日記中都手寫了她的所有密碼。
如果您擔心它的製作方式，請獲取PasswordSafe或其他開源管理器的源代碼並自己製作。
@detly您不能為錯誤的系統創建良好的規則。如果您必須遵循的規定不好（按照您描述的方式），則無法使用“良好”模式來“修正”它。
您的大腦可以有效思考和記住絕對的* NO *模式，同時還可以成為抵禦當今所有現代密碼破解者的優質而強大的密碼。
KeePass是開源的，免費的。 http://keepass.info/download.html
@detly等待，即使在適當的密碼管理器中，您也無法存儲密碼，但是它們也必須無法記住，而且其中有很多？
@BlacklightShining ...對任何人來說，公司/財務密碼策略是愚蠢的消息嗎？
@Stephane對，這意味著您也不能使用密碼管理器來“修復”它。
令我感到沮喪的是，但這似乎是本網站上的一種常見模式，即堅持不理會人們認為不好的政策，而這確實是很多人需要談判的事情。我認為這些策略而不是差的技術水平是大量安全問題的根源。如果人們能夠以更好的方式幫助他人使用“不良”系統，那將是很好的，即使它不是完美的。 （我保證大多數閱讀此書的人自己都會受至少一項這樣的政策的約束，並且已經以某種方式越過了它。）
不確定由20個均勻隨機的十六進製字符組成的字符串是什麼問題。簡短而甜美。我保證，記住起來比看起來容易。您不是猴子，您可以記住它，即使需要也可以記住其中的幾個（因此您可以在密碼管理器中使用一個，然後在側面使用其他幾個）。作為交換，您將獲得一個帶有80位熵的好密碼（不多也不少），在可預見的將來，這對於所有基於脫機的蠻力攻擊或字典攻擊都是完全安全的。結束。無需費勁地使用moronic密碼策略。
@detly非常感謝您的觀點，但是很遺憾，我不能出於兩個原因：1 /試圖“修復”這樣的系統只會使其看起來更牢固2 /修復它的責任不在於用戶問a，但人們制定政策。如果最終用戶嘗試修復它，則實際上冒著與這些決策者背道而馳的風險。
@detly如果您使用正確保護密碼的密碼管理器，這絕對不會增加您的責任，因為這樣做是適當而合理的事情。記住不多的密碼是不會重複使用，定期更改和未寫下來的，任何要求您這樣做的策略都是不現實和不合理的，並且在任何法律情況下進行測試都將被視為如此。
十 答案:
Stephane
2015-10-29 18:32:37 UTC
view on stackexchange narkive permalink

無。使用密碼管理器應用程序為每個站點生成長而隨機的密碼。

確保您未在其他任何地方使用主密碼（或主密碼的派生）。

如果您不信任在線或商業密碼管理器，請使用開放源代碼並且可以處理本地文件的密碼管理器。

編輯：供參考，Bruce Schneier在2014年發表了博客文章相當完整（而且很容易理解），為什麼使用任何一種模式生成密碼都是一個壞主意。

您信任在線或商業密碼管理器嗎？
定義信任...但這是非常主觀的，非常類似於對任何其他商業安排的信任。如果您真的很在意，請編寫自己的文檔或找到一個開放源代碼，然後在使用前可以進行分析，但是像在任何行業中一樣，都有許多通常受信任的提供程序。
那篇博客文章仍然有爭議。 Schneier忽略了單詞與字典之間以及字符與字母之間的關係的對等關係。將每個字符或單詞視為一個數字，直到字母或詞典中包含的限制，然後形成一個密碼作為這些數字的序列。弱密碼只是從太少的一組（或公共子集）中選擇了很少的元素。
“長而隨機的密碼”不是另一種模式嗎？
@ott-不。它是一個長隨機密碼。隨機=無模式。
@Cristi我相信流行的開源密碼管理器。為什麼？因為我知道有些人比我更偏執，並且有更多的空閒時間對代碼進行檢查而變得偏執，所以他們一發現就立即大喊“ Illuminati”或“三封信”。我相信別人的偏執狂大於我對Ashley Madison帳戶的安全需求。 -等等，我是在公共頻道上說過嗎？別管我！你看！ Illumnati正在接管政府*消失了* *（如果密碼非常有價值，那麼我什至不信任任何東西，即使我的PC也是如此）*
我不相信博客文章對XCKD文章的評論-由於該文章*假設*黑客知道了您的模式，並且它仍然更加安全。
-1
-1
@Kevin根據XKCD計算，每個單詞加11位熵。無論使用哪種技術，這都將使開裂時間增加約2000倍。
@Kevin是的，儘管我仍然認為Heartbleed對我的傷害還不足以保證消除偏執狂-偏執狂。辛苦了那些傢伙很擅長！ （實際上，MySQL緩衝區溢出確實使我更加不安，該溢出實際上已在代碼中正確捕獲，但是編譯器正在優化檢查！）
@CortAmmon:他們非常擅長於此，而對於OpenSSL，基本上不是。在理想的世界中，您將以任何方式審核您依賴的每段代碼。當然，這將是非常昂貴的，因此您必須妥協並且僅審核最有可能引起問題的x％。但是我仍然認為重要的是要意識到這些折衷，這樣在發生Heartbleed之類的事情時，您就不會措手不及。
@Kevin公平的課程足以學習。當然，這並不意味著我要製造自己的錫紙帽子。大眾街上的傢伙使他們比我好得多。
布魯斯的建議很奇怪，他避開了密碼短語，但支持縮寫的密碼短語。
@PaulDraper這有什麼奇怪的？一個“真實”單詞的熵要比（一個很好的）縮寫詞的熵少，因為它來自可能較小的列表。
因此，如何使用密碼管理器使用庫中的計算機登錄到庫Web服務？除圖書館Web服務帳戶外，我不信任計算機。
@JiK:有智能手機的密碼管理器，因此您只需要在圖書館計算機中輸入圖書館的Web服務密碼即可，而無需其他任何操作。 （下一個問題：我可以信任我的智能手機的操作系統提供商嗎？）
@JiK如果您不信任系統，請不要使用它登錄您的帳戶。此外，在某些情況下，您可以使用[InputStick]（http://inputstick.com/index.php/en/）之類的設備。我用它來物理登錄我們DC中的服務器（我信任但無法訪問我的PW管理器的計算機）
@Stephane藍牙不是無可救藥的嗎？只需輸入。
商業與開放源代碼是一個有爭議的問題，但是任何允許您重置主密碼的在線PM都可以訪問所有密碼並可以與攻擊者共享。
我不會說“絕對不安全”，但是，對於InpuStick，您可以在USB設備和智能手機之間的通信中添加AES加密：這使其非常安全。
@AleksandrDubinsky不一定：有些方案允許更改主密碼而不要求共享。請注意，這並不意味著您不必對服務放任信任。這實際上是便捷與安全的選擇。
@Stephane這怎麼可能？您是專門指“不需要共享主密碼”還是更一般地說“不讓密碼管理員一時興起地讀取密碼”。
@MarchHo是的，那是2048個單詞的集合-您可以將其顯著增大，並且仍然會令人回味。
@Stephane: Schneier的觀點不只是關於熵。如果可以量化“ Schneier縮寫”添加到短語的熵的數量，則該方案具有與使用未縮寫的短語相同的熵，並在末尾粘貼相等數量的隨機生成的字符。但是他不僅僅對熵感興趣（無論如何，整個問題是人類對N個密碼記住的熵不夠好）。他特別感興趣於生成密碼短語，該密碼短語會打敗已知的猜測算法，從而勝過其形式熵。
@ChristianStrempfer-不，“下一個問題”是什麼，當我將手機放在廁所里而無法訪問密碼管理器數據時，會發生什麼？
@T.E.D。，您已在雲上同步了密碼數據庫（由於已加密，因此沒有任何區別）
@SteveJessop我不知道密碼如何能勝過其形式熵。根據縮寫詞創建的10個字符的密碼（大寫/小寫和數字）的大小寫為ca。 60位熵。讓我們假設此架構確實提供了完全隨機的密碼。破解者平均需要嘗試（2 ^ 60）/ 2個密碼，因為它是完全隨機的。 5個單詞的完全隨機Diceware短語為8192 ^ 5，即。 65位熵，因此攻擊者需要嘗試（2 ^ 65）/ 2個單詞組合。攻擊者可以採取哪些捷徑來減少這種組合數量？
@oliver:，如果生成的密碼的熵少於40位，但實際上並沒有出現在任何現實密碼破解者嘗試的前萬億個密碼中（根據Schneier使用的模型），它的性能將超過您期望僅基於熵。 Schneier對“ Schneier縮寫”的主張是，密碼破解者不善於解決熵N的縮寫，而不是解決熵大於N的“密碼加隨機疣”。不幸的是，他實際上並沒有說*如何*大得多，或者他認為足夠的熵。
因此，例如，我記得多年前施耐爾（Schneier）這種建議的最早版本是，將一個隨機插入的句子插入一個令人難忘的句子中比在一個句子的結尾處插入更好，因為他觀察到了餅乾當時正在嘗試添加垃圾郵件的字典單詞和短語，但沒有插入垃圾郵件。兩種方法的熵都是相同的（好，選擇插入點時要加上或減去幾比特），但是那時插入的垃圾基本上勝過附加的垃圾。
...當然，如果您可以記住65位隨機密碼，那麼您也可以這樣做。密碼短語，以及如何使它們顫抖以使其抵禦餅乾的攻擊，對於那些嘗試過但由於需要知道的獨特密碼數量而失敗的人們來說是一種遊戲。
關於Bruce和XKCD的@Tim：https://security.stackexchange.com/questions/62832/is-the-oft-cited-xkcd-scheme-no-longer-good-advice
@AleksandrDubinsky我無法告訴您具體的ATM，但是我收集了最後一次傳遞的哈希密碼，以確保安全。我不記得他們是否允許您恢復它。
JonnyWizz
2015-10-29 21:04:50 UTC
view on stackexchange narkive permalink

如果您不信任密碼管理器，則不必將整個密碼存儲在密碼管理器中。

您可以將密碼拆分成易於使用的密碼記住您記得的部分（如果需要，對於所有網站都可以相同），以及密碼管理器中唯一且長而隨機的密碼。

如果有人能夠以某種方式訪問您的密碼管理器，他們將仍然沒有記住的一部分密碼。

“您容易記住的部分” –甚至很難記住的部分，是您在記憶中付出了一些努力。由於所有密碼都相同，因此您只需要記住一件事（再加上一件事：密碼管理器的密碼）即可使用。 10-20個隨機字符不一定“容易記住”，但是我每天都可以使用它來管理密碼，而作為一個非常安全的下限，則需要2> 50個猜測才能通過蠻力破解。
好吧，“更容易記住”是相對的。這比將要存儲在密碼管理器中的非常長的隨機字母/數字/符號部分要容易得多，但是鑑於您現在只需要記住兩個密碼（一個用於密碼管理器，另一個用於重用並添加到密碼管理器中）。 （如果您不使用密碼管理器就必須記住很多密碼，則可能比“密碼管理器”更難記住）。
請記住，（太多）網站限制了密碼中的字符數和/或可供選擇的字符集（可以在[here]（http://passwordshaming.tumblr.com/上看到令人恐懼的示例） 。這可能與建議的方案相衝突：您要么必須選擇一個非常短和/或簡單的通用部分，要么可能會偏離您的方案（並將某些站點的完整密碼保存在管理器軟件中）。
不過這很不方便。每次您必須登錄網站時，都必須查看密碼管理器，複製部件，然後附加部件，然後“登錄”。這麼多工作。
這樣的缺點是，如果密碼洩露（因為有人以純文本形式存儲了密碼），則記住的部分將受到威脅。（這是一個問題，如果由於長度太長而將隨機部分縮短以允許添加記住的部分，則會成為問題限制等）。
@GertvandenBerg,，但是他們怎麼知道您使用的是拆分密碼的方案？
@JonnyWizz: Hack兩個站點並註意到匹配的部分嗎？ （儘管不太可能使用自動破解...）安全性不應僅基於攻擊者不知道系統如何工作的假設……（這並不意味著當很少有人攻擊時，它就無法工作。那樣做...）
好吧，在不太可能的情況下，這樣記住的部分被破壞了，由於攻擊者只知道記住的部分，因此密碼管理器中的其餘密碼仍然是安全的。
我想有一個真正的風險，那就是，如果您不信任密碼管理器，那麼您可能不應該假定它沒有記錄您的擊鍵來捕獲記住的部分。從根本上講，您不能在用於登錄帳戶的同一設備上安裝不受信任的軟件（對於“同一設備”的某些值：您可能願意對虛擬化或甚至僅對用戶帳戶進行某些操作，以確保不受信任的軟件在同一設備上，但無法記錄）。
Chris H
2015-10-29 20:04:28 UTC
view on stackexchange narkive permalink

生成隨機數是唯一需要的模式-您甚至可以使用骰子（Wikipedia），或者獲取較短的隨機字母字符串（再次是Wikipedia）。

如果您不想忘記它們，並且不信任密碼管理器，請 寫下來！（Schneier.com）。我會在這裡考慮某種形式的混淆處理，以使隨便的小偷偷竊您的錢包不能僅​​僅登錄到您的Paypal帳戶（例如），即使這樣做很難。

通過簡單的混淆，您可以簡單地將密碼“移”下2或3，以便在用戶名旁邊看到錯誤的密碼，例如： http://paste.ubuntu.com/13005200/
如果可以使用@Tim,，那麼，如果使用隨機的字母數字字符串，則其他想法可能會交換字母的大小寫（也許僅在密碼的子集中）。
是的，另一個好人。我個人對更改密碼本身非常小心-像回寫一樣，因為我發現自己偶爾會忘記...實際上我有一個密碼管理器。
我也是@Tim（或者我正在與Linux上的KeePass2 / KeeFox戰鬥）
@Tim儘管嘗試使用數據庫中的每個帳戶嘗試數據庫中的每個密碼，但攻擊者可能會首先嘗試這樣做。那或者只是將數據庫用作針對被盜哈希的單詞表。
@Blacklight產生混淆的前提是我們不使用手寫列表，因此，竊賊（或“知道計算機”的好友）必須將它們全部鍵入一個文件並編寫一個腳本，假設不只少數幾個密碼當然。
zr_ifrit
2015-10-29 19:28:38 UTC
view on stackexchange narkive permalink

1）如果您不信任在線密碼管理器，則可以使用keepass2之類的離線管理器，但是您必須無論如何都可以訪問您的文件，否則就會出現漏洞。如果您真的不想信任密碼管理器，請學習密碼。

2）有幾種類型的模式可用於生成密碼。它們並不總是安全的，因此生成的更好。關於此主題的文章已在NakedSecurity 此處上發表，它們提出了不同的可能模式。

密碼文件的可訪問性無關緊要。它可以完全公開，因為它是加密的。弱鏈接信任*您輸入主密碼對其進行解密的計算機。*
Tomas
2015-10-30 00:13:59 UTC
view on stackexchange narkive permalink

我想請您參考此XKCD：

enter image description here

如果您添加例如像這樣的密碼末尾添加一個站點名稱（現在不要使用“ correcthorsebatterystaple”），這將非常安全。

真正重要的是長度。因此，如果它很長很容易記住，那就太好了。

如果密碼管理器遇到問題，建議：將密碼管理器文件存儲在Dropbox之類的東西上。這樣，您可以從任何地方訪問它，而且仍然安全。

模式可以通過（至少）兩種不同的方式來削弱您的密碼：最差的模式會使您的個人密碼更容易被破解，而可識別的模式（簡單或其他方式）將使得在第一個密碼之後的後續密碼更容易被破解。此策略可避免掉入第一個陷阱，但是除非您也更改4字庫，否則將成為第二個陷阱。假設您在次要站點上的密碼中至少有一個已經被破解-“ correcthorsebatterystaplebank”可能是安全的，但是如果黑客已經擁有“ correcthorsebatterystaplestackexchange”怎麼辦？
和Dropbox一樣安全...
-1
@Tomas由於打開嘗試的次數不受限制，因此DropBox的安全性可能至關重要。有權訪問您的保管箱的人可以訪問您的加密文件。然後，他可以嘗試對主密碼進行暴力破解攻擊。如果主密碼很長很複雜，這並不構成很大的風險，但是仍然有風險。
-1
44位的熵太低。密碼不會以1000次猜測/秒的速度破解，有時會以1萬億次猜測/秒的速度破解，這將在16秒內破解密碼。
@AleksandrDubinsky請不要誇大，我假設您來自美國或英國，兆兆表示1,000,000,000,000。這意味著即使密碼哈希僅執行1次操作，也將需要1THz的處理能力。假設大多數非國家資助的破解都是通過殭屍網絡完成的，那麼這相當於200個殭屍2核CPU以2.5 GHz的頻率運行（來自Steam硬件調查的平均值）。並非沒有，但代價昂貴。但這是假設每個哈希有1條指令，例如在使用帶有2 ^ 12輪的BCrypt時，它會變得非常昂貴，這似乎經常使用。但是可以肯定的是，更好。
@AleksandrDubinsky好吧，在混合物中扔幾個，它彈出到36²⁵，這需要*一點點*才能超過16秒。如永遠。
如果您使用Incorrectcowcapacitornailwebsite，則您的密碼將是*托特**安全的。
@Selenog您的硬件知識不足。 GPU可以在每個時鐘週期執行8,000次操作，但這並不重要。典型的散列以每秒數千億次嘗試的速度被破解。 ASIC的性能要好幾個數量級-比特幣鑽機可以用更少的電量完成[每秒8萬億次SHA1哈希]。民族國家肯定已經建立了類似的ASIC來破解密碼。沒錯，bcrypt或至少使用多個回合會更好。我確實使用過“有時”這個詞。但是今天，快速/弱哈希是非常常用的。
@AleksandrDubinsky誰說它必須是SHA1？甚至沒有一個單獨的脫機密碼管理器使用它作為其加密密鑰？我對此表示懷疑。
@Tomas 36 ^ 25適用於25個隨機字母數字字符。 25個字符的密碼短語不是一組隨機字符。它的熵要少得多。不要在這裡開玩笑。甚至沒有在這裡閱讀過您的帖子的黑客都知道，比如說，您有10％的機會採取“挑四個字並扔幾個數字”的策略，因此您最多可以添加3位熵因為他不十分確定自己的策略。
@Tomas密碼管理器通常會使用像SHA1這樣的快速哈希，但是會在多個回合中使用它，這會增加10-20位的熵。但是，如果在每個站點（如OP預期的那樣）上使用這樣的密碼短語（加上網站名稱），並且其中一個站點使用單回合SHA1（足夠多的話），那麼這就是您最薄弱的環節。
@AleksandrDubinsky * 25個字符的密碼短語不是一組隨機字符。它的熵要少得多。您只是想“贏得”討論？
@AleksandrDubinsky *密碼管理員通常會使用像SHA1這樣的快速散列*您怎麼知道的？例如，KeePass使用AES。
@Tomas AES用於加密。 AES使用的加密密鑰不是您的密碼。該密鑰是通過哈希函數從您的密碼派生的。如此處在[密鑰派生部分]（http://keepass.info/help/base/security.html）中所述，此哈希函數是SHA-256，加上N輪帶有公鑰的AES（好的，所以它使用AES進行密鑰派生）。默認情況下，N等於6000。 SHA1都不是，但是SHA2和AES都*像* SHA1一樣快。 KeePass不使用bcrypt或scrypt。
@AleksandrDubinsky讓我給您一個提示：[破解keepass主密碼有多難？]（http://security.stackexchange.com/questions/8476/how-difficult-to-crack-keepass-master-password）。
特別是對於KeePass的@Tomas，我發現了[一個程序]（http://sourceforge.net/p/keepass/discussion/329220/thread/ab72879e）。它只能進行1000次猜測/秒，但是它是用C＃編寫的。如果可以為GPU有效地重寫它，我希望至少有1,000,000。 44位代碼大約需要3個月的時間。不是即時的，但過於舒適。
@Tomas該問題的提問者建議使用66位密碼（即，比您的密碼複雜4,000,000倍的密碼），而應答者沒有聽說過GPU。不要使用“讓我給您提示”之類的短語。你真沒禮貌
用於密碼的@Aleksandr Dubinsky哈希函數應經過多次處理，以使它們在GPU上效率低下。這是因為服務器往往沒有GPU，所以為什麼要給攻擊者以優勢。還有其他方法可以使它們在GPU上的效率低下。
@Selenog使用多個回合不會影響GPU效率。在GPU上效率低下的哈希函數會佔用額外的內存。但是，多次使用低內存，快速哈希函數不會對GPU造成問題。與CPU一樣，GPU的速度降低了N倍，但仍保持領先優勢。
-1
在實踐中，密碼短語似乎並沒有您所相信的那樣幫助XKCD：https：//dl.acm.org/citation.cfm？id = 2335356.2335366
Gert van den Berg
2015-10-29 20:47:53 UTC
view on stackexchange narkive permalink

您可以使用基於哈希的密碼生成策略。您可以將主密碼與網站名稱（及其複雜性要求）結合使用，以生成該網站唯一的密碼。

與密碼管理器相比，它有一些優點和缺點：

  • 沒有可以丟失/被盜和攻擊的加密數據庫
  • 您需要記住用於使該方法適用於具有不同複雜性要求的站點的設置
  • A實施不佳，例如從md5哈希中獲取8個字符會大大減少密鑰空間。
  • 在被迫更改密碼的情況下很難處理

可以使用的一些工具：

  • 常規哈希函數（應避免使用），例如此處提供的示例（該帖子也具有該方法的優點和缺點）
  • 自動化該過程的工具，例如 supergenpass（基於MD5默認值（這不理想），如果攻擊者知道生成的密碼+站點名稱，則較慢的哈希值會使恢復主密碼的操作更加棘手。強制）（其他存在的密碼，例如主密碼，請參見下文）

（通過Matty：主密碼似乎比使用任何一種更好的方式生成密碼其他人之前提到的）

其他一些示例包括http://plevyak.com/dpg.html（可能基於更好的哈希值，但像bcrypt，PBKDF2或scrypt這樣的故意慢速的東西仍將具有其優勢）
這是一個有趣的方法。它的主要優點是您無需跟踪文件（不必擔心丟失）。但是，它並不更安全。如果以前以前攻擊者需要掌握文件才能開始破解，那麼現在他只需要掌握您的密碼之一即可。
對於他們不斷讓您選擇新密碼的網站（因此，網站名稱），您可以將其記錄在純文本文件或筆記本中。該策略將仍然有效（如果主密碼足夠安全）。
哦，您也不必拘泥於單個應用程序，因為沒有文件格式需要擔心。哈希生成器甚至可以作為Javascript頁面使用。
這是“密碼管理器” http://masterpasswordapp.com/中使用的策略。更改密碼很容易，它們只需在主密碼和您每次需要更改密碼時增加的站點名稱旁邊使用一個數字即可。
@Matty:似乎是一個非常不錯的開始……（櫃檯上：您仍然需要跟踪它們……）
@AleksandrDubinsky:它消除了密碼管理器的許多弱點，除了主密碼外，而是引入了一些新的弱點。 （真正的問題是，我們首先需要跟踪數百個密碼，這很難解決，OpenID使其更好一些-我可以使用我的Facebook帳戶登錄此處，但這仍然是一個問題）
我意識到了陷阱。您無法更改主密碼（不更改所有密碼）。
WBT
2015-11-02 10:13:40 UTC
view on stackexchange narkive permalink

使用密碼卡。
這裡是一個示例：

使用密碼卡，您可以選擇起點和路徑那裡（上，下，左，右，對角線或某種組合），並記住這一點。 （或者，每個密碼有多個起點和路徑。）您不必信任軟件密碼管理器，因為紙卡是您的密碼管理器，而底部的哈希是“主密碼”。您仍然必須與經理分開跟踪一些信息（起點和路徑），因此即使您丟失了錢包，密碼也不會消失。

從他們的網站“享受您的新安全感和內心的平靜……:-)”。聽起來像[安全區]的定義（https://security.stackexchange.com/q/173943/149193）。
Paul Walker
2015-11-01 03:48:40 UTC
view on stackexchange narkive permalink

我認為“離網”（ https://www.grc.com/offthegrid.htm）可能滿足您的要求。它基於隨機生成的網格和基於域名的方法來從中生成密碼。該站點上的頁面描述了使用網格的“標準”方式，但是也有關於如何調整網格的建議，因此，即使有人掌握了網格並知道“標準”方法，他們仍然不會能夠算出您的密碼。

Ken Brockert
2015-10-30 19:17:15 UTC
view on stackexchange narkive permalink

我喜歡使用電影中的流行語錄。我將每個單詞的第一個字母轉換為不同的大寫字母，小寫字母，符號或數字，並嘗試使用每個字母的4個並保持不同。

'What'ain我從來沒有聽說過，他們會用“什麼”說英語嗎？

變成“ W @ 4c！3％7D ^ S9Iw？”。我喜歡在少量的符號和字母上打上標籤，如果它太短的話我會記得。像456一樣，每隔一個班次“ W @ 4c！3％7D ^ S9Iw？$ 5 ^”

我無法想像這比使用引號本身要好得多。如果您從一組作品中隨機選擇句子，那並不會太糟糕，但是由於您使用的是_popular_引號...
它也不能解決為不同站點記住不同密碼的問題。
對我來說，它有點像一個記憶宮殿。我沒有將房間與要記住的東西相關聯，而是將電影和報價與服務器或網站相關聯。它幫助我記住更長更強的密碼及其用途。
我相信這種技術現在已經在密碼破解者中使用了...
sayan
2015-11-01 09:46:14 UTC
view on stackexchange narkive permalink

我要做的是使用一個複雜的基本字符串作為密碼，例如 AdasfbkSDUn7657AJDadadsag ，然後使用網站（我將為其創建密碼），然後將其名稱附加到開頭。如果記住密碼似乎令人生畏（應該使用 離線 密碼管理器）。

- www.website.com 

  web_AdasfbkSDUn7657AJDadadsag
的示例密碼


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