2019-M03 關於 Idempotent 兩三事 - 資安

2019-M03 關於 Idempotent 兩三事

早上朋友丟了問我關於解決 idempotent 的問題 原因在於他那邊最近常常發現

存錢的 POST API 在 Server 端常常收到兩次的 Bug

這類型的問題常常發生在 Mobile + API 自動 retry

因為 Mobile 的特性 : 使用 WiFi 會因為移動導致斷線、自動重新連線

導致第一個 POST API 沒有收到正常的回傳值 而自動 retry

因此在很多 POST 等相關 API 都會加上 IDEMPOTENT 參數來避免重送攻擊



概念上很簡單：在 POST 的時候 Client 會帶上一個 IDEMPOTENT

如果 Server 端收到來自同一個 IDENPOTENT 的請求 第二次之後的操作視為 NOP

如果來自不同使用者 但 IDENPOTENT 相同的情況 則回傳 collision 錯誤

因此找到一個不會碰撞的 IDENPOTENT 的產生方式就極為重要



---- 以下是本文重點 ----
強者我朋友提出了 UUID[0] 的方式 也就是隨機產生一組 128bit 的隨機字串

但是他的長官認為 是否會有 collision 的狀況 ...

因此廢物我提出了一個 ULID[1] 解決方案用來解釋他很難發生 collision



在 ULID 的 SPEC 下定義使用 128bit 長度：前面 48bit 用來表示時間、後面 80bit 則為隨機

時間戳記本身為 ms 等級計算 因次發生 collision 的前提之一就是要在同一毫秒

而後者 80bit 的隨機數字則假設遭遇到生日攻擊法[2]

使用速算法來計算 collision 發生機率為百萬分之一 (~ 2^-20)

約需要 2^30。大概是 1ms 需要有一億次請求


#謹獻給強者我朋友的長官#


[0]: https://tools.ietf.org/html/rfc4122.html
[1]: https://github.com/ulid/spec
[2]: https://en.wikipedia.org/wiki/Birthday_attack

--