Tag: token

關於 LLM 的數字

Hacker News Daily 上看到的文章，講 LLM 的各種數字 (大多都是費用)：「Numbers every LLM developer should know (github.com/ray-project)」，原文在「Numbers every LLM Developer should know」這邊。

其中第一條就蠻重要的，如果你是用 API 依照 token 收費的話，叫 API 長話短說會省不少錢 XD

40-90: Amount saved by appending “Be Concise” to your prompt

第二條是給個感覺，換算 word 與 token，不過這邊講的應該是英文的：

1.3:1 -- Average tokens per word

後面也有蠻多數字的，都是讓你有個感覺。都讀過後就可以把 cheatsheet 留下來：

測試 GitHub 與 AWS 可以多快偵測出外洩的 token

前幾天在 Hacker News 上看到「What happens when you leak AWS credentials and how AWS minimizes the damage (xebia.com)」這篇，原文連結在「What happens when you leak AWS credentials and how AWS minimizes the damage」這邊。原文跟 Hacker News 上的寫到東西都頗有趣的，可以分開來講。

先是原文的部份，他抓了一些時間軸：

12:33:12 – Pushed the credentials to GitHub
12:34:19 – The AWSCompromisedKeyQuarantineV2 policy is attached to the IAM user test-user by AWS
12:34:32 – Various List and Describe calls are made using the leaked credentials
12:35:08 – Received an email from AWS with the subject ‘ACTION REQUIRED: Your AWS Access Key is Exposed for AWS Account 12345678’

可以看到推上 GitHub 後，AWS 在一分七秒後就自動加上 AWSCompromisedKeyQuarantineV2 以減少災害擴大，然後再發信件通知。

這個功能可以參考 GitHub 的文件說明：「About secret scanning - GitHub Docs」。

另外在 Hacker News 上面看到有人直接把 secret scanning 當作 API 串來用 (噗)，把在 PyPI 上面掃到的 AWS secret 丟上 GitHub 觸發後續的機制：

I set up a project[1] to automatically leak AWS secrets published to the Python package index, which then triggers the secret scanning process and quarantines the keys[2]

1. https://github.com/pypi-data/pypi-aws-secrets

2. https://github.com/pypi-data/pypi-aws-secrets/blob/main/keys...

從 Mozilla 官網下載的 Firefox 帶有追蹤用的標籤

前天看到「Each Firefox download has a unique identifier」這篇報導，就順手貼到 Hacker News 上面了：「Each Firefox download has a unique identifier (ghacks.net)」。

簡單的說就是 Mozilla 在 Firefox 的 binary 裡面加上 download token，後續就可以追蹤使用者：「[meta] Support download token」。

依照報導所提到的，每次下載 binary 都會有不同的 token：

在「Attached file dltoken_data_review.md — Details」裡面有回答更多細節，像是跟 Google Analytics 綁定：

5) List all proposed measurements and indicate the category of data collection for each measurement, using the [Firefox data collection categories](https://wiki.mozilla.org/Firefox/Data_Collection) found on the Mozilla wiki.   

<table>
  <tr>
    <td>Measurement Description</td>
    <td>Data Collection Category</td>
    <td>Tracking Bug #</td>
  </tr>
  <tr>
    <td>A download token that uniquely corresponds to a Google Analytics ID</td>
    <td>Category 4 "Highly sensitive or clearly identifiable personal data"</td>
    <td>Bug 1677497</td>
  </tr>
</table>

我自己重製不出來 (都是被導去 CloudFront)，但留言區裡面的 Yuliya 透過 Tor 有重製出來：

I have tried some TOR exit nodes:

Name: Firefox Setup 98.0.1_germany.exe
Size: 55528896 bytes (52 MiB)
SHA256: 2d8164d547d8a0b02f2677c05e21a027dc625c0c1375fd34667b7d039746d400
SHA1: 71302acbee6895b84cf0dfae99050926f2db59ef

Name: Firefox Setup 98.0.1_austria.exe
Size: 55528896 bytes (52 MiB)
SHA256: a139a45dd5737ab981068ca2596b7fdfde15e5d4bc8541e0a2f07a65defd3e4e
SHA1: 28630a0aababa162ca9e7cbca51e50b76b9c3cff

I have labeled the file for the corresponding country of the exit node.

如果不願意換到 Chromium-based 的方案，目前在討論裡看到的替代方案是 LibreWolf，昨天裝起來後發現還行，應該也可以測試看看...

限制流量的方式 (rate limit)

在 Lobsters Daily 上看到這篇 2017 年的文章，Figma 的工程師講怎麼做 rate limit：「An alternative approach to rate limiting」，只要大一點的站台就會遇到 spammer 之類的攻擊，就會希望實做自動化的機制擋住 spammer。

文章裡面提到了三種方式，第一種 (類) 提到了經典的 Token bucket 與 Leaky bucket，這邊文章提供的演算法是讓每個使用者都會有一筆資料紀錄在 Redis 裡面 (這邊的用法可以抽換換成 Memcached)，裡面記錄了最後一次的 access time 以及還剩下多少 token 可以用，接下來就可以照時間計算 token 的補充與消耗：

但這個演算法的缺點是 race condition，需要另外設計一些機制確保操作的 atomic：

不過大多數的實做就算不管 atomic 也還行 OK，只是會比較不精確一點。

第二個方法他叫做 Fixed window counters，這個方法把時間切齊為單位 (像是 60 秒為一個 window)，所以可以把起點的時間也放到 key 裡面，然後 value 就是數量：

這個作法的好處就是簡單，而且 Redis 與 Memcached 都有提供 atomic 的 +1 操作。但缺點是可能會發生兩倍以上的 request，像是 5 reqs/min 的限制有可能會有連續的一分鐘內達到 10 reqs/min：

不過我覺得就 antispam 來說算是夠用了，當年 (大概是 2007 或是 2008 年？) 在 PIXNET 時用 C 寫 Apache module 就是把資料丟到 Memcached 裡面就是這樣實做的，然後每次學術網路的實驗室跑來掃站的就會自動被擋 XDDD

第三種方式他們稱作 Sliding window log，就是把每個 request 的 timestamp 都存起來，這個部份用 Redis 的資料結構會比用 Memcached 方便一些：

這個方式在控制上更精確，不過空間成本上就高很多... 這樣算是把常見的實做方式都提到了。

在 AWS Summit Taiwan 2021 上講的 HashiCorp Vault

今年的 AWS Summit Taiwan 2021 是線上的形式，早在前一個月前就先預錄好，但開始的時候就忘記要宣傳一下了... 結果是在找資料的時候發現其他人有提到：「AWS實作紀錄 #2：高可用性保管服務 (2021 AWS Summit Taiwan)」。

投影片與影片如果有興趣的人可以去 AWS 活動頁面上看，或者上面提到的那篇。

這次講的主題是想要在雲端上面搭建 Vault，但又不希望自己搞一堆 High Availability 的架構，最好是雲端服務本身就有提供... 而既然是在 AWS 的場子，主要都還是以 AWS 的服務來搭建。

在這次的設計裡，Vault 的資料是放在 DynamoDB 上，然後透過 KMS 管理加密用的，這兩個服務本身都有 High Availability，所以直接用就可以了。

接下來是跑 Vault 程式的部份，這部份得自己處理 High Availability 的架構，我是用兩台很小台的 EC2 instance (t4g.nano) 在跑，這邊也可以換成 ECS 或是 EKS 的 container。

接下來把這兩台 EC2 instance 掛起來的也都是 High Availability 服務：在 EC2 instance 前面用 ELB 擋住提供 HTTP API 服務，另外這邊即使是內部用，也可以上 HTTPS (透過 ACM 掛上 HTTPS 的憑證)。

在 ELB 上看到只有一台機器活著是正常的，因為兩台機器之間是 active-standby 架構，同時間只會有一台機器在運作，而 lock 的機制是 Vault 透過 DynamoDB 實做的，不需要另外處理。

其實裡面大多數的元件都可以抽換，像是 DynamoDB 也可以用其他的服務來當儲存層，馬上可以想到的是 RDS 的 MySQL 或是 PostgreSQL。

概念上不算困難，所以投影片上主要就是給設定檔，這樣方便大家抄，不用在自己摸指令摸半天...

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 會有問題，不過就算這樣做應該也是轉的回來的。

回到好處的部份，這個作法跟 Slack 與 Stripe 類似，讓開發者或是管理者更容易辨識 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.

Zoom 預設開啟密碼原因

最早的時候用 Zoom 只需要知道 meeting room 的編號就可以連進去，產生連結時也只需要提供號碼就能進去，後來 (不知道什麼時候開始的) 產生出來的連結會包括一組 token，而預設加入房間也需要密碼了。

現在知道原因了，因為被安全通報了：「Zoom Fixes Flaw Opening Meetings to Hackers」。

除了上面講到的問題以外，另外一個漏洞是本來的連結網頁就有資訊可以辨別是否為合法的 meeting room，可以讓攻擊者很快速的判斷哪些 meeting room 可以連進去。這次的修改變成不檢查，直接帶到 Zoom 的應用程式裡面，增加一些難度，但攻擊者還是可以透過 API 掃出來。

這主要是當初設計上的安全問題，當初沒有設計那麼長，應該就是考慮太長的號碼會讓使用者不太容易手動輸入...

在 AWS 強制使用 MFA 的情況下，透過 CLI 操作

AWS 可以設定 IAM 使用者強制使用 MFA (包括 API 的操作)，在這種情況下如果要使用 AWS Command Line Interface 就得透過 AWS STS (AWS Security Token Service) 產生另外一組 key + secret + session key，然後這組通行時間預設是 12 小時。

相關的文章可以參考「How do I use an MFA token to authenticate access to my AWS resources through the AWS CLI?」這篇，然後我就寫了一段 shell script 來做這件事情。

首先是在 ~/.aws/config 內放入 MFA 的 ARN，像是這樣：

[profile mycompany]
mfa = arn:aws:iam::012345678901:mfa/gslin
region = us-east-1

然後就可以用 aws.mfa mycompany 指令產生出一個會把 key + secret + session key 包進去的 shell：

function aws.mfa() {
    local MFA_ARN
    local MFA_TOKEN
    local PROFILE="$1"
    local STSDATA

    MFA_ARN="$(python3 -c "import configparser; import os; c=configparser.ConfigParser(); c.read('{}/.aws/config'.format(os.environ['HOME'])); print(c['profile ${PROFILE}']['mfa'])")
"
    echo "Reading ${PROFILE} and going for token ${MFA_ARN} ..."

    echo -n 'MFA Password: '
    read -r MFA_TOKEN

    STSDATA="$(aws --profile "${PROFILE}" sts get-session-token --serial-number "${MFA_ARN}" --token-code "${MFA_TOKEN}")"
    export AWS_ACCESS_KEY_ID="$(echo "${STSDATA}" | jq -r .Credentials.AccessKeyId)"
    export AWS_SECRET_ACCESS_KEY="$(echo "${STSDATA}" | jq -r .Credentials.SecretAccessKey)"
    export AWS_SESSION_TOKEN="$(echo "${STSDATA}" | jq -r .Credentials.SessionToken)"

    echo 'Running an independant shell...'
    ${SHELL}
}

很明顯的裡面用到了 Python 3 與 jq，這兩個應該都可以直接裝系統的版本就可以了。

後續的操作就跟原來的用法都一樣，像是 aws --region=us-east-1 s3 ls 這樣的指令。

Elasticsearch 的 CJK Bigram 設定

Elasticsearch 應該是目前大家搜尋引擎的首選了。而且預設的搜尋法不像以前的搜尋引擎，以前的搜尋引擎會把所有的中文字串當作一個 term，基本上是搜不到東西的。

不過偶而還是會出現一些問題，像是這樣：(這是在求職天眼通搜尋「訊力科技股份有限公司」的結果)

會發現出現了「104人力銀行_一零四資訊科技股份有限公司」，這是因為預設的搜尋演算法把中文字一個一個拆開，後面的「科技股份有限公司」八個字也都有出現，前面的「訊」與「力」也都有出現，於是就被拉出來了...

這種方式被歸類為 unigram 類的方式，像是「波音737 MAX」這一段就會被切成「波」、「音」、「737」與「MAX」。這個切法還算不錯，但有不少機會會遇到問題。

如果限制在 Elasticsearch 內建的功能，其實有更好的設定可以用，也就是對 CJK 文字改用 bigram 方式切：「CJK Bigram Token Filter」。

遇到英文數字還是照原來的切法，但遇到中文字 (更正確的說應該是 CJK) 會用 bigram 的方式切，像是搜尋詞「訊力科技股份有限公司」就會被切成「訊力」、「力科」、「科技」、「技股」、「股份」、「份有」、「有限」、「限公」與「公司」，而本來的「104人力銀行_一零四資訊科技股份有限公司」裡面就不會出現「訊力」、「力科」，於是就不會抓錯...

當然還是有更好的演算法，不過大多就需要另外安裝了，而 Elasticsearch 的升級又很容易跟這些另外裝的套件卡住，所以在考慮維護成本下，CJK Bigram Token Filter 應該是首選...