HashiCorp 的 Vault 也有 fork 了:OpenBao

當初 HashiCorp 宣布改 license (可以參考之前寫的「HashiCorp 將放棄 Open Source License,改採用 BSL 1.1」),用的最多的 Terraform 就馬上有人 fork 出來:「OpenTF 宣佈從 Terraform 最後一個 Open Source 版本 fork 出來」、「OpenTF (Terraform 的 fork) 改名為 OpenTofu」。

Vault 也受到影響,當時花了一些時間找看看有沒有人 fork,沒找到後就改用 etcd (然後搭配 etcd-adminer 以及 oauth2-proxyGoogle Workspace 的 SSO),後來就沒有追這個問題了...

剛剛才看到 fork 的消息出來了:「OpenBao – FOSS Fork of HashiCorp Vault (github.com/openbao)」,專案在「OpenBao」這邊,要注意目前只有 development branch 有東西,main branch 目前是空的,而且 Hacker News 上討論也有提到現在還在 early stage,很多東西都還在整理。


GitHub 的 API Token 換格式

GitHub 前幾天宣佈更換 API token 的格式:「Authentication token format updates are generally available」,在今年三月初的時候有先公告要換:「Authentication token format updates」。

另外昨天也解釋了換成這樣的優點:「Behind GitHub’s new authentication token formats」。

首先是 token 的字元集合變大了:

The character set changed from [a-f0-9] to [A-Za-z0-9_]

另外是增加了 prefix 直接指出是什麼種類的 token:

The format now includes a prefix for each token type:

  • ghp_ for Personal Access Tokens
  • gho_ for OAuth Access tokens
  • ghu_ for GitHub App user-to-server tokens
  • ghs_ for GitHub App server-to-server tokens
  • ghr_ for GitHub App refresh tokens

另外官方目前先不會改變 token 長度 (透過字元變多增加 entropy),但未來有打算要增加:

The length of our tokens is remaining the same for now. However, GitHub tokens will likely increase in length in future updates, so integrators should plan to support tokens up to 255 characters after June 1, 2021.

看起來當初當作 hex string 而轉成 binary 會有問題,不過就算這樣做應該也是轉的回來的。

回到好處的部份,這個作法跟 SlackStripe 類似,讓開發者或是管理者更容易辨識 token 的類型:

As we see across the industry from companies like Slack and Stripe, token prefixes are a clear way to make tokens identifiable. We are including specific 3 letter prefixes to represent each token, starting with a company signifier, gh, and the first letter of the token type.

另外這也讓 secret scanning 的準確度更高,本來是 40 bytes 的 hex string,有機會撞到程式碼內的 SHA-1 string:

Many of our old authentication token formats are hex-encoded 40 character strings that are indistinguishable from other encoded data like SHA hashes. These have several limitations, such as inefficient or even inaccurate detection of compromised tokens for our secret scanning feature.

另外官方也建議現有的 token 換成新的格式,這樣如果真的發生洩漏,可以透過 secret scanning 偵測並通知:

We strongly encourage you to reset any personal access tokens and OAuth tokens you have. These improvements help secret scanning detection and will help you mitigate any risk to compromised tokens.

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 可以提供稽核記錄,把幾個比較明顯的問題解了不少...

AWS 推出 AWS Secrets Manager

AWS 推出 AWS Secrets Manager,你可以把各種帳號密碼丟進去讓系統管理,另外內建 rotate 的功能,針對 AWS 支援的服務可以無縫更換密碼 (目前看起來是 RDS),或是透過 Lambda 換:「AWS Secrets Manager: Store, Distribute, and Rotate Credentials Securely」。

是個整合性的服務,之前就可以做 (用 Lambda 定時跑),現在則是包裝起來針對 AWS 自家的服務弄的更簡單。

Cloudflare 推出在 HTTPS 下的壓縮機制

在 TLS (HTTPS) 環境下基本上都不能開壓縮,主要是為了避免 secret token 會因為 dictionary 的可預測性而被取出,像是 CRIMEBREACHTIMEHEIST (沒完結過...),而因為全面關閉壓縮,對於效能的影響很大。

Cloudflare 就試著去找方法,是否可以維持壓縮,但又不會洩漏 secret token 的方式,於是就有了這篇:「A Solution to Compression Oracles on the Web」。

重點在於 Our Solution 這段的開頭:

We decided to use selective compression, compressing only non-secret parts of a page, in order to stop the extraction of secret information from a page.

透過 regex 判斷那些東西屬於 secret token,然後對這些資料例外處理不要壓縮,而其他的部份就可以維持壓縮。這樣傳輸量仍然可以大幅下降,但不透漏 secret token。然後因為這個想法其實很特別,沒有被實證過,所以成立了 Challenge Site 讓大家打:

We have set up the challenge website compression.website with protection, and a clone of the site compression.website/unsafe without it. The page is a simple form with a per-client CSRF designed to emulate common CSRF protection. Using the example attack presented with the library we have shown that we are able to extract the CSRF from the size of request responses in the unprotected variant but we have not been able to extract it on the protected site. We welcome attempts to extract the CSRF without access to the unencrypted response.

這個方向如果可行的話,應該會有人發展一些標準讓 compression algorithm 不用猜哪些是 secret token,這樣一來就更能確保因為漏判而造成的 leaking...

AWS 推出 AWS Secret Region

AWS 推出給情報單位用的 AWS Secret Region:「Announcing the New AWS Secret Region」。

AWS GovCloud (US) 類似的架構,這個雲的範圍再小一些,給情報單位以及有對應授權的單位用的:

The AWS Secret Region is readily available to the U.S. Intelligence Community (IC) through the IC’s Commercial Cloud Services (C2S) contract with AWS.

The AWS Secret Region also will be available to non-IC U.S. Government customers with appropriate Secret-level network access and their own contract vehicles for use of the AWS Secret Region.


這下知道為什麼美國政府要直接禁用 Kaspersky 了:「Russian Hackers Stole NSA Data on U.S. Cyber Defense」。如果看不到 WSJ 的文章,可以看「Russia reportedly stole NSA secrets with help of Kaspersky—what we know now」這邊。

最近的事件被發現與 Kaspersky 的漏洞有關:

The hackers appear to have targeted the contractor after identifying the files through the contractor’s use of a popular antivirus software made by Russia-based Kaspersky Lab, these people said.

加上 Kaspersky 有濃厚的俄羅斯官方色彩 (關係良好),以及法令上與技術上都有可能性要求 Kaspersky 協助。雖然這次事件是合約工家裡電腦用 Kaspersky 造成的,但已經有足夠的風險讓美國政府決定開鍘下令完全禁用了:

For years, U.S. national security officials have suspected that Kaspersky Lab, founded by a computer scientist who was trained at a KGB-sponsored technical school, is a proxy of the Russian government, which under Russian law can compel the company’s assistance in intercepting communications as they move through Russian computer networks.

AWS CodeBuild 可以管 Secret 了...

AWS CodeBuild 可以管理 secret 了:「AWS CodeBuild Now Provides Ability To Manage Secrets」。

AWS CodeBuild now further enhances securing your build environment. CodeBuild can now store sensitive information as secrets, which can now get directly passed to your build jobs. This can be achieved by modifying the parameter store directly in your buildspec.yml, or via the CodeBuild console.


We strongly discourage using environment variables to store sensitive values, especially AWS access key IDs and secret access keys. Environment variables can be displayed in plain text using tools such as the AWS CodeBuild console and the AWS CLI. For sensitive values, we recommend you use the parameter-store mapping instead, as described later in this section.


不過在找資料的時候,發現 AWS CodeBuild 提供了每個月一百分鐘的 free quota,不論是新帳號還是現有帳號都一直有?(這點是之前沒注意到的...)

The AWS CodeBuild free tier includes 100 build minutes of build.general1.small per month. The CodeBuild free tier does not expire automatically at the end of your 12-month AWS Free Tier term. It is available to new and existing AWS customers.

2015 年的 Turing Award 由 Whitfield Diffie 與 Martin E. Hellman 獲得

紐約時報看到今年的 Turing AwardWhitfield DiffieMartin E. Hellman 獲得:「Cryptography Pioneers Win Turing Award」。在 Turing Award 官網上也可以看到對應的說明。

Diffie–Hellman key exchange 是全世界第一個 (1976 年) 在公開頻道上建立 shared secret 的演算法,直到現在都還廣泛的被使用,可以防禦被動式的監聽攻擊:

The Diffie–Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure channel.

現在這個演算法用在 PFS (Perfect forward secrecy),或稱為 FS (Forward secrecy),確保 public key 被破解前的連線記錄不會輕易被破解,於是更確保了資料的安全性:

a secure communication protocol is said to have forward secrecy if compromise of long-term keys does not compromise past session keys.

後來這個演算法也被延用到 Elliptic curve 上,也就是 ECDH,因為不使用 Z_{2^p}Z_p (field) 而是使用 Elliptic curve (group),而大幅降低了可被拿來攻擊的特性,而使得 key 的長度可以比 RSA 小很多。

上一個因密碼學拿到 Turing Award 的是 2012 年得獎的 Silvio MicaliShafi Goldwasser,他們所音發展出來的用以對密碼系統驗證的數學方法而得獎。

而更有名的應該是 2002 年 Ronald L. RivestAdi ShamirLeonard M. Adleman 因為 RSA 演算法而得獎的事情。

在愈來愈多新聞揭露安全與隱私問題後 (尤其是政府對人民的監控),密碼學愈來愈被重視。之前在密碼學領域做出重大貢獻的人也陸陸續續得獎...

AWS 推出 Git Hook,阻擋 AWS 的 Key 被傳到 Git 上...

AWS 推出的工具,可以阻擋 AWS 的 Key 被傳到 Git 上:「awslabs/git-secrets」。可以看到說明:

git-secrets scans commits, commit messages, and --no-ff merges to prevent adding secrets into your git repositories. If a commit, commit message, or any commit in a --no-ff merge history matches one of your configured prohibited regular expression patterns, then the commit is rejected.