在南極洲收銀行 OTP 簡訊的方式

看到「SMS Multifactor Authentication in Antarctica」這篇,講在南極洲收銀行 OTP 簡訊的方式 (one-time password,常見的形式是六碼或是七碼數字)。

很明顯的,南極洲沒有什麼電信商可以讓你漫遊 XD

一開始是試著用 Verizon Messages Plus,這個服務可以在電信商直接把簡訊改成 e-mail 寄出來,但作者發現所有的簡訊都會轉送,就是銀行的不會轉送 XDDD

接著是試著用 Google Voice 的號碼,但銀行會判定為 VoIP 電話而不送。

另外的方式是「Wifi Calling」,看起來應該是 VoWiFi 這個台灣更常見的詞,透過 internet 連到電信商的網路掛進去,而不需要透過電信商的基地台。

McMurdo 的網路目前還是有很多不一樣的限制與問題:

At McMurdo, phones have access to a wifi network only for wifi calling and texting, not for general Internet access. It’s just a prototype at this time. It doesn’t work in all cases or in all areas, and for one reason or another it doesn’t work for some people, even if they’ve followed all the steps for enabling wifi calling.

看起來作者遇到的問題是 latency 過高以及頻寬不穩定的問題:

Also, the protocol assumes terrestrial broadband with reasonable latency and bandwidth. At McMurdo, as of this writing, latency to terrestrial locations is in excess of 700 milliseconds. Usable bandwidth for any given end user can vary widely, down to a few dozen kilobits per second.

然後也很難 troubleshooting:

The protocol also doesn’t expose any useful diagnostic info to the end user in order to troubleshoot. You just have to cross your fingers that the magic “wifi calling” icon lights up.

接下來作者嘗試的是 Voice MFA,但不存在這樣的電話號碼可以轉接之類的:

Direct inward dialing to US Antarctic stations isn’t generally available, so you probably can’t configure your cell phone number to forward to a number you can directly answer on-station. (I’m aware of some exceptions to this.)

作者最後提了兩個方法,第一個是想辦法找一個銀行不會擋的虛擬號碼註冊,但這個方法基本上是個貓抓老鼠的遊戲。第二個是作者實做的方法,自己搞 relay,透過 IFTTT 或是其他類似的工具來轉:

轉出來像是這樣:

也許等基礎建設好一點之後,VoWiFi 應該就有機會通?

GitHub 將在 2023 年底強制所有使用者都啟用 2FA

GitHub 公佈了強制使用 2FA 的計畫:「Software security starts with the developer: Securing developer accounts with 2FA」。

文章副標題把該講的都講完了:

GitHub will require all users who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA) by the end of 2023.

自己開是一件事情,整個服務強制啟用是另外一個等級,還有一年多的時間...

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。