上一個案子交件三個月後，我才發現自己還留著客戶 WordPress 的管理員帳號、Google Ads 的 Admin 權限，還有一組躺在 LINE 對話紀錄裡、從開案到現在沒換過的主機控制台密碼。真正讓我背脊發涼的不是「我可能會亂用」，而是我的筆電如果掉了，那些東西全部一起掉。這篇談密碼管理器，但重點不放在「哪一套介面比較漂亮」，而放在接案者最常漏掉的兩件事：客戶的帳密怎麼安全地交進來，以及案子結束後怎麼確實撤出去。
📌 本文重點
- NIST SP 800-63B 第 4 版（2025 年 8 月 26 日發布）已把「不得要求定期更換密碼」從第 3 版的 SHOULD NOT 提升為 SHALL NOT，並明文規定驗證方 SHALL 允許使用密碼管理器與自動填入，「每三個月換一次密碼」在官方文件裡是被否定的做法。
- 同一版第 3.1.1.2 節規定：密碼作為單一驗證因素時 SHALL 至少 15 字元；驗證方 MAY 允許「僅用於多因素驗證流程」的密碼短一些，但 SHALL 不得低於 8 字元——所以「開了兩步驟驗證就可以用短一點的密碼」在官方標準裡是被允許的（不是被要求的），且前提是那個第二因素真的存在。
- Bitwarden 安全白皮書載明客戶端預設以 PBKDF2-SHA256 迭代 600,000 次派生金鑰，主密碼雜湊送到伺服器後再以隨機 salt 迭代 600,000 次；1Password 則以 128 bits 熵的 Secret Key 搭配約 40 bits 熵的帳號密碼，官方明言「我們沒有你 Secret Key 的紀錄，也無法為你救回」。
- 接案的客戶帳號交接，正解不是把密碼丟進共享保險庫，而是優先使用各平台自己的權限模型：WordPress 給 Editor 而非 Administrator（install_plugins 這項權限只有單站的 Administrator 才有），Google Ads 用電子郵件邀請、離場時在「Actions」欄選 Remove access。
- 個人資料保護法於民國 114 年 11 月 11 日修正，刪除第 27 條並增訂第 20-1 條「非公務機關保有個人資料檔案者，應辦理安全維護事項」，但該次修正的施行日期由行政院定之，撰稿查閱時法規資料庫標示尚未生效——不論以新舊哪一條為準，接案者持有客戶個資的安全維護義務都存在。
瀏覽器內建存密碼，為什麼接案者不夠用
先講一句公道話：對只管自己帳號的一般使用者來說，瀏覽器內建的密碼儲存已經比「所有網站用同一組密碼」好上不知道幾個數量級。問題不在它爛，而在它的設計目標是「一個人、一個生態系、一台裝置群」，不是「一個人、多個客戶、多個他人資產」。
第一個具體落差是加密層級。Google 官方說明頁明白寫著，Google 密碼管理工具的「裝置端加密（on-device encryption）」並非預設開啟，需要使用者自己到 passwords.google.com 或 Chrome 設定中手動啟用，Google 只說「Over time, this security measure will be set up for everyone」。也就是說，你沒有主動去開之前，那份密碼庫的保護模型跟你的 Google 帳號綁在一起，而不是跟一把只有你有的金鑰綁在一起。
第二個落差更狠，而且是條單行道。同一頁官方在「Important」段落寫著：「Once on-device encryption is set up, it can’t be removed.」以及「If you lose your Google password, you risk loss of access to your saved passwords.」開了就不能關。至於帳號救援後會發生什麼，官方的完整句子是：「If you forget your Google password and create a new one during account recovery, you will not be able to access your saved passwords again until you confirm your new Google password.」——請注意句尾那個條件：官方寫的是「在你確認新的 Google 密碼之前」取不到，不是永久刪除。很多中文文章把這句話截斷在「again」就結束，讀成「再也拿不回來」，那是誤讀。但官方同時明說「你有失去存取權的風險」，並要你把帳號救援的手機與備援信箱維持在最新狀態。這對接案者的意義是：你的密碼庫裡混著客戶的東西，一旦你自己的帳號救援卡住，客戶資產也會跟著卡住。
第三個落差是接案專屬的：瀏覽器的密碼庫沒有「分享後可撤回」這個概念。你不可能把 Chrome 裡的某三筆密碼「授權」給協作的設計師三個月，到期自動失效。你只能複製貼上，而複製貼上的那一刻，控制權就永久離開你了。
第四個落差是跨生態。客戶用 Edge、公司電腦被鎖成只能用 IE 模式、外包夥伴用 Safari、你自己在 Linux 上跑 Firefox——這在台灣接案圈是日常。瀏覽器內建方案的同步半徑就是那個瀏覽器帳號，跨不出去。
不過，也別把密碼管理器當萬靈丹
這裡要說一個和多數工具文章方向相反的資料點。Verizon 官方的 Data Breach Investigations Report 2026 版在官網摘要上寫著：「31% of breaches now start with software vulnerabilities, beating stolen passwords as the top way attackers get in.」軟體漏洞已經超越竊得的密碼，成為最主要的初始入侵途徑。同一頁摘要的另外兩句是「48% of all breaches now involve ransomware, but payouts are shrinking.」與「40% higher click rates make mobile devices the new favorite target.」——請注意這裡的分母是「資料外洩事件（breaches）」，不是「所有資安事件」，兩者常被中文報導混用。
這代表什麼？代表你把密碼管理弄好，是把一個大破口補起來，但不是把門關上。你的 WordPress 外掛沒更新、主機 PHP 版本停在很久以前，那道門根本不需要密碼。這也是為什麼我會把密碼管理和站點維運當成同一件事看——如果你正在幫客戶顧站，備份策略要真的救得回來這件事的優先度不會比密碼低。
還有一種很容易被略過的情境：你在咖啡廳解鎖保險庫的那幾分鐘。保險庫在「已解鎖」狀態下，等於所有密碼都以明文存在記憶體裡。公共空間的肩窺、被動過手腳的充電座、以及你離開座位去拿咖啡的那 90 秒，都在這個時間窗裡。在咖啡廳與共享空間工作的資安細節我另外整理過，這裡只講一個設定：把自動鎖定調到 5 分鐘以內，離開座位就手動鎖。
密碼管理器到底在做什麼：主密碼、金鑰派生與零知識
要判斷一套工具值不值得託付客戶資產，你得先知道它宣稱的保護是怎麼來的。整個機制可以拆成三層：主密碼 →（金鑰派生函式 KDF）→ 加密金鑰 → 對稱加密整個保險庫。伺服器只拿得到最後那一坨加密後的亂碼。
Bitwarden 的具體數字
Bitwarden 把細節寫在公開的安全白皮書裡，這在同類產品裡算是誠實的。官方文件記載，加密採「Advanced Encryption Standard in cipher block-chaining mode (AES-CBC), with 256 bit keys」搭配「HMAC with SHA-256」，組成 AES256-CBC-HMAC-SHA256。
金鑰派生的部分：「Password-Based Key Derivation Function 2 (PBKDF2) with 600,000 iteration rounds to stretch the user’s master password with a salt of the user’s email address.」客戶端預設 600,000 次迭代，salt 用你的電子郵件位址，而且這個迭代次數在帳號設定裡是可調的。帳號建立之後也可以改用 Argon2id。
還有一層很多人不知道的：送到伺服器的那個「主密碼雜湊」，官方寫「Once reaching the server, the Master Password Hash is hashed again using PBKDF2-SHA256 with a random salt and 600,000 iterations」——伺服器端會再用隨機 salt 迭代 600,000 次雜湊一遍。意思是就算 Bitwarden 的資料庫整個外流，攻擊者拿到的也不是可以直接拿去試的東西。
官方對零知識的表述是：「Bitwarden team members cannot see your passwords… Bitwarden never stores and cannot access your master password or your cryptographic keys.」
1Password 的雙秘密設計
1Password 走的是另一條路：除了帳號密碼，還有一組 Secret Key。官方說明頁寫得很清楚，它由「34 letters and numbers, separated by dashes」組成，前八個字元中前兩碼是版本號、後六碼是識別碼（例如 A3-ABC123 這種格式）。
關鍵在熵的分配。官方頁面直接給了數字：帳號密碼大約 40 bits 熵，負責保護你裝置上的資料；Secret Key 有 128 bits 熵，負責「protects your data off your devices」——也就是防禦針對伺服器的暴力破解。因為沒人背得起 128 bits 的東西，1Password 會把加密後的副本存在你的裝置與備份中。
代價寫在同一頁：「We have no record of your Secret Key and can’t recover it.」而且官方特別強調 Secret Key「is not a backup code」，忘記帳號密碼時它幫不上忙。這兩句話合起來的意思是——1Password 的安全性有一部分是靠「連原廠都救不了你」換來的。
KeePassXC：完全不上雲的那一派
KeePassXC 官方文件說明它以 GPLv3 授權釋出，是免費開源軟體，原生格式為 KDBX 3.1 與 KDBX 4，加密使用「either the industry-standard AES256 or the Twofish block cipher」，並以「a configurable number of key transformations」強化主金鑰。
它沒有任何內建的雲端同步。官方給的做法是把資料庫檔案放進你自己的雲端同步資料夾，「let your synchronization service of choice do the rest」。額外的保護有兩種：key file（一份含隨機位元組的檔案，加進主金鑰，官方提醒要確保「the file never changes」而且「it actually contains unpredictable data」），以及 YubiKey 的 HMAC-SHA1 challenge-response——KeePassXC 產生一個 challenge，用 YubiKey 的回應強化加密金鑰，而且每次存檔所需的回應都會改變。
救援機制？沒有。文件裡不存在這個東西。密碼忘了，資料庫就是一塊永遠打不開的磚。
「零知識」的正確理解，以及它什麼時候會失效
零知識不等於不可能被攻破，它的準確意思是「伺服器端拿不到明文」。這個保證在三種情況下會被繞過，而這三種都跟接案者的日常高度相關：
第一，主密碼太弱。加密資料一旦外流，攻擊者就能離線暴力破解，不受伺服器的速率限制。600,000 次迭代能把成本拉高，但拉不動一個「客戶公司名字 + 2024」等級的主密碼。
第二，裝置本身已被入侵。竊資型惡意程式（infostealer）的工作方式就是等你解鎖後把明文撈走，這時再強的 KDF 也沒有意義。這跟手機端的權限外洩是同一類問題，我在手機 APP 個資外洩與權限自檢那篇談過裝置端的檢查方式。
第三，你自己把明文複製出去了。貼進 LINE、貼進 Google Sheet、貼進工單系統——保險庫的安全性到你按下 Ctrl+C 那一刻就結束了。這是本文後面整整一大節要處理的問題。
四套主流密碼管理器比較：定價、模式與適用規模
以下價格皆為我在 2026-07-31 於各官方定價頁實際查得的美元標示，會隨時調整，實際請以官網公告為準。
| 項目 | 1Password | Bitwarden | KeePassXC | Proton Pass |
|---|---|---|---|---|
| 免費方案 | 無（14 天試用） | 有，官網列為 Free | 完全免費（GPLv3） | 有，$0/月 |
| 個人付費 | Individual $2.99/月（年繳）、$3.99/月（月繳） | Premium $1.65/月，年繳 $19.80 | — | Pass Plus（官網當日價格未正常渲染，以官網公告為準） |
| 家庭／多人 | Families $4.49/月年繳（月繳 $5.99），官方標示「includes up to 5 people (with room to grow)」，可再加人 | Families $3.99/月，最多 6 人，年繳 $47.88 | — | Pass Family，最多 6 人（價格以官網公告為準） |
| 商用最低門檻 | Teams Starter Pack $24.95/月年繳，含 10 人 | Teams $4/人/月年繳 | — | 商用方案以官網公告為準 |
| 商用進階 | Business $8.99/人/月年繳，含 SSO、自訂群組、成員免費 Families | Enterprise $6/人/月年繳，含帳號救援、SSO、全員免費 Families | — | 以官網公告為準 |
| 資料存放 | 官方雲端 | 官方雲端或自架 | 本機 kdbx 檔，同步自理 | 官方雲端 |
| 額外秘密 | Secret Key（128 bits 熵） | 無，靠 KDF 迭代與兩步驟登入 | Key file、YubiKey challenge-response | 以官網安全說明為準 |
| 緊急存取 | 官方以 Emergency Kit 保存 Secret Key | Emergency Access（Premium 或付費組織成員） | 無 | Emergency Access（列於付費方案功能） |
Proton Pass 免費方案值得單獨講
Proton Pass 的定價頁上，免費方案的內容是有正常渲染出來的：$0/月，提供「Unlimited logins, notes and credit cards」、不限裝置數、瀏覽器與行動／桌面 App、密碼產生器、10 組 hide-my-email 別名、「Alerts for weak and reused passwords」，以及「Passkeys supported on all devices」；官網把「Built-in 2FA authenticator」列在 Pass Plus 那一欄，免費層沒有。付費層（Pass Plus）才解鎖無限別名、整合 2FA、保險庫分享、安全連結分享、暗網監控、附件與 Emergency Access。
那「10 組 hide-my-email 別名」對接案者其實比看起來有用：每個客戶專案配一組別名去註冊該專案專用的服務，結案後直接停用別名，等於連垃圾信一起切乾淨。這是共享保險庫做不到的事。
我的取捨建議（以及為什麼不要一開始就買 Enterprise）
一人接案、客戶少於 5 家、預算敏感：Bitwarden 免費層 + Premium（年繳 $19.80）。Premium 這一層之所以值得，不是因為多了什麼花俏功能，而是因為 Emergency Access 只給 Premium 用戶，而這對單打獨鬥的人是唯一的「我出事了怎麼辦」解方。
已經有固定 2–5 人協作班底：Bitwarden Teams（$4/人/月年繳）或 1Password Teams Starter Pack（$24.95/月含 10 人）。注意這兩個的計價邏輯完全不同：Bitwarden 是按人頭線性成長，1Password 的 Starter Pack 是包月固定價含 10 個名額。如果你的班底穩定在 6–10 人，1Password Starter Pack 反而更便宜；如果只有 3 人，Bitwarden 明顯划算。算一下：3 人用 Bitwarden Teams 是 $12/月，1Password Starter Pack 是 $24.95/月；到 7 人時 Bitwarden 是 $28/月，就已經貴過 Starter Pack 了。
不要一開始就上 Enterprise 或 Business。Bitwarden Enterprise $6/人/月、1Password Business $8.99/人/月，多出來的東西主要是 SSO、政策強制、SIEM 整合、帳號救援——這些的價值前提是「你有 IT 管理權限、有需要被稽核的合規要求」。一個三人的接案工作室買這個，付的是你用不到的治理功能。真的需要的時候再升，兩家都支援方案調整。
只有一台裝置、極度不信任雲端、而且你確定自己會做備份：KeePassXC。零成本、完全掌控。但請誠實評估「我會不會做備份」這件事——KeePassXC 沒有任何救援，你的 kdbx 檔壞掉就是全損。這跟工具好壞無關，是責任轉移的問題。
客戶帳號怎麼交進來：先分類，再決定要不要放進保險庫
這一節是本文的核心，也是絕大多數「密碼管理器推薦」文章不會寫的部分。接案者處理客戶帳密的第一步不是「開一個共享保險庫」，而是把資產分成三類——因為其中兩類根本不該進保險庫。
第一類：能委派權限的，永遠不要拿密碼
WordPress、Google Analytics 4、Google Ads、Meta 商業管理平台、Google Search Console、各家 CDN——這些平台都有正式的「邀請協作者」機制。只要平台支援委派，你就絕對不該拿對方的帳號密碼。原因有三：你不需要承擔保管責任、客戶可以隨時撤銷、而且留有紀錄。
以 WordPress 為例，官方文件列出六種預設角色，其中最關鍵的分界線是這個：安裝外掛與佈景主題的權限（install_plugins、install_themes、update_core、edit_users、create_users、delete_users）只有單站安裝的 Administrator 才有，Editor 完全沒有。官方對 Editor 的定義是「somebody who can publish and manage posts including the posts of other users」。
| 你要做的事 | 需要的最低角色 | 備註 |
|---|---|---|
| 寫稿、改稿、發文、管理別人的文章 | Editor | 含 manage_categories、moderate_comments、upload_files |
| 只寫自己的稿，不要發布權 | Contributor | 只有 edit_posts、delete_posts、read |
| 改選單、小工具、Customizer | Administrator | edit_theme_options 是 Administrator 才有 |
| 裝／更新外掛、換佈景主題 | Administrator（單站） | Multisite 下這些權限收歸 Super Admin |
| 新增或刪除使用者 | Administrator（單站） | create_users／delete_users |
實務上的判斷：如果案子只是內容代管與 SEO 優化，Editor 就夠了；只有在你要負責外掛更新與版本維護時，才需要 Administrator。我自己的做法是開案時先要 Editor，遇到真的需要動外掛的工項再單獨請客戶升權、做完再降回來。多兩封信，但省掉的是「客戶網站三個月後掛掉、他第一個想到的是你」這種對話。
Google Ads 那邊，官方說明列出五種存取層級（Admin、Standard、Read only、Email only、Billing），流程是到 Admin 選單的「Access and security」按加號、「Enter the email address for your invitee and you can choose the access level」、送出邀請；撤銷則是「Find the user you want to remove, and in the ‘Actions’ column, select Remove access」。官方還有一句提醒特別值得轉達給客戶：「If your account has only one administrator, you may lose access to your tags if that user becomes unavailable」——建議帳戶保有至少兩位 Admin。這句話你在開案時講，比結案時講有價值一百倍。
第二類：只能給帳密的，才進共享保險庫
台灣接案的現實是，有一大票東西沒有委派機制：虛擬主機的 cPanel／DirectAdmin、網域註冊商後台、某些本土金流與電商後台、老舊的 CMS、客戶自己架的內部系統。這一類，而且只有這一類，才是共享保險庫存在的理由。
Bitwarden 的模型叫 Collection。官方文件的定義是「Collections group together related logins, notes, cards, and identities for secure sharing within an organization」，而最關鍵的一句是：「Items stored in an organization’s collection(s) do not belong to any individual user, but rather to the organization」，而且「Organization-owned items must be included in at least one collection」。
這句話對接案者的意義非常具體：如果那個 organization 是客戶開的、你只是被邀請進去的成員，那麼案子結束、你被移出組織的當下，那些項目在制度上就不再屬於你。反之，如果 organization 是你開的、客戶的資產放在你的組織裡，你就是那個要對外負責的人。這個歸屬決定必須在開案時談清楚，而不是結案時才發現。
Bitwarden 的成員角色也值得記一下：官方文件說 Owner 是「the only ones that can access an organization’s subscription and billing details」；Admin 可以設定 SSO、企業政策、管理成員；User 則是「can access shared items in their assigned collections and manage personal vault items」——只能存取被指派的 collection。Enterprise 方案還可以建立自訂角色。
1Password 這邊，官方說明指出分享保險庫之前必須先升級到 1Password Families（個人層級）。權限有兩層：預設是「Everyone with access to a vault can view, print, and copy the items in it. When you first share a vault with someone, they can also create, edit, archive, and delete the items in it.」；另一層是 Manager——「If you allow someone to manage a vault, they can change the vault’s name and description, or delete the vault.」官方緊接著補了一句很多人漏看的限定：「This permission doesn’t include any item viewing or editing permissions.」給了管理權不等於給了看內容的權限，這兩件事在 1Password 是分開的。還有一個容易踩雷的行為：「When you delete a shared vault, it will also be removed from the devices of everyone you were sharing it with.」刪保險庫是連坐的，別在心情不好的時候按。
第三類：帶金流與身分的，不要碰
客戶的網銀、信用卡完整卡號、身分證影本、公司大小章掃描檔、電子發票的憑證——這些不管客戶多熱情地要塞給你，都不要收。不是因為你不可信，是因為一旦收了，你就從「服務提供者」變成「個資持有者」，法律責任的性質整個變了（詳見後面的個資法一節）。
遇到客戶硬要給的時候，我的講法是：「這部分我沒有保管能力，出事我賠不起，我們用 XX 方式處理會更快也更安全。」把它框成能力問題而不是信任問題，對方通常就過了。開案前就講清楚這條線，也是識別問題客戶的一個有效測試——會在這個點上跟你硬拗的客戶，後面通常也不會好處理。
把「傳 LINE」這件事講清楚
幾乎每一個台灣接案者都做過：客戶在 LINE 上打一行「帳號 admin 密碼 abc12345」，你回一個貼圖，然後這則訊息就永遠留在那裡了。這件事的風險有三個層次，而且它們都不是抽象的。
風險一：訊息會在雙方裝置與備份中永久留存。你刪掉自己那端沒有用，客戶那端還在；客戶的窗口離職了，那支手機或那台電腦上的對話紀錄還在；聊天備份上傳到雲端，那份密碼也跟著上去了。你無法回收已經送出的明文，這是不可逆的。
風險二：無法設定到期與存取次數。一則 LINE 訊息不會在 7 天後自我銷毀，也不會在被看過一次後失效。
風險三：爭議時你舉不出證。如果客戶的網站三個月後被人上傳了廣告碼，你要怎麼證明那組密碼不是從你這邊流出去的？聊天紀錄只能證明「你們兩個都有」，證明不了「只有你們兩個有」。
替代做法我用 Bitwarden Send。官方文件對它的描述是「A tool to transmit sensitive text or files directly to anyone through secure, temporary links」，具體限制是：文字 Send 最多 1,000 個加密字元，檔案 Send 最多 500 MB（行動裝置 100 MB），生命週期最長 31 天，可以設定到期日、「maximum access count」（最大存取次數），可以加上密碼保護、指定收件者的電子郵件驗證、隱藏你的寄件信箱。檔案 Send 需要 Premium。官方對它的定位是「designed for ephemeral sharing」，到期後資料「will be completely purged」。
我的實際操作是分離通道：Send 連結走 email，Send 的解鎖密碼走 LINE 語音或電話口述。這樣任何單一通道被翻出來都拿不到東西。設定上，最大存取次數我固定填 1，到期日填 3 天——如果客戶三天內沒點，那多半代表窗口換人了，這件事你會想知道。
什麼情況下不該用 Send：客戶的公司 IT 會封鎖外部分享連結（金融業、部分上市公司常見），或者對方是完全不碰新工具的長輩型窗口。這時候硬推工具只會讓交接卡住兩個星期。我的折衷是請對方直接在他們自己的後台幫我開一個帳號、密碼由我在第一次登入時自行修改——密碼從頭到尾沒有經過任何通道，這是最乾淨的解法，也是為什麼第一類「能委派就委派」永遠優先。
順帶一提，這些交接規則最好白紙黑字寫進合約，包括「乙方於結案後 N 日內撤除所有存取權限」與「甲方應於結案時完成密碼變更」。接案合約的必備條款那篇我整理過驗收與著作權的部分，帳號交接條款可以直接掛在驗收條款後面。
離場撤銷清單：結案後 48 小時內要做完的七件事
這一節是我覺得最多人漏掉的。「把客戶移出保險庫」和「客戶的資產不再對你開放」是兩件完全不同的事，中間差了一整個攻擊面。
核心觀念只有一句：撤銷「存取權」不會讓「已經被看過的密碼」失效。你在共享保險庫裡看過那組 cPanel 密碼，撤權之後你腦子裡（或截圖裡、或某個貼上去又忘了刪的暫存檔裡）還是有它。真正的撤銷，永遠是「換掉那個秘密本身」。
| 資產類型 | 撤銷動作 | 做完之後仍殘留的風險 |
|---|---|---|
| WordPress 協作帳號 | 請客戶在「使用者」把你的帳號刪除或降為 Subscriber | 應用程式密碼（Application Password）與 REST API 金鑰不會隨角色降級失效，必須另外檢查 |
| Google Ads / GA4 / Search Console | 在 Access and security 的 Actions 欄選 Remove access | 已下載的報表與已匯出的受眾名單仍在你手上，屬於資料，不是權限 |
| 主機 cPanel / DirectAdmin | 客戶變更密碼（不是移除你的保險庫權限） | 你先前建立的 SSH 金鑰、FTP 子帳號、Cron 任務可能仍存在 |
| 網域註冊商 | 客戶變更密碼並移除你的聯絡人身分 | 網域移轉授權碼（EPP code）若已交給你，需請客戶重新產生 |
| 共享保險庫項目 | 移出組織／移除 Collection 指派 | 你曾看過的所有明文；唯一的真解是逐一換掉密碼 |
| 第三方工具（設計、排程、CI） | 移除你的 seat 或 API token | OAuth 授權常獨立於成員清單，需在「已連結應用程式」另外撤銷 |
| 你自己保險庫內的客戶項目 | 刪除，並清空垃圾桶 | 本機備份、匯出的 CSV／JSON、雲端同步的舊版本 |
順序也有講究，而且跟直覺相反：不要先撤自己的權限。正確順序是——(1) 確認客戶端至少有一位可用的 Owner/Administrator 且他本人能登入（請他當著你的面登入一次）；(2) 客戶變更所有第二類資產的密碼；(3) 檢查殘留憑證（應用程式密碼、SSH 金鑰、OAuth 授權、API token）；(4) 才移除你的協作帳號與保險庫存取；(5) 清空你自己保險庫裡的客戶項目與垃圾桶；(6) 檢查本機是否有匯出檔；(7) 寫一封交接確認信，列出上面每一項的完成狀態，請客戶回覆確認。
第七步的那封信才是真正保護你的東西。它把「權限已交還」這件事變成有時間戳記、雙方確認過的書面紀錄。三個月後如果出事，這封信是你唯一的分界線。這個「用一封確認信把責任切乾淨」的邏輯，和我在需求確認防呆流程裡談的是同一套。
補一個誠實的說明：Bitwarden 官方的成員管理頁面把「暫時撤銷存取（temporarily revoke access）」「永久移除（permanently remove access）」「刪除組織成員帳號」列為三個不同的功能入口，但該頁本身沒有展開三者的差異細節，只有一句總括警告：「Deleting an account or organization is permanent, cannot be undone or restored, and will delete all associated vault data。」所以在按下任何一個之前，請先確認你按的是哪一個。我自己的規則是：協作暫停用「撤銷」，正式結案用「移除」，「刪除帳號」永遠不碰。
兩步驟驗證、TOTP 與 passkey 的關係
TOTP 該不該跟密碼放在同一個保險庫
Bitwarden Premium 與 1Password 都內建驗證器，可以把 TOTP 的種子存在同一筆項目裡，登入時自動填。這在資安圈是一個持續的爭論：把兩個因素放在同一個籃子裡，還算兩個因素嗎？
嚴格說，不算——如果保險庫被攻破，兩個因素同時失守。但實務上，我採取分層的做法，而且分層的依據是「這個帳號被盜的後果由誰承擔」：
- 客戶資產的 TOTP：放共享保險庫。因為協作的現實是不同人、不同時區需要登入，硬要分離只會導致大家改用「把驗證碼截圖傳到群組」這種更爛的做法。
- 你自己密碼管理器主帳號的兩步驟驗證：絕對不放在保險庫裡。放實體安全金鑰，或至少放在另一支專門的手機上。這是唯一不能有循環相依的地方——保險庫的鑰匙不能鎖在保險庫裡。
- 你的主要 email 與金流帳號：也不放保險庫。email 是所有帳號救援的根，金流帳號涉及實際損失。如果你有在用跨境收款工具，這一條特別重要，我在跨境收款工具比較那篇整理過各家的帳戶安全機制差異。
passkey 是什麼，以及一個幾乎人人搞錯的點
FIDO Alliance 官方給的定義是：passkey 是「a FIDO authentication credential based on FIDO standards, that allows a user to sign in to apps and websites with the same process that they use to unlock their device」。官方也明確區分兩種型態：synced passkeys（透過雲端服務在使用者的多台裝置之間同步）與 device-bound passkeys（不會離開單一裝置）。對釣魚的抵抗力，官方的說法是「with passkeys there are no passwords to steal and there is no sign-in data that can be used to perpetuate attacks」，並直接寫出比較結論：「Passkeys are a primary factor that — standing alone — are more secure than the combination of either ‘password + OTP’ or ‘password + phone approval’.」
Apple 的開發者說明補上了兩個技術面的關鍵：「In iCloud Keychain, passkeys are end-to-end encrypted, so even Apple can’t read them.」以及「Because servers only keep public keys, servers are less valuable targets for hackers.」還有一句解釋了為什麼它防釣魚：「Passkeys are intrinsically linked with the app or website they were created for, so people can never be tricked into using their passkey to sign in to a fraudulent app or website.」——綁定關係是密碼學上的，不是靠使用者看網址列。
現在講那個幾乎人人搞錯的點。Google 官方帳戶說明裡有這麼一句：「If your account has 2-Step Verification or is enrolled in the Advanced Protection Program, your passkey bypasses the second authentication step, since this verifies that you own the device.」
翻成白話：passkey 不是「密碼之外再加一道」，它是「取代整套流程」。用 passkey 登入時，你的兩步驟驗證會被跳過，因為 passkey 本身已經同時證明了「你持有這台裝置」和「你通過了裝置的生物辨識或 PIN」。很多中文教學把 passkey 寫成「更方便的第二道驗證」，這在概念上是反的，而且會導致錯誤的風險評估——如果有人拿到你已解鎖的手機，passkey 不會再多問一次。
Google 同時說明，生物特徵資料「stays on your device and is never shared with Google」；裝置遺失時的處置是到 Google 帳號裡「remove the passkey on the lost or stolen device」；跨裝置登入則是在電腦上掃描 QR code，再用手機的生物辨識或 PIN 完成驗證。
一個接案者需要知道的官方限制
NIST SP 800-63B 第 4 版第 2.3.2 節有一條規定值得記著：「Since syncable authenticators … require the private key to be exportable, syncable authenticators SHALL NOT be used at AAL3.」理由就寫在句子裡——私鑰必須可匯出。AAL3 是最高的驗證保證等級，一般商業網站用不到，但如果你的客戶是政府標案、金融或醫療相關，對方的資安規範可能會直接排除同步型 passkey，要求實體安全金鑰。這件事最好在提案階段就問清楚，不要等到交付前才發現整套驗證方案要重做。
現實面的結論：2026 年的台灣接案環境，passkey 與密碼會長期並存。客戶的主機商後台、老 CMS、本土 SaaS，多數還沒支援 passkey。所以「用了 passkey 就不需要密碼管理器」在可見的未來都不成立——你的密碼管理器反而會變成同時裝密碼、TOTP 和 passkey 的那個容器（Proton Pass 免費層就已經支援 passkey 儲存）。
主密碼忘了怎麼辦：緊急存取、Emergency Kit 與繼承
這一節請認真讀，因為它是唯一一個「事前不做、事後絕對補不了」的環節。
各家的官方答案
1Password：救不回來。官方原文是「We have no record of your Secret Key and can’t recover it.」官方給的預防手段是 Emergency Kit——一份含有你 Secret Key 的文件，官方的指示是「Save your Emergency Kit, which contains your Secret Key」，用途是在裝置遺失或損壞時仍能取得 Secret Key。注意它不能解決「忘記帳號密碼」，官方明確說 Secret Key「is not a backup code」。
Bitwarden：靠 Emergency Access 這個機制。官方文件說明它開放給 Premium 用戶，「which includes members of paid organizations (Families, Teams, and Enterprise)」。你可以指定一位受信任的緊急聯絡人，對方需要「a free or premium Bitwarden account on the same Bitwarden server」。角色有兩種：
- View：取得「view/read access to all items in your individual vault, including login items’ passwords and attachments」。
- Takeover：對方「must create a master password for permanent read/write access to your vault. This will replace your previous master password and remove any two-step login methods.」
流程上，你在設定時指定一段「wait time」（等待期）；緊急聯絡人提出請求後，如果你在等待期內沒有手動核准，期滿就自動放行；你也可以在期內主動拒絕。
這裡有一個必須看懂的含意：把某人設為 Takeover 的緊急聯絡人，等於給了他你帳號的最終控制權——只要他發起請求而你在等待期內沒有反應（例如你在無網路的地方旅行兩週）。等待期怎麼設，就是在「我真的出事時要多久才救得到」和「有人惡意發起時我有多久能攔下」之間取捨。官方另外註明，如果組織啟用了自動確認使用者的政策，緊急存取「is not available for your account」。
KeePassXC：沒有任何救援機制。官方文件裡不存在這個功能。主密碼遺失＝資料庫永久打不開。
Google 密碼管理工具（若你已啟用裝置端加密）：設定不可逆，但帳號救援不等於資料永久消失。官方原文再確認一次：「Once on-device encryption is set up, it can’t be removed.」以及「If you lose your Google password, you risk loss of access to your saved passwords.」至於走完救援流程之後，官方寫的是你將無法存取已存密碼「until you confirm your new Google password」，並提醒「To avoid issues with account access, confirm your password right away.」換句話說：不可逆的是「開了就關不掉」這個設定，不是你的密碼庫本身；但只要你確認不了新密碼，實務上的結果一樣是拿不到。
一人接案的實際配置
我自己現在的做法是這三層，成本大約是一杯咖啡加一個下午：
第一層，紙本、兩份、異地。把主密碼提示（不是主密碼本身）與 Emergency Kit 列印兩份，一份放家裡的防火盒，一份放父母家或銀行保管箱。不要用手機拍照存雲端——那等於把最後一道防線降級成你的 Google／Apple 帳號安全性。
第二層，一位緊急聯絡人，等待期設長。選一個信任但不參與你工作的人（家人優先於同業）。等待期我設成官方允許範圍內偏長的一端，理由是我常出國、常有幾天不看訊息，而真正需要用到這個機制的情境（我出了嚴重的事）通常不差那幾天。
第三層，把它寫進合約與交接文件。如果你長期維運客戶的站，客戶有權知道「你出事的時候他們怎麼拿回自己的資產」。這一層的正解不是把緊急存取權給客戶——那等於給客戶你所有其他客戶的資料——而是確保客戶端本身永遠握有自己資產的最高權限（回到前面 Google Ads 官方那句「建議至少兩位 Admin」）。
什麼情況下不該設緊急存取：你和對方的關係還在變動中（合夥人、交往中的伴侶、還在磨合的協作夥伴）。這個權限的撤銷是即時的，但「他已經看過了」是不可逆的。用來篩選客戶的那套警訊邏輯，用在選緊急聯絡人身上同樣適用。
順帶談「密碼要多長、要不要定期換」
既然講到主密碼，把官方標準一次講清楚。NIST SP 800-63B 是全球最常被引用的密碼標準，它有兩個版本在流通，內容有實質差異：
| 項目 | 第 3 版（SP 800-63B） | 第 4 版（SP 800-63B-4，2025-08-26） |
|---|---|---|
| 最短長度 | 「Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber.」（§5.1.1.2） | 作為單一因素時 SHALL 至少 15 字元；僅用於多因素流程中 SHALL 至少 8 字元（§3.1.1.2） |
| 最長長度 | SHOULD 允許至少 64 字元 | SHOULD 允許至少 64 字元 |
| 組合規則（大小寫、符號） | SHOULD NOT 強制 | SHALL NOT 強制 |
| 定期更換 | SHOULD NOT 任意要求更換；有入侵證據時 SHALL 強制更換 | SHALL NOT 要求定期更換；有入侵證據時 SHALL 強制更換 |
| 密碼管理器 | SHOULD 允許貼上，「This facilitates the use of password managers」 | 「Verifiers SHALL allow the use of password managers and autofill functionality.」 |
| 外洩密碼比對 | SHALL 比對常見／已外洩清單 | SHALL 比對 blocklist |
兩個重點：第一，「每 90 天換一次密碼」不只是不必要，在第 4 版是被 SHALL NOT 明文禁止的做法。如果你的客戶公司政策還在強制月月換，你手上有官方文件可以引。第二，「支援密碼管理器」從第 3 版的建議（SHOULD）升級成第 4 版的強制（SHALL）。那些會擋貼上、擋自動填入的後台，在官方標準上是不合規的。
外洩比對這件事，Have I Been Pwned 的 Pwned Passwords 提供免費的查詢方式，官方說明它用 k-anonymity：你的裝置只送出 SHA-1 雜湊的前 5 個字元，服務端回傳所有相符的後綴，比對在你自己的裝置上完成，密碼本身不會離開你的電腦。官方 API 是免費的（「Integrate Pwned Passwords into your own applications with our freely available API」），對命中的密碼，官方的建議毫不含糊：「This password has previously appeared in a data breach and should never be used. If you’ve ever used it anywhere before, change it immediately!」
Bitwarden、1Password 等主流工具都內建了這類檢查（Watchtower、Vault Health Reports）。接手一個新客戶的舊站時，第一件事就是跑一次這個報告——我遇過三次「客戶的管理員密碼出現在外洩清單裡」，其中一次那組密碼還是客戶公司全體共用的。
你手上握著客戶資料：個資法怎麼看
這一節我盡量只講法條原文與可驗證的事實，判斷的部分會標明是我的意見。
什麼算「個人資料」
個人資料保護法第 2 條的定義原文是：個人資料「指自然人之姓名、出生年月日、國民身分證統一編號、護照號碼、特徵、指紋、婚姻、家庭、教育、職業、病歷、醫療、基因、性生活、健康檢查、犯罪前科、聯絡方式、財務情況、社會活動及其他得以直接或間接方式識別該個人之資料」。
同條也定義了三個關鍵動詞：「蒐集」指「以任何方式取得個人資料」；「處理」指「為建立或利用個人資料檔案所為資料之記錄、輸入、儲存、編輯、更正、複製、檢索、刪除、輸出、連結或內部傳送」；「利用」指「將蒐集之個人資料為處理以外之使用」。
對接案者的意義：你幫客戶匯出一份電子報名單來做分析，那份名單裡的姓名與聯絡方式就是個人資料，「匯出」與「儲存在你的電腦」就是處理。這不需要你做任何壞事，光是持有就進入了法律的射程。
安全維護義務：現在有一個條號變動要注意
這是一個實際查證後才會發現的細節，多數中文文章還沒更新。
民國 114 年 11 月 11 日的修正案增訂了第 20-1 條，第一項原文是：「非公務機關保有個人資料檔案者，應辦理安全維護事項，防止個人資料被竊取、竄改、毀損、滅失或洩漏。」第二項是：「前項個人資料檔案安全維護事項、管理機制、應採取之措施及其他相關事項之辦法，由主管機關定之。」同一次修正刪除了原本承載這個義務的第 27 條。
但關鍵在生效狀態。全國法規資料庫的沿革載明，該次修正的範圍是「修正第 1-1、12、18、21、22～26、41、47～49、52、53、55 條條文；增訂第 1-2、20-1、21-1～21-5、51-1、53-1 條條文及章名；刪除第 27 條條文」，並註明「施行日期，由行政院定之」。我在 2026-07-31 逐條打開查閱時，第 20-1 條、第 27 條、第 1-1 條、第 41 條的頁面都掛著同一行標示：「本法規部分或全部條文尚未生效，最後生效日期：未定」——也就是說，行政院到查閱當日還沒有發布施行日期命令。
這裡有一個很容易誤判的陷阱，請務必知道：全國法規資料庫的單條頁面預設顯示的是最新公布的版本，不是現行有效的版本。所以你現在點開第 27 條，看到的會是一個孤零零的「（刪除）」，但那個刪除還沒施行；你點開第 20-1 條，會看到完整條文，但那條也還沒施行。只看條文本身分不出來，唯一的判斷依據是頁面上那行生效狀態標示。要查真正的現行條文，得切到頁面上的「歷史法規」。
所以正確的說法是：條號會變，但義務不變。不論以現行條文或修正後的第 20-1 條為準，「防止個人資料被竊取、竄改、毀損、滅失或洩漏」這個核心要求都成立。如果你要在提案書或合約裡引條號，請在引用當下自己再查一次法規資料庫的生效狀態欄位——這是我唯一會建議你不要照抄任何文章（包括這一篇）的地方。
另外一個常被寫錯的變動：第 1-1 條的條文是「本法之主管機關為個人資料保護委員會」，但這一條同樣還沒生效。依法規沿革，第 1-1 條是民國 112 年 5 月 31 日增訂、114 年 11 月 11 日再修正，兩次都註明「施行日期，由行政院定之」，而我在 2026-07-31 查閱時，該條頁面仍標示「本法規部分或全部條文尚未生效，最後生效日期：未定」。行政機關這邊的實況也對得上：個人資料保護委員會目前對外仍是「籌備處」（pdpc.gov.tw）。所以「個資法的主管機關已經改成個資會」這種寫法，在查閱當日還不是已完成的事實，而是待施行的制度安排。要在提案書或合約裡寫主管機關，請當下自己再查一次。
做錯了會怎樣
民事責任，第 29 條原文：「非公務機關違反本法規定，致個人資料遭不法蒐集、處理、利用或其他侵害當事人權利者，負損害賠償責任。但能證明其無故意或過失者，不在此限。」第 29 條不在 114 年 11 月 11 日的修正範圍內，是現行有效條文。注意但書的舉證責任在你身上——你要證明自己沒有故意過失，而不是對方證明你有。這正是為什麼前面那份「交接確認信」有價值：它是你能拿出來的過程紀錄。
刑事責任，第 41 條——注意，第 41 條也在 114 年 11 月 11 日的修正範圍內，法規資料庫顯示的是修正後、施行日期由行政院定之、查閱當日尚未生效的版本，以下引用即為該版本，用在正式文件前請自行核對現行條文：「意圖為自己或第三人不法之利益或損害他人之利益，而違反第六條第一項、第十五條、第十六條、第十九條、第二十條第一項規定，或依第二十一條限制國際傳輸之命令或處分，足生損害於他人者，處五年以下有期徒刑，得併科新臺幣一百萬元以下罰金。」構成要件包含「意圖為自己或第三人不法之利益或損害他人之利益」，這是主觀要件，一般接案者的疏失不會直接落入這一條——但「把客戶名單拿去做別的用途」就完全不是疏失的問題了。
第 6 條另外把病歷、醫療、基因、性生活、健康檢查及犯罪前科列為特種個人資料，原則禁止蒐集，僅有法律明文規定、法定職務必要、當事人自行公開、學術研究、協助執行職務、經當事人書面同意等例外。如果你的客戶是診所、健檢中心、長照機構，你手上的資料很可能就是這一類，請在開案前就跟客戶確認資料處理的界線。
我的實務結論
三句話：能不持有就不持有；必須持有就限期持有並記錄在案；離場時把「已刪除」寫成文件請對方回覆確認。密碼管理器在這個框架裡的角色，是讓「必須持有」的那一小塊有一個可控、可撤銷、可交代的容器，而不是讓你更方便地囤積東西。
什麼情況下不該這樣做
情況一：你只有一台電腦、從不出門、也沒有協作對象。那 KeePassXC 加一份定期備份就是最佳解，沒必要每年付訂閱。但這個結論的成立完全取決於「你會不會做備份」——如果過去一年你沒有真的還原過一次備份來驗證它能用，請誠實承認你不會，然後去用有雲端的方案。
情況二：團隊不到三人卻先買 Enterprise／Business。Bitwarden Enterprise $6/人/月、1Password Business $8.99/人/月，多出來的 SSO、政策強制、SIEM 整合，前提是你有身分提供者、有需要被稽核的規範。三人團隊買這個，錢花在治理功能上，而你真正該花錢的地方是備份與監控。
情況三：把客戶的個人 Google／Apple 帳號密碼收進自己的保險庫。那不是「專案資產」，那是一個人的身分。收進來的瞬間，你就有能力讀他的私人信件、看他的位置紀錄、以他的名義做任何事。不管客戶多堅持「這樣比較方便」，都要拒絕，並改用該平台的委派機制。如果那個平台沒有委派機制，請客戶另開一個專用帳號。
情況四：把客戶的身分證影本、信用卡完整卡號、公司大小章掃描檔存進保險庫的「安全筆記」。密碼管理器加密得再好，也改變不了你「持有了不該持有的東西」這個事實，而且在第 6 條特種資料的情境下風險更高。
情況五：客戶要求你把所有帳密整理進他們指定的 Google Sheet 或 Notion 頁面。這在台灣中小企業很常見，而且你未必拒絕得了。我的折衷做法是：在那份表上只填「資產名稱、負責人、存放位置、最後更新日」，密碼欄一律留空並註明「憑證由 XX 保管，需另行申請」。你交出去的是清單，不是鑰匙。順帶一提，這種「共用文件變成密碼倉庫」的病，用合適的專案管理工具把資產清單與憑證分開放，比事後宣導有效得多。
情況六：你把密碼管理器的主帳號兩步驟驗證，也存在同一個密碼管理器裡。這是循環相依。裝置遺失時你會發現自己被鎖在外面，而且是那種完全無解的鎖法。
常見問題
Q：密碼管理器被駭的話，我所有密碼是不是一次全沒了？
A：不一定，關鍵在於外洩的是「加密後的資料」還是「明文」。主流工具採零知識架構，伺服器端只存加密資料，Bitwarden 白皮書明載客戶端以 PBKDF2-SHA256 迭代 600,000 次派生金鑰，主密碼雜湊送達伺服器後再以隨機 salt 迭代 600,000 次。所以資料庫外流時，攻擊者拿到的是需要離線暴力破解的密文，破解成本取決於你主密碼的強度。真正會一次全沒的情境是你自己的裝置被竊資型惡意程式感染，或你的主密碼弱到可以被字典攻擊猜中。
Q：我應該多久換一次主密碼？
A：不需要定期換。NIST SP 800-63B 第 4 版第 3.1.1.2 節明文規定驗證方「SHALL NOT require subscribers to change passwords periodically」，只有在有證據顯示驗證器已遭入侵時才「SHALL force a change」。第 3 版原本是較弱的 SHOULD NOT，第 4 版升級為強制禁止。實務上該做的是：把主密碼設得夠長（第 4 版對單因素密碼要求最少 15 字元），開啟兩步驟驗證，並定期用工具比對是否出現在外洩清單中。
Q：客戶不肯用密碼管理器，堅持要在 LINE 上給我密碼，怎麼辦？
A：先不要試圖說服他換工具，改成移除「需要傳密碼」這個步驟本身。優先請客戶在他自己的後台用電子郵件邀請你當協作者，例如 WordPress 給 Editor 角色、Google Ads 在 Access and security 用 email 邀請——這樣密碼從頭到尾不會經過任何通道。只有在平台完全沒有委派機制時，才退而使用有到期時間的一次性分享（例如 Bitwarden Send，官方限制為文字最多 1,000 字元、最長 31 天、可設最大存取次數與密碼），並讓連結與解鎖密碼走不同通道。
Q：有了 passkey 之後還需要密碼管理器嗎？
A：需要，而且在可見的未來都需要。第一，台灣多數主機商後台、本土 SaaS 與老舊 CMS 還沒支援 passkey，密碼仍是主要驗證方式。第二，passkey 本身也需要一個地方存放與同步，主流密碼管理器（含 Proton Pass 免費層）已經同時扮演密碼、TOTP 與 passkey 的容器。第三，要特別注意 Google 官方說明的這句：「your passkey bypasses the second authentication step」——passkey 是取代整套流程，不是在密碼之外多加一道，用它做風險評估時不要算成兩層。
Q：Bitwarden 免費版對接案者夠用嗎？
A：可以起步，但有兩個功能落差要先知道。第一，Emergency Access（緊急存取）只開放給 Premium 用戶與付費組織成員，一人接案者沒有這個等於「我出事了資產就全鎖死」。第二，檔案 Send 需要 Premium，免費版只能傳文字 Send（上限 1,000 字元）。以官網標示的 Premium 年繳 $19.80 來算，換得的是備援機制與檔案分享能力，對有在幫客戶保管憑證的人，這是我認為最划算的一筆訂閱。實際價格請以官網公告為準。
Q：我幫客戶保管帳密，會不會有法律責任？
A：會，而且舉證責任對你不利。個人資料保護法第 29 條規定非公務機關違反本法致個資遭不法蒐集、處理、利用或侵害當事人權利者負損害賠償責任，「但能證明其無故意或過失者，不在此限」——也就是要由你證明自己沒有故意過失。安全維護義務方面，114 年 11 月 11 日的修正刪除第 27 條、增訂第 20-1 條「應辦理安全維護事項，防止個人資料被竊取、竄改、毀損、滅失或洩漏」，但該次修正施行日期由行政院定之，引用條號前請自行至全國法規資料庫確認生效狀態。實務上的自保是：能委派就不持有、必須持有就限期並記錄、結案時以書面確認已刪除。本段非法律建議，具體爭議請諮詢律師。
延伸閱讀
- 接案合約怎麼簽？必備條款、驗收與著作權歸屬完整指南——把帳號交接與撤銷寫進合約的位置與寫法。
- 在咖啡廳與共享空間工作：選點、設備、公共 Wi-Fi 資安與禮儀全指南——保險庫解鎖狀態下的實體與網路風險。
- WordPress 備份怎麼做才真的救得回來？外掛、主機端與異地備份的三層策略——密碼顧好了，站還是要能還原才算數。
資料來源
- NIST, SP 800-63B: Digital Identity Guidelines — Authentication and Lifecycle Management（第 3 版）：https://pages.nist.gov/800-63-3/sp800-63b.html
- NIST, SP 800-63B-4: Digital Identity Guidelines — Authentication and Authenticator Management（第 4 版，2025-08-26）：https://pages.nist.gov/800-63-4/sp800-63b.html
- Bitwarden 官方定價頁：https://bitwarden.com/pricing/
- Bitwarden 說明中心〈What encryption is used?〉：https://bitwarden.com/help/what-encryption-is-used/
- Bitwarden 安全白皮書：https://bitwarden.com/help/bitwarden-security-white-paper/
- Bitwarden 說明中心〈Emergency Access〉：https://bitwarden.com/help/emergency-access/
- Bitwarden 說明中心〈About Collections〉：https://bitwarden.com/help/about-collections/
- Bitwarden 說明中心〈About Bitwarden Send〉：https://bitwarden.com/help/about-send/
- Bitwarden 說明中心〈Member Roles and Permissions〉：https://bitwarden.com/help/user-types-access-control/
- Bitwarden 說明中心〈Managing Users〉：https://bitwarden.com/help/managing-users/
- 1Password 支援中心〈About your Secret Key〉：https://support.1password.com/secret-key-security/
- 1Password 個人方案定價頁：https://1password.com/pricing/personal
- 1Password 商用方案定價頁：https://1password.com/pricing/business
- 1Password 支援中心〈Create and share vaults〉：https://support.1password.com/create-share-vaults/
- 1Password 支援中心〈1Password Families〉（成員人數）：https://support.1password.com/explore/families/
- Proton Pass 官方定價頁：https://proton.me/pass/pricing
- KeePassXC 官方文件：https://keepassxc.org/docs/
- FIDO Alliance〈Passkeys〉：https://fidoalliance.org/passkeys/
- Apple Developer〈Passkeys Overview〉：https://developer.apple.com/passkeys/
- Google 帳戶說明〈Sign in with a passkey instead of a password〉：https://support.google.com/accounts/answer/13548313
- Google 帳戶說明〈On-device encryption for Google Password Manager〉：https://support.google.com/accounts/answer/11350823
- Have I Been Pwned〈Pwned Passwords〉：https://haveibeenpwned.com/Passwords
- Verizon Business〈Data Breach Investigations Report〉（2026 年版）：https://www.verizon.com/business/resources/reports/dbir/
- 全國法規資料庫〈個人資料保護法〉全文：https://law.moj.gov.tw/LawClass/LawAll.aspx?pcode=I0050021
- 全國法規資料庫〈個人資料保護法第 20-1 條〉：https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=I0050021&flno=20-1
- 全國法規資料庫〈個人資料保護法第 27 條〉（已刪除，施行日期由行政院定之）：https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=I0050021&flno=27
- 全國法規資料庫〈個人資料保護法第 41 條〉：https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=I0050021&flno=41
- WordPress 官方文件〈Roles and Capabilities〉：https://wordpress.org/documentation/article/roles-and-capabilities/
- Google Ads 說明〈Add, change, or remove account access〉：https://support.google.com/google-ads/answer/6372672
- Google Ads 說明〈About access levels in your Google Ads account〉（五種存取層級）：https://support.google.com/google-ads/answer/9978556
- 全國法規資料庫〈個人資料保護法〉法規沿革（114-11-11 修正範圍與施行日期）：https://law.moj.gov.tw/LawClass/LawHistory.aspx?pcode=I0050021
- 全國法規資料庫〈個人資料保護法第 1-1 條〉（主管機關，尚未生效）：https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=I0050021&flno=1-1
- 個人資料保護委員會籌備處：https://www.pdpc.gov.tw/
