📜 [專欄新文章] [ZKP 讀書會] Trust Token Browser API
✍️ Yuren Ju
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

Trust Token API 是一個正在標準化的瀏覽器 API，主要的目的是在保護隱私的前提下提供跨站授權 (Cross-domain authorization) 的功能，以前如果需要跨站追蹤或授權通常都使用有隱私疑慮的 Cookies 機制，而 Trust Token 則是希望在保護隱私的前提下完成相同的功能。

會在 ZKP (Zero-knowledge proof) 讀書會研究 Trust Token 主要是這個 API 採用了零知識證明來保護隱私，這也是這次讀書會中少見跟區塊鏈無關的零知識證明應用。

問題

大家應該都有點了一個產品的網頁後，很快的就在 Facebook 或是 Google 上面看到相關的廣告。但是產品網頁並不是在 Facebook 上面，他怎麼會知道我看了這個產品的頁面？

通常這都是透過 Cookie 來做跨網站追蹤來記錄你在網路上的瀏覽行為。以 Facebook 為例。

當使用者登入 Facebook 之後，Facebook 會透過 Cookie 放一段識別碼在瀏覽器裡面，當使用者造訪了有安裝 Facebook SDK 來提供「讚」功能的網頁時，瀏覽器在載入 SDK 時會再度夾帶這個識別碼，此時 Facebook 就會知道你造訪了特定的網頁並且記錄下來了。如此一來再搭配其他不同管道的追蹤方式，Facebook 就可以建構出特定使用者在網路上瀏覽的軌跡，從你的瀏覽紀錄推敲喜好，餵給你 Facebook 最想給你看的廣告了。

不過跨站追蹤也不是只能用在廣告這樣的應用上，像是 CDN (Content Delivery Network) 也是一個應用場景。CDN 服務 Cloudflare 提供服務的同時會利用 Captcha 先來確定進入網站的是不是真人或是機器人。而他希望使用者如果是真人時下次造訪同時也是採用 Cloudflare 服務的網站不要再跳出 Captcha 驗證訊息。

雖然 Cloudflare 也需要跨站驗證的功能來完成他們的服務，但是相較於 Google 或 Facebook 來說他們是比較沒那麼想知道使用者的隱私。有沒有什麼辦法可以保護使用者隱私的狀況下還能完成跨站驗證呢？

這就是今天要講的新 API: Trust Token。

Trust Token API - The Chromium Projects

Trust Token / Privacy Pass 簡介

Trust Token 其實是由 Privacy Pass 延伸而來。Privacy Pass 就是由 Cloudflare 所開發的實驗性瀏覽器延伸套件實作一個驗證機制，可以在不透漏過多使用者隱私的前提下實作跨站驗證。而 Trust Token 則是標準化的 Privacy Pass，所以兩個運作機制類似，但是實作方式稍有不同。

先看一下 Privacy Pass 是如何使用。因為這是實驗性的瀏覽器延伸套件所以看起來有點陽春，不過大致上還是可以了解整個概念。

以 hCaptcha 跟 Cloudflare 的應用為例，使用者第一次進到由 Cloudflare 提供服務的網站時，網站會跳出一些人類才可以解答的問題比如說「挑出以下是汽車的圖片」。

當使用者答對問題後，Cloudflare 會回傳若干組 blind token，這些 blind token 還會需要經過 unblind 後才會變成真正可以使用的 token，這個過程為 issue token。如上圖所示假設使用者這次驗證拿到了 30 個 token，在每次造訪由 Cloudflare 服務的網站時就會用掉一個 token，這個步驟稱為 redeem token。

但這個機制最重要的地方在於 Cloudflare 並無法把 issue token 跟 redeem token 這兩個階段的使用者連結在一起，也就是說如果 Alice, Bob 跟 Chris 都曾經通過 Captcha 測試並且獲得了 Token，但是在後續瀏覽不同網站時把 token 兌換掉時，Clouldflare 並無法區分哪個 token 是來自 Bob，哪個 token 是來自 Alice，但是只要持有這種 token 就代表持有者已經通過了 Captcha 的挑戰證明為真人。

但這樣的機制要怎麼完成呢？以下我們會透過多個步驟的例子來解釋如何達成這個目的。不過在那之前我們要先講一下 Privacy Pass 所用到的零知識證明。

零知識證明 (Zero-knowledge proof)

零知識證明是一種方法在不揭露某個祕密的狀態下，證明他自己知道那個秘密。

Rahil Arora 在 stackexchange 上寫的比喻我覺得是相對好理解的，下面簡單的翻譯一下：

假設 Alice 有超能力可以幾秒內算出樹木上面有幾片樹葉，如何在不告訴 Bob 超能力是怎麼運作並且也不告訴 Bob 有多少片葉子的狀況下證明 Alice 有超能力？我們可以設計一個流程來證明這件事情。

Alice 先把眼睛閉起來，請 Bob 選擇拿掉樹上的一片葉子或不拿掉。當 Alice 睜開眼睛的時候，告訴 Bob 他有沒有拿掉葉子。如果一次正確的話確實有可能是 Alice 幸運猜到，但是如果這個過程連續很多次時 Alice 真的擁有數葉子的超能力的機率就愈來愈高。

而零知識證明的原理大致上就是這樣，你可以用一個流程來證明你知道某個秘密，即使你不真的揭露這個秘密到底是什麼，以上面的例子來說，這個秘密就是超能力運作的方式。

以上就是零知識證明的概念，不過要完成零知識證明有很多各式各樣的方式，今天我們要介紹的是 Trust Token 所使用的零知識證明：DLEQ。

DLEQ (Discrete Logarithm Equivalence Proof)

說明一下以下如果小寫的變數如 c, s 都是純量 (Scalar)，如果是大寫如 G, H則是橢圓曲線上面的點 (Point)，如果是 vG 則一樣是點，計算方式則是 G 連續相加 v 次，這跟一般的乘法不同，有興趣可以程式前沿的《橢圓曲線加密演算法》一文解釋得比較詳細。

DLEQ 有一個前提，在系統中的所有人都知道公開的 G 跟 H 兩個點，此時以下等式會成立：

假設 Peggy 擁有一個秘密 s 要向 Victor 證明他知道 s 為何，並且在這個過程中不揭露 s 真正的數值，此時 Victor 可以產生一個隨機數 c 傳送給 Peggy，而 Peggy 則會再產生一個隨機數 v 並且產生 r，並且附上 vG, vH, sG, sH：

r = v - cs

所以 Victor 會得到 r, sG, sH, vG, vH 再加上他已經知道的 G, H。這個時候如果 Victor 計算出以下兩個等式就代表 Peggy 知道 s 的真正數值：

vG = rG + c(sG)vH = rH + c(sH)

我們舉第二個等式作為例子化簡：

vH = rH + c(sH) // 把 r 展開成 v - csvH = (v - cs)H + c(sH) // (v - cs)H 展開成 vH - csHvH = vH - c(sH) + c(sH) // 正負 c(sH) 消掉vH = vH

這樣只有 Peggy 知道 s 的狀況下才能給出 r，所以這樣就可以證明 Peggy 確實知道 s。

從簡易到實際的情境

Privacy Pass 網站上透過了循序漸進的七種情境從最簡單的假設到最後面實際使用的情境來講解整個機制是怎麼運作的。本文也用相同的方式來解釋各種情境，不過前面的例子就會相對比較天真一點，就請大家一步步的往下看。

基本上整個過程是透過一種叫做 Blind Signature 的方式搭配上零知識證明完成的，以下參與的角色分為 Client 與 Server，並且都會有兩個階段 issue 與 redeem token。

Scenario 1

如果我們要設計一個這樣可以兌換 token 來確認身分的系統，其中有一個方法是透過橢圓曲線 (elliptic curve) 完成。Client 挑選一個在橢圓曲線上的點 T 並且傳送給 Server，Server 收到後透過一個只有 Server 知道的純量 (scalar) s 對 T 運算後得到 sT 並且回傳給 Client，這個產生 sT 的過程稱為 Sign Point，不過實際上運作的原理就是橢圓曲線上的連續加法運算。

SignPoint(T, s) => sT

等到 Client 需要兌換時只要把 T 跟 sT 給 Server，Server 可以收到 T 的時候再 Sign Point 一次看看是不是 sT 就知道是否曾經 issue 過這個 token。

Issue

以下的範例，左邊都是 Client, 右邊都是 Server。 -> 代表 Client 發送給 Server，反之亦然。

// Client 發送 T 給 Server, 然後得到 sT

T -> <- sT

Redeem

// Client 要 redeem token 時，傳出 T 與 sT

T, sT ->

問題：Linkability

因為 Server 在 issue 的時候已經知道了 T，所以基本上 Server 可以透過這項資訊可以把 issue 階段跟 redeem 階段的人連結起來進而知道 Client 的行為。

Scenario 2

要解決上面的問題，其中一個方法是透過 Blind Signature 達成。Client 不送出 T，而是先透過 BlindPoint 的方式產生 bT 跟 b，接下來再送給 Server bT。Server 收到 bT 之後，同樣的透過 Sign Point 的方式產生結果，不一樣的地方是情境 1 是用 T，而這邊則用 bT 來作 Sign Point，所以得出來的結果是 s(bT)。

Client:BlindPoint(T) => (bT, b)

Server:SignPoint(bT, s) => sbT

而 Blind Signature 跟 Sign Point 具備了交換律的特性，所以得到 s(bT) 後可以透過原本 Client 已知的 b 進行 Unblind：

UnblindPoint(sbT, b) => sT

這樣一來在 Redeem 的時候就可以送出 T, sT 給 Server 了，而且透過 SignPoint(T, s) 得出結果 sT’ 如果符合 Client 傳來的 sT 就代表確實 Server 曾經簽過這個被 blind 的點，同時因為 T 從來都沒有送到 Server 過，所以 Server 也無法將 issue 與 redeem 階段的 Client 連結在一起。

Issue

bT -> <- s(bT)

Redeem

T, sT ->

問題：Malleability

以上的流程其實也有另外一個大問題，因為有交換律的關係，當 Client 透過一個任意值 a 放入 BlindPoint 時產生的 a(sT) 就會等於 s(aT)：

BlindPoint(sT) => a(sT), a// a(sT) === s(aT)

此時如果將 aT 跟 s(aT) 送給 Server Redeem，此時因為

SignPoint(aT, s) => s(aT)

所以就可以兌換了，這樣造成 Client 可以無限地用任意數值兌換 token。

Scenario 3

這次我們讓 Client 先選擇一個純數 t，並且透過一種單向的 hash 方式來產生一個在橢圓曲線上的點 T，並且在 redeem 階段時原本是送出 T, sT 改成送出 t, sT。

因為 redeem 要送出的是 t，上個情境時透過任意數 a 來產生 s(aT) 的方法就沒辦法用了，因為 t 跟 sT 兩個參數之間並不是單純的再透過一次 BlindPoint() 就可以得到，所以就沒辦法無限兌換了。

Issue

T = Hash(t) bT -> <- sbT

Redeem

t, sT ->

問題：Redemption hijacking

在這個例子裏面，Client 其實是沒有必要傳送 sT 的，因為 Server 僅需要 t 就可以計算出 sT，額外傳送 sT 可能會導致潛在的 Redemption hijacking 問題，如果在不安全的通道上傳輸 t, sT 就有可能這個 redemption 被劫持作為其他的用途。

不過在網站上沒講出實際上要怎麼利用這個問題，但是少傳一個可以計算出來的資料總是好的。Client 只要證明他知道 sT 就好，而這可以透過 HMAC (Hash-based Message Authentication Code) 達成。

Scenario 4

步驟跟前面都一樣，唯一不一樣的地方是 redeem 的時候原本是傳 t, sT，現在則改傳 t, M, HMAC(sT, M)，如果再介紹 HMAC 篇幅會太大，這邊就不解釋了，但可以是作是一個標準的 salt 方式讓 Hash 出來的結果不容易受到暴力破解。

這樣的特性在這個情境用很適合，因為 Server 透過 t 就可以計算出 sT，透過公開傳遞的 M 可以輕易地驗證 client 端是否持有 sT。

Issue

T = Hash(t) bT -> <- sbT

Redeem

t, M, HMAC(sT, M) ->

問題：Tagging

這邊的問題在於 Server 可以在 issue 階段的時候用不一樣的 s1, s2, s3 等來發出不一樣的 sT’，這樣 Server 在 Redeem 階段就可以得知 client 是哪一個 s。所以 Server 需要證明自己每次都用同樣的 s 同時又不透漏 s 這個純亮。

要解決這個問題就需要用到前面我們講解的零知識證明 DLEQ 了。

Scenario 5

前面的 DLEQ 講解有提到，如果有 Peggy 有一個 s 秘密純量，我們可以透過 DLEQ 來證明 Peggy 知道 s，但是又不透漏 s 真正的數值，而在 Privacy Pass 的機制裡面，Server 需要證明自己每次都用 s，但是卻又不用揭露真正的數值。

在 Issue 階段 Client 做的事情還是一樣傳 bT 給 Server 端，但 Server 端的回應就不一樣了，這次 Server 會回傳 sbT 與一個 DLEQ 證明，證明自己正在用同一個 s。

首先根據 DLEQ 的假設，Server 會需要先公開一組 G, H 給所有的 Client。而在 Privacy Pass 的實作中則是公開了 G 給所有 Client，而 H 則改用 bT 代替。

回傳的時候 Server 要證明自己仍然使用同一個 s 發出 token，所以附上了一個 DLEQ 的證明 r = v - cs，Client 只要算出以下算式相等就可證明 Server 仍然用同一個 s (記住了 H 已經改用 bT 代替，此時 client 也有 sbT 也就是 sH)：

vH = rH + c(sH) // H 換成 bTvbT = rbT + c(sbT) // 把 r 展開成 v - csvbT = (v - cs)bT + c(sbT) // (v - cs)bT 展開成 vbT - csbTvbT = vbT - c(sbT) + c(sbT) // 正負 c(sbT) 消掉vbT = vbT

這樣就可以證明 Server 依然用同一個 s。

Issue

T = Hash(t) bT -> <- sbT, DLEQ(bT:sbT == G:sG)

Redeem

t, M, HMAC(sT, M) ->

問題：only one redemption per issuance

到這邊基本上 Privacy Pass 的原理已經解釋得差不多了，不過這邊有個問題是一次只發一個 token 太少，應該要一次可以發多個 token。這邊我要跳過源文中提到的 Scenario 6 解釋最後的結果。

Scenario 7

由於一次僅產生一個 redeem token 太沒效率了，如果同時發很多次，每次都產生一個 proof 也不是非常有效率，而 DLEQ 有一個延伸的用法 “batch” 可以一次產生多個 token, 並且只有使用一個 Proof 就可以驗證所有 token 是否合法，這樣就可以大大的降低頻寬需求。

不過這邊我們就不贅述 Batch DLEQ 的原理了，文末我會提及一些比較有用的連結跟確切的源碼片段讓有興趣的人可以更快速的追蹤到源碼片段。

Issue

T1 = Hash(t1) T2 = Hash(t2)T3 = Hash(t3)b1T1 ->b2T2 ->b3T3 -> c1,c2,c3 = H(G,sG,b1T1,b2T2,b3T3,s(b1T1),s(b2T2),s(b3T3)) <- sb1T1 <- sb2T2 <- sb3T3 <- DLEQ(c1b1T1+c2b2T2+c3b3T3:s(c1b1T1+c2b2T2+c3b3T3) == G: sG)

Redeem

t1, M, HMAC(sT1, M) ->

結論

Privacy Token / Trust Token API 透過零知識證明的方式來建立了一個不需要透漏太多隱私也可以達成跟 cookie 相同效果的驗證方式，期待可以改變目前許多廣告巨頭透過 cookie 過分的追蹤使用者隱私的作法。

不過我在 Trust Token API Explainer 裡面看到這個協議裡面的延伸作法還可以夾帶 Metadata 進去，而協議制定的過程中其實廣告龍頭 Google 也參與其中，希望這份協議還是可以保持中立，盡可能地讓最後版本可以有效的在保護隱私的情況下完成 Cross-domain authorization 的功能。

參考資料

IETF Privacy Pass docs

Privacy Pass: The Protocol

Privacy Pass: Architectural Framework

Privacy Pass: HTTP API

Cloudflare

Supporting the latest version of the Privacy Pass Protocol (cloudflare.com)

Chinese: Cloudflare支持最新的Privacy Pass扩展_推动协议标准化

Other

Privacy Pass official website

Getting started with Trust Tokens (web.dev)

WICG Trust Token API Explainer

Non-interactive zero-knowledge (NIZK) proofs for the equality (EQ) of discrete logarithms (DL) (asecuritysite.com) 這個網站非常實用，列了很多零知識證明的源碼參考，但可惜的是 DLEQ 這個演算法講解有錯，讓我在理解演算法的時候撞牆很久。所以使用的時候請多加小心，源碼應該是可以參考的，解釋的話需要斟酌一下。

關鍵源碼

這邊我貼幾段覺得很有用的源碼。

privacy pass 提供的伺服器端產生 Proof 的源碼

privacy pass 提供的瀏覽器端產生 BlindPoint 的源碼

github dedis/kyber 產生 Proof 的源碼

[ZKP 讀書會] Trust Token Browser API was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌

電腦手機網絡安全（四）：有關安全鑰匙 YubiKey，你問我答（頗大篇幅修訂版）+ 香港用戶訂購優惠詳情

文：薯伯伯

（超長文，建議先儲存，有需要再找來讀。不想全文讀，只想買 keys，請只看「香港用戶訂購優惠詳情」，第十三條問答及第十四條問答。）

早幾天寫了一篇文章，提到二步認證的安全鑰匙 YubiKey，無獨有偶，《立場》的另一位博客，《茉莉花開：中東革命與民主路》的作者陳婉容原來早在七月份就聯絡了瑞典的 Yubico 公司，希望取得他們的贊助，在核實身份後，這家瑞典公司寄出了五百條 YubiKey 送給香港人，來自遠方的慷慨之舉，實在令人感動。

我發覺不少人對於 YubiKey 的功能及用法均有誤解，甚至有人認為「有伏」，或誤以為用上 YubiKey 後反而更危險。我回應了一些評語，整合之後發到自己的臉書專頁，《立場》的編輯看到，問可否轉載到《立場》，所以我又花了一點時間，整理一下文稿。

後來我跟 YubiKey 的香港代理分銷商聯絡，提到近日大家較為關注網絡保安，他們同意給讀者提供一個折扣優惠，也希望加強普羅大眾對網絡安全的意識。於是，我又再把之前的文章修訂一下，再講解清楚相關的使用細項，希望有興趣的讀者，讀完這篇文章後，可以加強自身的網絡保安防護。

香港用戶訂購優惠詳情

先說一下香港分銷商的優惠模式：

1. YubiKey 的產品，全線八折，目前這個優惠沒有定下限期，但會看看情況再決定何時終止。（這個優惠折扣，其實是我建議的，因為只是想跟官網的教育優惠體齊而已。我希望讀者可以有優惠，但同一時間也不希望分銷商要做蝕本生意。）
2. 又或者是以原價購買 YubiKey，但會送上 Bitdefender 防護軟件一年的訂閱服務（原價是 HK$ 300 一年）。

優惠方案之一：

YubiKey 5Ci：HK$ 440（原價 HK$ 550）
YubiKey 5 Nano：HK$ 310（原價 HK$ 390）
YubiKey 5 NFC：HK$ 285（原價 HK$ 355）
YubiKey 5C：HK$ 310（原價 HK$ 390）
YubiKey 5C Nano：HK$ 375（原價 HK$ 470）

優惠方案之二：

Bitdefender TOTAL SECURITY 2020 的銷售價是 HK$ 300 /年費（可以用五部機），與 YubiKey 合拼購買，會有以下組合優惠：

YubiKey 5Ci + Bitdefender 一年：HK$ 550
YubiKey 5 Nano + Bitdefender 一年：HK$ 390
YubiKey 5 NFC + Bitdefender 一年：HK$ 355
YubiKey 5C + Bitdefender 一年：HK$ 390
YubiKey 5C Nano + Bitdefender 一年：HK$ 470

詳情可以看： https://netmon.zohocommerce.com/categories/yubikey/45023000004418001（注意，不能直接在網站上購買，購買流程在下面有寫。）

（利申：我的 YubiKey 是自己用原價購買，而各位用以上優惠碼購物時，我是完全不會有任何佣金。）

購買的流程如下：

1. 先了解要買哪款型號、數量及價格，然後致電 Yubico 的官方認可香港分銷商 NetMon 查詢有沒有存貨。Coupon code 是 PAZU20。如果有貨，可以直接上觀塘鴻圖道的辦公室購買，以現金交收。

2. 可以先用 PayPal 或信用卡支付，然後寄到順豐站或「順便智能櫃地址」，運費由買家自行支付，目前順豐的運費有優惠，原價 HK$ 30，在 2019 年 10 月底前只用 HK$ 20。

Netmon Information Systems
地址：觀塘鴻圖道 57 號，南洋廣場 15 樓 1 室。
電話：25272086。
網址： www.netmon.asia

至於如何選擇 YubiKey，請看下面的問答：「有很多款 YubiKey，我到底應該選擇哪條？」

———

以下是第二次修訂的〈有關安全鑰匙 YubiKey，你問我答〉，刪去了一些概念重複的問題，又加入了數條問題，還有鳴謝相識於二十多年前的 Ben 深夜通電話，與我分享他的意見。

一

問：若果 YubiKey 安全鑰匙被其他人拿到，他們是不是可以直接登入我的戶口？

答：先說答案，不可以的。我們首先要搞清楚 YubiKey 的用途，它是用來作為登入戶口的其中一個因素，即是說，你要登入戶口，仍然需要帳號本身的密碼，以及 YubiKey，又或是其他因素，例如手機短訊（不建議）、authenticator app 的軟體六位密碼，或是備用的號碼。

所以即使別人取得你的 YubiKey，也不能單單使用 YubiKey 去登入你的帳戶。「二步認證」時需要你本身的密碼，以及一個額外的認證因素，才能登入戶口。

如果別人只是取得你的 YubiKey，但又沒有得到你的帳號密碼，那也是沒有辦法登入你的帳號。

二

問：我本身已經在手機裡用 authenticator app 去做二步認證，那為甚麼仍然要用 YubiKey 呢？

答：按保安級別來說，YubiKey 的 FIDO2（在線快速身份識別）比起 authenticator app 的 TOTP（基於時間單次密碼）較為優勝，而 Android 手機的漏洞又較 iPhone 的多。在 iPhone 上好像沒有怎麼出過事，但以前就曾經爆出，Android 機有惡意 app 成功利用保安漏動偷取了 app 二步認證的資料。

理論上去說，用安全鑰匙來做認證，肯定會較為安全。但很多用家，包括我自己，其實也會在手機上安裝 authenticator app。iPhone 較安全，但即使你用的是 Android，如果手機的廠家較為可信，堵塞保安漏洞的更新較快，你又不 root 機，又沒有胡亂安裝軟件，本身的風險未必算高。

那麼為甚麼本身已經有用 authenticator app，還要加一個安全鑰匙？我的原因，是因為使用硬件鑰匙，可以加快二步認證的速度及便捷程度，從而把這個二步認證，變成網絡生活的習慣。

三

問：我還是不明白，那麼說我豈不是可以直接用手機上的 authenticator app，為電腦登入做認證就可以了嗎？何以要另外花錢，給電腦買一條安全鑰匙？

答：因為我每天會登出登入戶口數次或以上，所以有必要加快這個過程。先說明一點，網絡保安的兩大關鍵。一是在可行的情況下，開啟二步認證。二是在每次上網之後，都要登出戶口，最好避免儲存電郵或社交媒體的登入狀態。

最簡單直接的設定，是每次關掉瀏覽器，就會自動刪去所有瀏覽記錄、登入狀態及 cookies，通常是在設定偏好，安全隱私裡可以設置。而我其實即使在自己的電腦上網，也習慣使用「私隱模式」去瀏覽網站。

當你養成了這個習慣，每天也要登入登出戶口數次。如果你每次看到登入的畫面，都有一種不安的恐懼感，擔心自己不懂如何登入，那麼更加要熟習登出登入的過程，每天登出登入，把登出登入變成生活的習慣，就不會見到 log in 畫面時便忍不住向空氣驚叫或斥罵一聲。如果你已經記不清對上一次是何時登入帳號，那只代表你的戶口經常處於「登入」的狀態，這是保安漏洞，也是很壞的上網習慣，一定要改。

由於每天登出登入的次數較多，如果能夠安全地加快這個速度，就是值得考慮的方案。我具體去說一下，authenticator app 跟 YubiKey（或其他硬體驗證）在使用習慣上的分別。

假如你一天要登出登入帳戶五次，如果用的是手機 authenticator app 去做認證，安全程度也算是足夠，但每次都要先找來手機，然後輸入手機的開機密碼，打開 authenticator app，我用的是 Lastpass Authenticator，之後取得六位數字後，複製到剪貼簿，再把六位數字傳送去電腦，或手動輸入，再按確認，這樣才能登入戶口。

但如果有 YubiKey 或其他硬件認證，過程就相對快速。先輸入帳戶密碼，從鎖匙扣或錢包裡拿出 YubiKey，把 YubiKey 插進電腦，掃一掃上面的金屬圈，便能登入。而我用的 YubiKey，是細小得可以長期插在電腦的 USB C 插頭（一些熟知技術的讀者，知道我的電腦長期插著安全鑰匙，可能會響警號，稍安毋躁，我將會說清楚這個安全隱患）。我每次登入戶口時，先是用手指打完密碼，然後直接伸手在電腦旁邊摸一摸 YubiKey 的金屬環，便能登入。

所以用 YubiKey 的原因，在我的情況，並不是要把它當成唯一的二步認證因素，而是要加快二步認證的過程。對於不同的用家，這個速度是否重要，很看使用習慣。即使這個速度不重要，單純基於保安考慮，用了安全鑰匙，整個系統的保安級別有所提升。

四

問：我應該要有一條還是兩條 YubiKey 呢？

答：按官方的說法，最好是兩條，因為一條常用，另一條則做後備。但對於大多數用戶來說，其實用一條也是足夠。我會建議大家先買一條，再以其他方式去做後備的密碼重設方案，例如其中一個二步認證的「因素」是 YubiKey，但同一個戶口，要加上 authenticator app 做另一個認證的方案。之後有需要，再買不同型號的安全鑰匙。

如果你本身打算參加 Google 的高級保護計劃（Advanced Protection Program），你是必須有兩條鑰匙。不過參加了這個計劃之後，使用 Google 的所有服務都會極為不便，我自己也沒有參加。

簡單來說，對於不打算參加 Google 高級保護計劃的用家來說，只要有後備的認證方案，那麼一條安全鑰匙，也是足夠的。

五

問：YubiKey 會否影響我使用 WhatsApp、Telegram 或 Signal？

答：YubiKey 不支援 WhatsApp、Telegram 或 Signal，所以不會影響你使用這些聊天軟件。

六

問：Google 官方推介的那款安全鑰匙，叫 Titan，為甚麼你反而要推介瑞典出品的 YubiKey？

答：Titan 的製造商是飛天誠信（Feitian Technology），總部設於北京。這家公司獲得不少國家認證及讚許，官方對其安全產品及科技成就予以高度的認可及肯定，目前並沒有證據顯示這家公司的產品有後門或安全漏洞。

所以，我選擇用瑞典及美國製造的 YubiKey。

還有，大家可以比較兩者的設計，YubiKey 真係靚仔好多。

答完這條問題後，發覺 Google 在 2019 年 10 月 15 日（剛好是此文修訂版發佈同一天）推出了一條新的 Titan，這次是跟 Yubico 合作，新的 Titan，設計外觀上跟 YubiKey 5C 大同小異。可能之前 Google 跟 Feitian 的合作，確實引來太多揣測，這次才找瑞典的 Yubico。

七

問：如果有人用 YubiKey 插進我的電腦，是否沒有密碼就能直接打開電腦？

答：這個要看你如何設置，如果你想設置為開啟電腦時，要先輸入密碼，再插入 YubiKey 才能登入電腦，那你應該要使用 pluggable authentication module（PAM，可插拔認證模塊）。相關設定請看 https://support.yubico.com/support/solutions/articles/15000015045-macos-logon-tool-configuration-guide

如果你使用 PAM 模塊的設定，即使別人取得你的 YubiKey，也不可以打開你的電腦，他是必須有你的 YubiKey，加上你本身開機的密碼，才能登入電腦。

不過話又說回來，如果是使用電腦，只要設定妥當，其實不用配合 YubiKey 開機，也算安全。因為我是用 Mac 機，也只能用 Mac 機的情況去說一下，如何才算安全。

1. 你常用的開機戶口的權限只是 standard 而不是 admin。
2. 你的硬盤本身有開啟加密，即 FileVault。
3. 你本身 admin 及 standard 的戶口密碼夠強。

這三點當中，以第三點最為容易被用家忽略，很多人為了貪方便，開機密碼簡單到不能再簡單，有些密碼甚至只有三四個位，極易被破解。尤其開機的密碼，是容許不停地試，即可以使用「蠻力」（brute force）去猜度，所以一定要小心選擇。

舉個例子，如果你的密碼是 west，破解的時間是 @_$*，兩組密碼，哪個較難破解？前面的那個，是馬上立即就能被破解，而後面這個，用的時間較多，是用一個微秒，也就是一百萬分之一秒而已！

至於如何選擇強勁密碼，不妨參考骰子密碼法（Diceware），也就是用一粒骰仔，投擲出六位的隨機數字，再用這個數字，透過列表，選擇其對應的字，都是一些字典中可以找到的字詞，如果選擇了七個以上的字詞，這個密碼就很難破解了。有關說明，詳見：https://en.wikipedia.org/wiki/Diceware

大家也可以去這裡測試一下自己的密碼安全程度，不要輸入真的密碼，差不多就可以，我的密碼，聲稱是要用 919 萬億年才能破解。 https://howsecureismypassword.net/

八

問：你認為我可以長期把安全鑰匙插在電腦嗎？

答：要看使用的場景，以及自己的需要。如果處於高風險環境，把安全鑰匙長期插在電腦中，是不衛生的做法，一些機構甚至明確要求員工不能這樣做，雖然大多員工會對這個建議置若罔聞。

我的 YubiKey 是用來登入網上的帳號，而不是登入電腦（可以看看上一條問題）。先說我的習慣，我是長期把 YubiKey 插在電腦中，有兩款較細小的型號可以做到這點，分別是 YubiKey 5 Nano 及 YubiKey 5C Nano。

但我們首先要明白自己想防範的是甚麼，再評估應該要做的安全措施。以我的情況，密碼是極難猜的（按不一定科學的估計，我的密碼可能要 919 萬億年才能破解），而我的密碼又完全不重複，不同網站也會用不同的密碼，所以如果密碼洩露，有三個較大的可能，一是服務供應商的問題，二是電腦被人安裝了惡毒軟件或不乾淨的瀏覽器 add-ons，例如鍵盤記錄器（keylogger）或直接偷取密碼發到遠方，三是上了釣魚網站。至於其他難測的漏洞，很難估計，在這裡就不討論。

對於第一點，能夠用上二步認證的服務，本身保安做得較好，即使系統受到入侵，估計（估計而已！）密碼的記錄也有加密，所以因為服務供應商的漏洞而洩露密碼的情況很低。至於第二個情況，我本身用的是 Mac，Mac 不是完全沒有病毒或惡毒軟件，所以我儘量不安裝來源不明的東西，有時逼不得已要安裝，也只會在虛擬的環境（virtual machine）中進行。較大的風險可能是瀏覽器的 add-ons 或 extensions，只好儘量找些評分高，信譽好的插件來安裝。

第三個情況，即釣魚網站（phishing sites） ，通常是假冒的銀行網站。這些網站弄得像是真網站（其實通常還是有些破綻，例如圖片的成像差一些，圖片起角，字體模糊，拼錯英文等等，倒是有點像藍絲的美學風格）。總之打開一些需要登入的網站，都會留意清楚網址，又或是看看有否證書。每次上銀行網站、Google 及 Facebook 等，都一定要加倍小心，因為即使用了二步認證，釣魚網站是可以同時騙取密碼及驗證碼。如果忽然收到電郵，提供連結叫你輸入密碼，更要加倍留意。

總之評估了自身的使用習慣，最需要防範的風險，是壞人從遠處入侵電腦，並偷取或截取密碼，再入侵我的戶口。所以我只要確保我的認證因素，一個是發到線上的密碼，另一個是線下的因素便可以。即使有人從網絡取得我的密碼，他的手也不能伸到我的手機或安全鑰匙，企圖登入我的戶口，他們要同時取得我的硬件及手機上的二步認證因素，其可能性始終很低。

另外有些要防範的情況，例如你在公司使用電腦，鄰座的同事相當有可疑，又可以近距離碰到你的電腦，自然就要加倍小心，不要長插鑰匙。你的安全顧慮，也可以因為不同的司法環境，或是本身的敏感程度而改變。若果你是一直備受監控的對象，入侵者有計劃也有資源去取得你的密碼，例如派人偷拍你在咖啡館輸入密碼的情形，入侵者甚至可以取得法庭搜查令，採用不道德的公權力去挾持你的電腦及其安全鑰匙。如果是這樣，你要採取的安全級別，可能要高出其他人很多倍，例如斯諾登要求到訪者把手機的電池取出，又或是要求把 iPhone 等關機後放進雪櫃或 faraday bag。如果你認為他有妄想症，不妨讀一讀《No Place to Hide》（作者 Greenward）又或是《Permanent Record》（作者就是斯諾登本人）。

說了一大堆，其實就是說，評估過自身的風險後，我使用 YubiKey 的習慣，是經常把它插在電腦上。我不覺得會危害到戶口安全，也不認為會降低安全系數，大家自行評估相關風險。

九

問：為甚麼我覺得 YubiKey 有伏？真的安全？這個東西有沒有後門？

答：可能因為你不了解這個技術，所以覺得有伏。

說實在的，當我看到這樣的提問，確是頗感驚訝呀，就像看到有人堅拒打疫苗因為擔心會自閉一樣驚訝。

十

問：有甚麼服務是支援安全鑰匙的二步認證呢？

答：對香港人而言，可能有機會用到而又支援安全鑰匙的服務包括：Google (Gmail, Drive, Youtube, Cloud Platform), Facebook, Dropbox, Github, Amazon Web Services, 1Password (版本7以上), Lastpass (Premium), Bitwarden, Dashlane, Boxcryptor (免費版也支援), Twitter 等等。

至於 Apple ID 戶口則不支持安全鑰匙，但有提供其他方式的二步認證。

十一

問：我是用 iPhone，為甚麼我覺得這類產品對 iPhone 的支援，好像很弱很不足呢？

答：因為這類產品，對 iPhone 的支援，真的很弱很不足啊！即使 YubiKey 出了一款 5Ci 有 lightning 連接頭，但只有極少量的 apps 支援。如果你是用 MacBook 加 iPhone，我建議你只用買 YubiKey 5 (Nano) 或 5C (Nano)，而不用為 iPhone 買 5Ci 那款，那個 lightning 接頭很雞肋。

對於 MacBook ＋ iPhone 的用家來說，最適合的方案，是在 MacBook 用 YubiKey，在 iPhone 還是用 authenticator app。

如果你只有 iPhone，沒有電腦，那麼很簡單，乾脆不用買安全鑰匙，用 app 去做二步認證就可以。（如果你本身是單機 iPhone 的用家，讀到這裡，才發覺原來我是不建議單機 iPhone 用家使用安全鑰匙，可能會覺得浪費了寶貴的閱讀時間，但希望這篇文章裡其他保安知識，也會對你有幫助啦！）

十二

問：萬一我的安全鑰匙遺失了，我是否不能再登入我的戶口呢？

答：要看你如何設定，但先說答案，不是。如果你遺失了鑰匙，還是可以登入戶口。安全鑰匙只是登入戶口的其中一個認證因素，但你同時可以設定其他方式去認證。

其他認證的方式包括：

1. 手機短訊（SMS）：因為 SMS 的保安差，不建議。若然真的要用手機短訊，可以用不同居又可信任的朋友手機號碼，而這個電話號碼，最好不是存在手機的電話簿內。

2. Authenticator app：在 iPhone 及 Android 都有這類 app，我推介的是 Lastpass Authenticator，免費使用，軟件本身可以加上六位數字的密碼鎖。如果你想讓朋友幫你作為後備的方案，建議把設定的二維碼發給朋友，而該朋友又不是朝夕相對，一個 app 裡是可以儲存大量網站的認證碼，而且可以標明服務及戶口名稱，以作識別。

3. 安全鑰匙：也就是硬件認證方式，其中最多人使用的，是本文裡提到的 YubiKey。

4. 後備認證碼：部份網站，例如 Google 及 Facebook，會提供八個後備認證碼，可以寫下來，放在安全的地方，但有時貪方便，會儲存在電腦裡（其實不建議這樣做）。

所以，萬一遺失了安全鑰匙，只要設置合宜，其實也不代表不能用其他認證方式去登入戶口。而在設定了二步認證後，也應該要做一些練習，想像一下，萬一丟失了手機後，你還能用甚麼方式登入呢？如果你的手機、電腦及安全鑰匙全都放在公事包裡，而整個公事包被盜，你還有其他可行的二步認證方式嗎？手機丟失，你不能用 authenticator app。電腦丟失了，而你又貪方便只把後備碼儲存在電腦裡，連電腦也丟失了可以怎麼辦？如果你把不同居的朋友手機號碼作為後備的驗證方案，你能夠單憑手機最後兩個數字，就想起這位朋友嗎？網絡保安，除了要有措施，還有要反複練習。

另外，如果你使用的是 Google 最高級別的保安計劃（即 Google Advanced Protection Program），那就真的只能用兩條安全鑰匙進行登入。我本身是用 iPhone 及 Mac，因為安全鑰匙對於 iPhone 的支援太弱，所以我也沒有加入這個計劃。

還有，萬一你喪失了所有認證因素，其實 Google 或是 Gsuite 的管理人，仍然有辦法幫你重設密碼，但 Google 方面的驗證需要很多天，而且過程要問上大量問題，入侵者也不易通過。至於 Gsuite 的管理人，即使他單方面想幫你重設戶口密碼，這個雖然可能會成為另一個安全隱患漏洞，但他們也只能把密碼發到你後備的聯絡方式，而且當中也要有幾重驗證的過程，亦要花上一至數天。只要你那個後備的聯絡方式設定得較安全，入侵者也不能輕易破解。

十三

問：有很多款 YubiKey，我到底應該選擇哪條？

答：有三個考慮因素，一是你用甚麼電腦，二是你用甚麼手機，三是你用甚麼服務。我把幾種可能的情況寫出來，大家參考一下。要先說一點，因為 iPhone 對 YubiKey 或安全鑰匙的支援不好，所以按目前的情況，iPhone 的用家在手機上還是建議用 authenticator app 算了，即使你用的是 NFC 或 lightning 版的安全鑰匙，能夠支援的服務還是太少，可以忽略。選用哪款鑰匙，也要看自己的使用習慣，請參看「每次登入戶口時，都要把安全鑰匙插在電腦，有點麻煩，你認為我可以長期把安全鑰匙插在電腦嗎？」。

簡單來說，如果你打算長期把安全鑰匙插在電腦，就買 Nano 版，如果經常需要拔插，就買長一點的版本，方便拔插。如果你是用 Android，可以考慮買 NFC 的版本，如果是用 iPhone，因支援較弱，還是用 authenticator app 算了。

再具體一點去說，我根據以下的電腦及手機組合，建議使用的安全鑰匙型號。

1. 只有用桌面或手提電腦（USB A接口）：用 5 Nano 或 5C（按我的習慣，會用 5C Nano）。
2. 只有用桌面或手提電腦（USB C接口）：用 5C Nano 或 5C（按我的習慣，會用 5C Nano）。
3. 使用 12 吋的 MacBook（只有一個 USB C 接口的電腦）：用 5C 或 5C NFC（就快推出），而不要用 5C Nano，因為只有一個 USB C 接頭，要經常拔插，用 5C 或 5C Nano（暫未推出）會較好。
4. 電腦 (USB A接口) + iPhone (Lightning接口)：用 5 Nano 或 5 NFC（在 iPhone 上不用）。
5. 電腦 (USB A接口) + Android (USB C接口)：用 5 NFC。
6. 電腦 (USB A接口) + Android (MicroUSB接口)：用 5 NFC。
7. 電腦 (USB C接口) + iPhone (Lightning接口)：用 5C Nano 或 5C（在 iPhone 上不用）。
8. 電腦 (USB C接口) + Android (USB C接口)：用 5C NFC（就快推出，暫時未有啊，如果現在用的話，建議可以先買一個 Yubikey 5C Nano，只在電腦上用，手機上則用 app）。
9. 電腦 (USB C接口) + Android (MicroUSB接口)：用 5C NFC（就快推出，暫時未有啊，如果現在用的話，建議可以先買一個 Yubikey 5C Nano，只在電腦上用，手機上則用 app）。
10. 使用 12 吋的 MacBook（只有一個 USB C 接口的電腦）+ iPhone（Lightning接口）：用 5C 或 5C NFC（暫時未出），不建議用 5C Nano。
11. MacBook Air（有兩個USB C接口）：因為兩個 USB C 接口都在機身左邊，如果不會長期用 hub，那麼用 5C Nano 也可以。如果這個插口本身又要連 iPhone 或其他設備，那麼用 5C 會較好。
12. 以上任何配搭，但用的百度雲、淘寶、QQ 郵箱等：不用買。

至於 Security Key by Yubico 這一款，則可以用在電腦 (USB A接口) 上，沒有 NFC 功能，屬較為基礎的一款。之前 YubiKey 慷慨送給香港人的型號，就是這個。對於自己有能力購買的用家，請按上文所述的建議，對應自己的機型去購買。

另外，如果打算用轉換頭（例如 USB A 轉 USB C），請看看相關兼容情況：https://support.yubico.com/support/solutions/articles/15000006473-using-a-yubikey-with-usb-c-adapters （因為沒辦法逐一去試，萬一打開 YubiKey 的包裝後，發覺本身使用的 hub 或轉換器兼容不了，那就得物無所用，所以我不是太過建議用轉換頭。如果真的想用轉換頭，最好找朋友的安全鑰匙插進自己的電腦，再去 https://www.yubico.com/genuine/ 測試能否認出。

十四

問：可以在哪裡購買 YubiKey？

答：上官網 Yubico.com，在香港則去官方認可的香港分銷商。

購買這類安全產品，跟買安全套一樣，理論上是要避免使用中介渠道或集運公司，因為理論上越多中間人，那麼理論上就越大機會被人做手腳。

其中一種做手腳的方式，是企圖入侵的人，把鑰匙裡的物理序列號偷偷記錄，並用其他方式去產生密鑰。強調是「理論上」，因為估計實行起來，也非容易，太多顧慮，聽起來好像又太多疑，但既然說到網絡安全，當然要在各個可行的層面，也儘量做好防範的措施。例如萬一你的鑰匙被人偷走，非法扣留，又或是買回來的時候包裝已經打開，最好不要再用。

Yubico 的官方網站顯示，在香港有一個官方認可以的分銷商：Netmon Information Systems，地址是：觀塘鴻圖道 57 號，南洋廣場 15 樓 1 室。電話是 25272086。網址是 www.netmon.asia ，建議在辦公時間先打電話去查詢存貨量。

———

延伸閱讀：

陳婉容幫助香港人取得瑞典公司 Yubico 的贊助：https://www.facebook.com/sherrychanyy/photos/a.517784544922353/2803649153002536/?type=3&permPage=1

電腦手機網絡安全（一）：SIM 卡鎖：https://www.facebook.com/pazukong/photos/a.2007886759444126/2634928633406599/

電腦手機網絡安全（二）：簡介二步認證：https://www.facebook.com/pazukong/photos/a.2007886759444126/2636315873267875/

電腦手機網絡安全（三）：二步認證的驗證因素：https://www.facebook.com/pazukong/photos/a.2007886759444126/2637695243129938/

———

* 想追看薯伯伯的文章，請設定本 Page 為「搶先看 / See First」*

Instagram 🥑🥭🍉🍌: pazu

新博客：http://pazu.com/blog

另外還要提一提大家：

【新書速報】Pazu 薯伯伯《不正常旅行研究所》（白卷出版社）——從西藏拉薩到神州大地；由亞洲各國至中東地區。非常人般玩轉奇異世界、紀錄精彩故事文化習俗。

在旺角序言、北角森記、誠品書店及各大書店，均有代售！其中在旺角序言及北角森記，有少量簽名版本。

電腦手機網絡安全（四）：有關安全鑰匙 YubiKey，你問我答

文：薯伯伯

早幾天寫了一篇文章，提到二步認證的安全鑰匙 YubiKey，無獨有偶，《立場》的另一位博客，《茉莉花開：中東革命與民主路》的作者陳婉容原來早在七月份就聯絡了瑞典的 Yubico 公司，希望他們可以贊助香港抗爭者五百條 YubiKey，在核實身份後，這家瑞典公司慷慨地向寄出了五百條 YubiKey，實在令人感動。

我發覺不少人對於 YubiKey 的功能及用法均有誤解，甚至有人認為「有伏」，或誤以為用上 YubiKey 後反而更危險。我回應了一些評語，整合之後發到自己的臉書專頁，《立場》的編輯看到，問可否轉載到《立場》，所以我又花了一點時間，再次整理一下文稿，就成了這篇文章。以下的問題，部份是在陳婉容的臉書帖文評語區選取，我把部份的用字修改。

一

問：若果硬體及 YubiKey 都被其他人拿到，怎辦？

答：即使其他人取得你的 YubiKey，也不能單單使用 YubiKey 便登入你的帳戶。「二步認證」是需要你本身的密碼，以及一個額外的認證因素，才能登入戶口。所以如果別人只是取得你的 YubiKey，但又沒有得到你的帳號密碼，那也是沒有辦法登入你的帳號。

二

問：我本身已經用 Authenticator app 去做二步認證，而不是用手機短訊，那為甚麼仍然要用 YubiKey 呢？

答：用 authenticator app 去做認證，本身已經算是較為安全，但相比起 YubiKey 或其他硬件認證，使用 app 較為花時間，也可能因此較難歸入日常網絡安全生活的一部份。

先說明一下，我強烈建議每次上網之後，都要登出 Facebook 及 Gmail 的戶口，不要長期處於登入的狀態，儘可能避免使用 Facebook app 或 Gmail app，最好是用瀏覽器登錄，並設定瀏覽器關閉的時候，會自動把 cookies 刪除。又或者乾脆使用「隱私模式」，不留痕迹。要把登出及登入，變成上網的常態，要反複練習。

如果你一天要登錄帳戶五次，假如用的是 app 去做認證，安全是安全，但每次都要先找來手機，輸入手機密碼，打開 authenticator app，可能也要再輸入一次 app 密碼，取得六位數字後，再把六位數字傳去電腦，或手動輸入，再按確認，這樣才能登入戶口。

但如果有 YubiKey 或其他硬件認證，過程就相對快速。先輸入帳戶密碼，把 YubiKey 插進電腦，便能登入（注意是密碼加硬件，單靠 YubiKey 是不能登入）。如果你所處的環境是較安全，例如數小時裡都在家中，那隻 YubiKey 可以一直插在電腦，雖然不算完美，但尚能接受。

用上二步認證，是極為關鍵的保安措施，但很多人是因為二步認證的過程繁瑣，所以棄用或懶得去用，從而嚴重危害到戶口安全。YubiKey 的作用，是加速了二步認證的速度，但又不會降低安全系數。

三

問：我應該要有一條還是兩條 YubiKey 呢？

答：按官方的說法，最好是兩條，因為一條常用，一條做後備。但對於大多數用戶來說，其實用一條也是足夠。我會建議大家先買一條，再以其他方式去做後備的密碼重設方案，例如 YubiKey 加上 authenticator app，或記下後備的認證碼（通常有八組，可以交給朋友代為保管）。不過後備的密碼重設方案，不應該用自己的手機號碼。

至於是否需要用兩條，如果你本身打算參加 Google 的高級保護計劃（Advanced Protection Program），你是必須有兩條鑰匙。不過參加了這個計劃之後，使用服務時是極為不便，尤其如果你是用 iPhone 就更為麻煩。（即使是講到明支援 iOS Lightning 接頭的 YubiKey 5Ci，還是不支持 Google 的高級保護計劃認證。）

方便與安全，往往是對立，要取得一個平衡點。我覺得二步認證的安全系數已經足夠，除了特殊的人群，大多數人也沒有必要參加高級保護計劃。而對於不打算參加高級保護計劃的用家來說，一條鑰匙，也是足夠的了。

四

問：YubiKey 會否影響我使用 WhatsApp、Telegram 或 Signal？

答：YubiKey 不支援 WhatsApp、Telegram 或 Signal，所以不會影響你使用這些聊天軟件。

YubiKey 支援的服務，常用的包括 Google 戶口、Facebook、Dropbox 等，還有很多，這裡不一一列出。

五

問：Google 官方推介的那款安全鑰匙，叫 Titan，為甚麼你反而要推介瑞典出品的 YubiKey？

答：Titan 的製造商是飛天誠信（Feitian Technology），總部設於北京。這家公司獲得不少國家認證及讚許，並對其安全產品及科技成就作出高度的認可及肯定，目前並沒有證據顯示這家公司的產品有後門或安全漏洞。

所以，我選擇用瑞典及美國製造的 YubiKey。還有，大家可以比較兩者的設計，YubiKey 真係靚仔好多。

六

問：如果有人用 YubiKey 插進我的電腦，是否沒有密碼就能直接打開電腦？

答：這個要看你如何設置，如果你想設置為開啟電腦時，要先輸入密碼，再插入 YubiKey 才能登入電腦，那你應該要使用 pluggable authentication module（PAM，可插拔認證模塊）。相關設定請看 https://support.yubico.com/support/solutions/articles/15000015045-macos-logon-tool-configuration-guide

如果你是用 PAM 模塊的設定，即使別人取得你的 YubiKey，也不可以打開你的電腦，他是必須有你的 YubiKey，加上你的密碼，才能登入電腦。

不過話又說回來，如果是使用電腦，只要設定妥當，其實不用 YubiKey 開機，也算安全。因為我是用 Mac 機，也只能用 Mac 機的情況去說一下，如何才算安全。

1. 你常用的開機戶口的權限只是 standard 而不是 admin。
2. 你的硬盤本身有開啟加密，即 FileVault。
3. 你本身 admin 及 standard 的戶口密碼夠強。

這三點當中，以第三點最為容易被用家忽略，很多人為了貪方便，開機密碼簡單到不能再簡單，很易被破解，尤其開機的密碼，是容許不停試，即可以使用「蠻力」（brute force）去猜度，所以一定要小心選擇。至於如何選擇強勁密碼，不妨參考骰子密碼法（Diceware），詳見：https://en.wikipedia.org/wiki/Diceware

大家也可以去這裡測試一下自己的密碼安全程度，不要輸入真的密碼，差不多就可以，我的密碼，聲稱是要用 919 萬億年才能破解。 https://howsecureismypassword.net/

七

問：我本身用密碼管理器，密碼是極為複雜，這樣不是已經很安全了嗎？為甚麼還要用 YubiKey？

答：即使是再安全的密碼，如果你的密碼管理器被破解，又或是被人安裝了鍵盤記錄器（keylogger），再複雜的密碼也沒有用，入侵者照樣可以輕易登入你的帳號。所以一定要有二步認證，而為了加快二步認證的過程，並把這個過程變成生活一部份，用硬件認證，是較好的方式。

當然，如果你真的覺得 authenticator app 已經足夠，其實也不一定要付費買安全鑰匙。只是，我兩者皆用過，我覺得鑰匙方便很多。

八

問：為甚麼我覺得有伏？真的安全？？這個東西有沒有後門？

答：可能因為你不了解個技術，所以覺得有伏。

九

問：我是用 iPhone，為甚麼我覺得這類產品對 iPhone 的支援，好像很弱很不足呢？

答：因為這類產品，對 iPhone 的支援，真的很弱很不足啊！即使 YubiKey 出了一款 5Ci 有 lightning 連接頭，但只有極少量的 apps 支援。如果你是用 MacBook 加 iPhone，我建議你只用買 YubiKey 5 (Nano) 或 5C (Nano)，而不用為 iPhone 買 5Ci 那款，那個 lightning 接頭很雞肋。

對於 MacBook ＋ iPhone 的用家來說，最適合的方案，是在 MacBook 用 YubiKey，在 iPhone 還是用 authenticator app。

十

問：可以在哪裡購買 YubiKey？

答：上官網 Yubico.com，或是去官方認可的香港分銷商。

購買這類安全產品，跟買安全套一樣，理論上是要避免使用中介渠道或集運公司，因為理論上越多中間人，那麼理論上就越大機會被人做手腳。

其中一種做手腳的方式，是企圖入侵的人，把金鑰裡的物理序列號偷偷記錄，並之後用其他方式去產生密鑰。強調是「理論上」，因為估計實行起來，也非容易，太多顧慮，聽起來好像又太多疑，但既然說到網絡安全，當然要在各個可行的層面，也儘量做好防範的措施。例如萬一你的鑰匙被人偷走，非法扣留，又或是買回來的時候包裝已經打開，就最好不用。

Yubico 的官方網站顯示，在香港有一個官方認可以的分銷商：Netmon Information Systems，地址是：觀塘鴻圖道 57 號，南洋廣場 15 樓 1 室。電話是 25272086。網址是 www.netmon.asia ，建議在辦公時間先打電話去查詢存貨量。

———

延伸閱讀：

《Yubico 贊助香港抗爭者世上最強網上保安鎖匙Yubikey》（文：陳婉容）：https://www.facebook.com/sherrychanyy/photos/a.517784544922353/2803649153002536/?type=3&permPage=1

電腦手機網絡安全（一）：SIM 卡鎖：https://www.facebook.com/pazukong/photos/a.2007886759444126/2634928633406599/

電腦手機網絡安全（二）：簡介二步認證：https://www.facebook.com/pazukong/photos/a.2007886759444126/2636315873267875/

電腦手機網絡安全（三）：二步認證的驗證因素：https://www.facebook.com/pazukong/photos/a.2007886759444126/2637695243129938/

———

* 想追看薯伯伯的文章，請設定本 Page 為「搶先看 / See First」*

Instagram 🥑🥭🍉🍌: pazu

新博客：http://pazu.com/blog

另外還要提一提大家：

【新書速報】Pazu 薯伯伯《不正常旅行研究所》（白卷出版社）——從西藏拉薩到神州大地；由亞洲各國至中東地區。非常人般玩轉奇異世界、紀錄精彩故事文化習俗。

在旺角序言、北角森記、誠品書店及各大書店，均有代售！其中在旺角序言及北角森記，有少量簽名版本。