破解密碼的幻想與現實

先說幾項公事：

• UBR 無條件讀者計畫六月份的合作夥伴為獵人書店，店長文萱為香港選了 21 本值得留存的好書，有意購書捐贈的朋友請到獵人書店，順便看看新店的陳設，好漂亮的說。

• 接二連三偷懶後，讀書會將於七月首個星期一（2024.07.01）台港時間 19:00-20:00 重開，題目為 LikeCoin 3.0 綠皮書的 四 篇 文 章，地點 meet.google.com/tke-...，主要以普通話討論。

以下進入正題。

除了 2FA 雙因子認證，保障資訊安全的另一「低掛水果」是密碼管理器。

如果非得只選用一種保安措施，我認為 2FA 比密碼管理器更重要，不過如果有人不同意我也不會辯駁，反正兩者都很重要，相信大家一定有共識要保障資安，兩者缺一不可。

密碼管理器的三大功能

相信大家都知道密碼管理器是用來保管密碼，不過這個理解並不完整。管理之謂管理，至少得包括三項功能：

1. 儲存密碼；

2. 填寫密碼；

3. 生成密碼。

儲存密碼不用多解釋，就像把一大堆帳號和密碼寫在紙製記事本或數位文檔，替用戶保管密碼，每項記錄通常包括：

• 服務名稱：如 Spotify；

• 網址或應用識別碼：如 https://spotify.com 或 com.spotify.music；

• 帳號：如 alice@gmail.com；

• 密碼：如 csN@^t8u(x0T>.6Gdj.R；及可選填寫的

• 分類、備註等。

除了登錄作業系統、瀏覽器外掛等小量場景密碼管理器無法介入，只要儲存了服務的登錄資料，密碼管理器就能替用戶代勞填寫帳戶名和密碼，不但方便快捷，也更安全。自動填寫讓用戶無需冒著被個別程式偷看剪貼簿的風險「copy」密碼，比如 Tiktok 就曾被揭 iOS 版本每隔數秒讀取用戶剪貼簿，更要命的是，蘋果生態提供「universal copy-and-paste」，當用戶在 iPhone 附近使用以同一 Apple ID 登入的 iPad 和 Mac，連這些剪貼簿的內容都能讀取，直至 iOS 14 加入提示用戶的保安功能，TikTok 才表示剔除該「旨在防止濫發的功能」。讀取剪貼簿的應用畢竟能想出藉口，更壞的是直接置換輸入法應用，方便於用戶輸入時盜取密碼，由密碼管理器填寫密碼，有助避開這種陷阱。

當看到 www.goog1e.com ，一般用戶或許會乖乖送上用戶名和密碼，而沒注意到原來那是盜取用戶密碼的釣魚網站 goog1e.com（是「1」不是「l」），但密碼管理器就不一樣，只要網址對不上，即使內容與串法看似一模一樣，也不會提示用戶填上帳號和密碼，因此除了防止被木馬程式偷取密碼，由密碼管理器代勞也能降低被釣魚的風險。

除了儲存和填寫密碼，有些人會忽略密碼管理器生成密碼這重要功能。我有一位朋友，即使被說服使用密碼管理器，卻只採納前面兩項功能，而保持自己沿用多年的「密碼生成心法」，深信心法揉合了幾項秘密和邏輯，只有他能推敲出密碼，別人無論如何猜不出來。我雖然不敢苟同，當下也沒爭辯，畢竟友人至少踏出了第一步，假如操之過急，非得讓他一下子改變幾個使用習慣，結果可能逼得他乾脆不用密碼管理器，適得其反。

網站數據外洩，用戶躺著中槍

你一定在電視劇看過類似的狗血劇情：Bob 想駭進 Alice 的電腦，試了幾次密碼不對，最後在案頭看到某件擺設，靈機一觸，猜對 Alice 的心思，成功破解密碼。

現實上，除非 Alice 的密碼十分兒戲，否則 Bob 可不會使用「人肉攻擊」，而較常以電腦作「字典攻擊」（dictionary attack）或「蠻力攻擊」（brute-force attack），前者是以字典收錄的字詞及各種搭配推測密碼，後者更加簡單粗暴，不管三七廿一，恃著一秒鐘能猜大量組合的強大算力，窮盡各種可能性至猜對為止。友人自設密碼時想像駭客如何破解是一個電視劇畫面，真有駭客要破解的話，卻很可能是截然不同的畫面，跟以甚麼「秘方」生成密碼，沒有絲毫關係。

以上兩種情況，只要有良好資安意識，交由密碼管理器生成、儲存和填寫夠長、夠隨機、夠混雜的密碼，基本上就能避免。至於多長的密碼才夠保險，專家有著各種建議，有些說起碼 8、最好 10 字符，另外 12、16 字符等長度全都有人提倡；我雖不是專家，不過也有不管學術但求實用的建議：盡可能長，比如 20、30 甚至 40，反正都交由密碼管理器代勞，又不用自己背誦和填寫。唯一麻煩的是有些服務，尤其銀行和政府等老牌機構，往往不厭其煩地提醒用戶資安很重要，但同時把密碼的長度限制得很短，甚至禁用某些特殊字符等，遇上這種讓人氣結的情況，唯有在系統的限制下設定最佳密碼。

還有一種密碼被破解的原因，是服務供應商數據外洩（data breach），用戶躺著中槍。雖然這種情況防不勝防，但只要帳號加入了 2FA，就能避免該帳號被入侵；另外，以密碼管理器為每一個服務生成獨立密碼，避免重複，則可確保即使單一服務的密碼外洩，也不致連累其他服務，再次說明 2FA 和密碼管理器的重要性。

大企業比你想像中兒戲

千萬不要以為有個漂亮的網站就是大企業，也不要假設大企業就很著重資安，滴水不漏，事實上，數據外洩經常發生，Apple、Google、Microsoft 等全部都曾經中招，Facebook 更至少七度洩漏用戶資料，比如 2019 年曾漏出電話號碼、出生日期、位置等，超過五億用戶的個人資料。

數據外洩雖然不一定包括密碼，即使有通常也是密碼的雜湊值（hash），但也提供了不少私隱方便壞人釣魚。雜湊是個數學函數，把密碼用作參數，得出的結果就是雜湊值，一般都是單向，即不存在另一個可以反過來以雜湊值為參數，推算出原來密碼的函數。換言之，假如 alice@gmail.com 的密碼是 apple，bob@gmail.com 的密碼是 banana，服務的用戶密碼檔大概長這樣：

alice@gmail.com   3a7bd3e2360a3d29eea436fcfb7e44c735d117c42d1c1835420b6b9942dd4f1b
bob@gmail.com    b493d48364afe44d11c0165cf470a4164d1e2609911ef998be868d46ade3de4e

以上例子為 SHA-256，即比特幣挖礦需要用到的雜湊函數，有興趣可到這裡分別輸入 apple 和 banana，就能得出以上兩個雜湊值，或者用其他參數測試，觀察變化。在實際應用中，生成密碼雜湊最好能用上比 SHA-256 更強的函數或者「加鹽」（salt），即在原密碼加上特定字串才放到函數生成雜湊值，提高逆向找出密碼的難度。作為用戶的我們，掌握以上概念就夠，請勿擔心接下來的技術含量越來越高，反正我也是「有限公司」，只略懂皮毛。

把用戶密碼以雜湊儲存而絕不使用未經加密的明文，是服務供應商最為基本的資安措施，否則即使數據沒有洩漏，光是內部員工可以把用戶的密碼看光光，就已經是極之嚴重的漏洞。偏偏，「大名鼎鼎」、「重視用戶私隱」的 Facebook 又曾犯上這種低級錯誤，於 2019 年發現誤以明文儲存用戶密碼，紀錄遠至 2012 年，影響二至六億 Facebook 與 Instagram 用戶，由於集團含糊其詞，準確數字與影響範圍無從知曉。自爆此事以求軟著陸的公告題為 Keeping Passwords Secure，以跟「朋友」分享生活日常的語氣，輕描淡寫表示用錯了明文存密碼，反過來提醒用戶注意資安，叫人不得不佩服 Facebook 的公關手段。

Facebook 尚且這樣，其他不在公眾視野的服務就更不好說。總之，包含密碼在內的數據外洩相當普遍，在互聯網混久了多半曾經遇上，建議定期使用 ‘;–have i been pwned? 網站，查看日常註冊帳號用的郵箱有否遇過數據外洩；如果你曾經「一個密碼走天涯」，也可以在此查詢該密碼有否出現在歷史上有紀錄的密碼外洩事件。少不更事的我，使用一組郵箱和密碼註冊無數網站，遇過 24 次資料外洩，密碼出現在外洩數據共 42 次，你呢？

除非你打算在網上任人魚肉，否則密碼管理器必不可少。雖然我反對被平台綁死，不會推薦內建於作業系統或瀏覽器的密碼管理器，但相對於完全不用，內建就內建好了。如果願意多走一步，請安裝第三方提供的密碼管理器，比如我選用的是 Proton Pass，除了因為程序開源、公司的往績、端對端加密，也喜歡它的「法外分身」功能，讓用戶生成無限郵件地址註冊不同服務，進一步保障私隱與安全。我習慣也鼓勵大家付費予高質內容和完善服務，Proton 也不例外，不過，即使是免費版，Proton Pass 的功能也相當完善。

最後，由於保護密碼管理器本身也得用到密碼，而邏輯上不能依賴密碼管理器自己去儲存，用戶需要以其他方法保存該密碼；建議生成一個強密碼用於密碼管理器本身，刻意讓登錄經常過期而需頻繁輸入該密碼，直到深印腦海，輸入手勢變成反射動作，就能透過牢記一個強密碼去管理所有密碼。

p.s. 上期週報的後半部問到我的 Substack 帳號算不算雙因子認證，我強詞奪理企圖引起討論不果，本文不再故弄玄虛，已乖乖道出關鍵所在。

Original link: chungkin Express