Twitter 的 MFA 可以加入多支 YubiKey 了

我手上有好幾隻 YubiKey,目前幾個有在用的服務都有支援同時綁定多組 U2F/WebAuthn 的能力 (像是 FacebookGitHub)。

Twitter 一開始推出的時候也可以支援多組,但在去年 2020 年八月的時候發現這個功能被拔掉,只能放一把進去。

我自己開了一張 ticket 定時回頭看一下有沒有修正,剛剛定期回顧發現這個功能被加回來了,而且官方的文件上也加上去了:「How to use two-factor authentication」。

翻了一下 Internet Archive 上的資料,看起來是 3/113/16 中間更新文件的...

手上有多把 security key 的人也可以處理一下。

架設 Proxy over TLS

HTTP Proxy 算是很好用的跳板手段,瀏覽器有很多套件可以依照各種條件自動切換到不同的 Proxy 上面。

但一般在使用 HTTP Proxy (走 Port 3128 或是 8080 的那種) 使用明文傳輸,就不適合使用 Proxy-Authenticate 把帳號密碼帶進去 (出自 RFC 7235 的「Hypertext Transfer Protocol (HTTP/1.1): Authentication」),查了一些資料後發現,現在的瀏覽器基本上都支援 Proxy over TLS 了,也就是 Proxy Protocol 外面包一層 TLS,保護瀏覽器到 Proxy 中間的流量。

順便說一下,這邊講的 HTTPS Proxy 跟環境變數裡的 HTTPS_PROXYhttps_proxy 不太一樣,這兩個環境變數是說「HTTPS 協定要走哪個 Proxy 設定」。

HTTPS Proxy 主要有幾份文件可以參考,第一份可以是 Squid 的「Feature: HTTPS (HTTP Secure or HTTP over TLS)」,裡面提到了伺服器上的設定 https_port,以及瀏覽器的支援度。

第二份是認證的部份,也是 Squid 的文章「Proxy Authentication」這篇,走 ncsa 認證基本上就可以吃熟悉的 .htpasswd 格式了。

接下來就是安裝與設定了,在 Ubuntu 20.04 可以直接用 apt 裝 squid4,因為有包括了 --enable-gnutls;而在 Ubuntu 18.04 就不能這樣做了,因為 Ubuntu 裡面是 squid3,而且沒有加上 --enable-openssl 或是 --enable-gnutls,會比較麻煩...

其他基本上就是塞設定進去就可以了... 然後 Google Chrome 這邊可以裝「Proxy SwitchyOmega」這種套件,他可以設定 HTTPS Proxy 的 Profile,然後依照網域名稱來設定要用哪個 Profile。

這樣做的好處就是不需要連 VPN 改變 routing table (通常需要登入),就有類似 VPN 的效果,而且可以很細緻的調整流量要怎麼繞。

而且機器上也不需要 shell account 讓人跑 ssh -D1080 之類的指令開 Socks Proxy,要給朋友共用也比較簡單。

先架了台灣跟美國的,找機會再多架一些伺服器起來用...

Vault 裡 AppRole 的設計,以及怎麼解決 Secret Zero 問題

VaultHashiCorp 拿來管理各種敏感資訊的軟體,像是 API token 或是資料庫的帳號密碼。把這些資訊集中控管後就不需要把這些資訊放進 Git (超爽的?),而是在需要的時候由應用程式呼叫 Vault 取得。

而 Vault 的設計裡面要求應用程式需要「認證」後才能取得,結果這個「認證」又是一組敏感資訊,這就是 Secret Zero 問題,屬於雞蛋問題的一種。

找了一輪發現 HashiCorp 自家的說明解釋的最清楚,不過這篇是放在 blog 上的文章:「Tackling the Vault Secret Zero Problem by AppRole Authentication」。

Vault 在解決 Secret Zero 的方法是使用 AppRole,這邊的認證包括了 role_idsecret_id 的設計。比較特別的是一組 role_id 可以有多組 secret_id 對應。

在 AppRole 這樣的設計下,權限會綁在 role_id 上,而 secret_id 則可以在部屬時動態產生,像是官方提到的 TerraformChef,或是依照組織裡面使用的管理工具:

這樣就可以透過 role_id 管理權限,但不用在 Git 裡面寫死 Secret Zero 資訊,而且每台機器都有自己的 secret_id 可以提供稽核記錄,把幾個比較明顯的問題解了不少...

Open Distro for Elasticsearch 的比較

先前提到的「AWS 對 Elastic Stack 實作免費的開源版本 Open Distro for Elasticsearch」,在「Open Distro for Elasticsearch Review」這邊有整理了一份重點:

可以看到主要重點都在安全性那塊...

移除 Facebook 上的行動電話

Facebook 上的行動電話號碼除了被拿來當作 2FA 的備案外,也被強制分享。更糟的是還被拿來當作廣告的條件:

目前同時有 TOTP (Facebook 的 app 提供的) 與 U2F,完全不會用到簡訊認證,就拔掉吧...

G Suite 推出 LDAPS 認證,但是 Business 版本不支援...

公司裡面有人提到去年的這個消息,說 G Suite 可以直接提供 LDAPS 認證:「Secure LDAP now generally available to simplify the management of traditional applications」,在裡面提到了另外一篇講的比較詳細的文章也可以參考:「Cloud Identity now provides access to traditional apps with secure LDAP」。

這個功能等於是把傳統的應用程式直接掛上去,瞬間搞定一堆應用,不用再自己透過 SAML 或是各種 API 接半天...

不過看了一下提供服務的對象,發現 G Suite 的 Business 版本不支援,只有 Enterprise 與教育版本有支援,或是買 Cloud Identity 的 Premium 版本:

Editions:
Available to G Suite Enterprise, G Suite Enterprise for Education, G Suite for Education, and Cloud Identity Premium editions only

這樣就苦了點... 目前遇到的人大多數都是買 Business 而非 Enterprise。

CA/Browser Forum 上的會議記錄:關於密碼與 2FA 的強制要求

CA/Browser Forum 會定時將會議記錄與最後的結論公開放在網站上,有時候有些資訊還蠻有趣的。像是前幾天在「Ballot 221 - Two-Factor Authentication and Password Improvements - CAB Forum」這邊看到 CA/Browser Forum 的成員對密碼與 2FA 提出了修正提案,其中瀏覽器端只有 Microsoft 參與投票,但是被否決了...

不知道否決的原因,但是大概可以猜到幾個點。

第一個是提案提到了 NSANIST 800-63B Appendix A,這個單位不太受歡迎啊...

第二個則是「For accounts that are accessible only within Secure Zones or High Security Zones, require that passwords have at least twelve (12) characters;」這段強迫使用密碼,而現在有比密碼更安全的方案存在 (以 public key cryptography 為認證基礎的方案),像是早期的 U2F 以及今年定案的 WebAuthn

應該是這些原因吧...