先說幾項公事:
UBR 無條件讀者計畫六月份的合作夥伴為獵人書店,店長文萱為香港選了 21 本值得留存的好書,有意購書捐贈的朋友請到獵人書店,順便看看新店的陳設,好漂亮的說。
上週四的漂流教室 #1 有六位讀者到場一起吃麵,為史上最多(i.e. 兩次裡面較多的一次),不算一位 DHK dao 志工,為五位新朋友開了錢包並派出 DHK。今晚(星期四,2024.06.27)18:00-20:00 我將再接再厲舉行漂流教室 #2,地點油麻地美都餐室,封面圖的某張卡座。老規矩,隨緣,不收費,自行在店消費,該店最低消費 35 港元。
接二連三偷懶後,讀書會將於七月首個星期一(2024.07.01)台港時間 19:00-20:00 重開,題目為 LikeCoin 綠皮書的 四 篇 文 章,地點 meet.google.com/tke-dpmc-fxo,主要以普通話討論。
以下進入正題。
除了 2FA 雙因子認證,保障資訊安全的另一「低掛水果」是密碼管理器。
如果非得只選用一種保安措施,我認為 2FA 比密碼管理器更重要,不過如果有人不同意我也不會辯駁,反正兩者都很重要,相信大家一定有共識要保障資安,兩者缺一不可。
密碼管理器的三大功能
相信大家都知道密碼管理器是用來保管密碼,不過這個理解並不完整。管理之謂管理,至少得包括三項功能:
儲存密碼;
填寫密碼;
生成密碼。
儲存密碼不用多解釋,就像把一大堆帳號和密碼寫在紙製記事本或數位文檔,替用戶保管密碼,每項記錄通常包括:
服務名稱:如 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 才表示剔除該「旨在防止濫發的功能」。讀取剪貼簿的應用畢竟能想出藉口,更壞的是直接置換輸入法應用,方便於用戶輸入時盜取密碼,由密碼管理器填寫密碼,有助避開這種陷阱。
當看到 https://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 帳號算不算雙因子認證,我強詞奪理企圖引起討論不果,本文不再故弄玄虛,已乖乖道出關鍵所在。
![highlight](/api/highlight?text=%E7%A0%B4%E8%A7%A3%E5%AF%86%E7%A2%BC%E7%9A%84%E5%B9%BB%E6%83%B3%E8%88%87%E7%8F%BE%E5%AF%A6&author=DHK%20dao&url=%40dhk&avatarUrl=https%3A%2F%2Fstorage.googleapis.com%2Fpapyrus_images%2Fd0018383e486813c84cb0d9ac746e549.jpg&featuredImageUrl=https%3A%2F%2Fstorage.googleapis.com%2Fpapyrus_images%2Fcbaf44efda2f0970f7ec77e43daf1d0e.jpg&size=512)
![DHK dao logo](/_next/image?url=https%3A%2F%2Fstorage.googleapis.com%2Fpapyrus_images%2Fd0018383e486813c84cb0d9ac746e549.jpg&w=384&q=75)