看到「imgproxy: Resize your images instantly and securely」這篇文章,介紹「DarthSim/imgproxy」這個專案,想起很久以前的同事在 PIXNET 弄的 * 系列服務...

imgproxy 可以 resizing,也可以 croping,然後也支援 signature token 機制,感覺是每個大一點的站台都會自己刻一次的服務 XD

整個專案以 Golang 為主,效能應該是不錯... 不過一般前面還是會放 cache 機制 (像是 CDN 之類的服務),而不會把 loading 直接打進來,避免同樣的圖片一直重複計算。

GitHub 推出軟體版的 U2F Authenticator (目前只有 macOS)

用軟體實做 U2F,目前是開發在 macOS 上:「Introducing Soft U2F, a software U2F authenticator for macOS」。

實在是不愛這種方式,由於是軟體式的,安全性低了不少... (機器被入侵後就都沒有防護了)

不過 U2F 是目前少數可以在 protocol 層抵抗 phishing 的方式,相較於一般 OTP 的方式還是得很注意網址,所以站在推廣的立場的確是希望能多一點人用...

GitHub 保護自家的 OAuth Access Token 不會進入 GitHub 上公開的 Repository

GitHub 的公告:「Keeping GitHub OAuth Tokens Safe」。

當你不小心把 GitHub 的 OAuth Access Token 推到 GitHub 的 public repository 時,站方會自動 revoke 掉:

Starting today you can commit more confidently, knowing that we will email you if you push one of your OAuth Access Tokens to any public repository with a git push command. As an extra bonus, we'll also revoke your token so it can't be used to perform any unauthorized actions on your behalf.

保護使用者在使用 GitHub 自家的產品。

AWS 推出信用卡式的 MFA

AWS 推出信用卡式的 MFA:「A Convenient New Hardware MFA Form Factor」。

一樣是跟 Gemalto 合作。相較於之前掛在鑰匙圈上變得更容易收納 (可以放到皮夾內):

實體的 OTP 還是比 app 形式的安全強度好,變成信用卡形式後應該再弄一片來玩玩...

Facebook 在對抗 BREACH Attack 的方法

在「Facebook Takes Tougher Stand Against BREACH Attack」這篇提到 Facebook 在 2012 年對抗 BREACH attack 的方法:

在文章最後面有提到當時一般建議的 migrate 方式 (關閉 TLS 的壓縮) 不適用於 Facebook:

Turning off compression is not an option for large dynamic sites such as Facebook because it would hinder performance dramatically.

而且就算關掉 TLS 的 compression,也還是有疑慮:

Even if TLS-level compression is disabled, it is very common to use gzip at the HTTP level. Furthermore, it is very common that secrets (such as CSRF tokens) and user input are included in the same HTTP response, and therefore (very likely) in the same compression context,

節錄幾段 migrate 的重點:

Facebook disclosed how it’s mitigating BREACH attacks by changing the frequency in which it rotates CSRF tokens from daily to each time a Facebook session is started.

本來 CSRF token 變更的頻率是好幾天一次,把頻率拉高...

After a new token is issued, the previous tokens still remain valid for a couple days, resulting in multiple tokens being permissible simultaneously.

然後舊的 token 還是會保持一段時間有效。

因為現實因素而沒辦法在 TLS 層關閉,後面在 application level 的 workaround 相當費功... (而且要多花不少資源?)

新的 HTTPS 攻擊:BREACH Compression Attack

也是一個禮拜前的消息,在 Slashdot 上看到對 HTTPS 的新攻擊,目前沒有好解法,NSA 應該開心到爆炸:「BREACH Compression Attack Steals SSL Secrets」。

說明可以參考「Vulnerability Note VU#987798 BREACH vulnerability in compressed HTTPS」這篇。

假設你的 ISP 想要抓出你的 Facebook (HTTPS) session id 或是 CSRF token (只要是有能力在中間攔截封包並修改資料的團體都可以,這邊以 ISP 為例),作法是針對 HTTP 頁面值入 script,讓你的瀏覽器對 發出大量 request,藉由觀察這些 HTTPS 的長度就有機會取得 session id (或 CSRF token)...

CERT 的 security advisory 上是寫:

With a token of length 32 and a character space of size 16 (e.g. hex), the attacker needs an average of approximately 1,000 request if no recovery mechanisms are needed. In practice, we have been able to recover CSRF tokens with fewer than 4,000 requests. A browser like Google Chrome or Internet Explorer is able to issue this number of requests in under 30 seconds, including callbacks to the attacker command & control center.

四千次就搞定了... 太!歡!樂!了!

為什麼有了 Google Authenticator 還要使用實體的 Two-Factor Token?

如標題的問題,因為 token 可以將 secret key 實體隔離開。

可以讀看看最近這篇報導:「Zitmo Trojan Variant Eurograbber Beats Two-Factor Authentication to Steal Millions」,其中這段:

To date, the researchers said, Eurograbber has infected more than 30,000 users and stolen an estimated 36 million Euros.


用簡訊也有類似的問題,實體的 OTP 算是目前最能抵抗這類攻擊的方式了...