Facebook 員工爆料內部密碼存了明碼

Krebs on Security 這邊看到的:「Facebook Stored Hundreds of Millions of User Passwords in Plain Text for Years」,Facebook 官方的回應在「Keeping Passwords Secure」這邊。

幾個重點,第一個是範圍,目前已經有看到 2012 的資料都有在內:

The Facebook source said the investigation so far indicates between 200 million and 600 million Facebook users may have had their account passwords stored in plain text and searchable by more than 20,000 Facebook employees. The source said Facebook is still trying to determine how many passwords were exposed and for how long, but so far the inquiry has uncovered archives with plain text user passwords dating back to 2012.

另外的重點是這些資料已經被內部拿來大量搜尋 (喔喔):

My Facebook insider said access logs showed some 2,000 engineers or developers made approximately nine million internal queries for data elements that contained plain text user passwords.

另外是 Legal 與 PR 都已經啟動處理了,對外新聞稿會美化數字,降低傷害:

“The longer we go into this analysis the more comfortable the legal people [at Facebook] are going with the lower bounds” of affected users, the source said. “Right now they’re working on an effort to reduce that number even more by only counting things we have currently in our data warehouse.”

另外也會淡化後續的程序:

Renfro said the company planned to alert affected Facebook users, but that no password resets would be required.

去年的另外一則新聞可以交叉看:「Facebook’s security chief is leaving, and no one’s going to replace him」:

Instead of building out a dedicated security team, Facebook has dissolved it and is instead embedding security engineers within its other divisions. “We are not naming a new CSO, since earlier this year we embedded our security engineers, analysts, investigators, and other specialists in our product and engineering teams to better address the emerging security threats we face,” a Facebook spokesman said in an email. Facebook will “continue to evaluate what kind of structure works best” to protect users’ security, he said.

看起來又要再換一次密碼了... (還好已經習慣用 Password Manager,所以每個站都有不同密碼?)

喔對,另外補充一個概念,當他們說「我們沒有證據有人存取了...」的時候,比較正確的表達應該是「我們沒有稽核這塊... 所以沒有證據」。

Tails 3.13 把注音輸入法的 bugfix 放進去了

在「Tails 裡的注音輸入法終於修好了...」這邊有提到 Tails 的注音輸入法爛掉很久的問題,以及對應的 bugfix 測的差不多了,不過當時一直還沒確定會不會在這個版本修正。

剛剛在「Tails 3.13 is out」這邊的公告裡看到把這個 bugfix 納入 Tails 3.13 了:

Add support for the Bopomofo input method for Chinese using the Chewing library and improve support for the Pinyin input method. (#11292)

後續要再來測操作順暢性的問題了...

Cloudflare 試著分析哪些 HTTPS 連線被攔胡過濾

這邊講的應該是在 client 端裝了 root certificate 後,網路上的 middle box 就有能力解開 HTTPS 連線看內容,再 proxy 連出去的方式:「Monsters in the Middleboxes: Introducing Two New Tools for Detecting HTTPS Interception」,對於有設定 Pinning 的 HTTPS 應該會因為偵測到 certificate 被換掉而不會被監聽,但大多數的應用程式應該沒做這個保護。

對應的公開網站是 MALCOLM,為「Measuring Active Listeners, Connection Observers, and Legitimate Monitors」的縮寫。

Cloudflare 用了幾個方法去分析,像是 User-agent 與 OS 跟支援的 cipher 對不起來的情況就可以猜測是 middle box 的監聽。另外也可以看到 Cloudflare 分析了 middle box 的廠牌,可以看到 Blue Coat 應該是目前的大品牌 (但這邊有統計偏差,限制在可以被偵測出來的品牌)。

其實整體看起來不算低耶... 光是可以確認的部分,整個 Cloudflare 網路上有 10%~20% 的流量其實是有被過濾的?

Tails 裡的注音輸入法終於修好了...

Tails 是一個獨立的 Debian 作業系統,強調匿名性,裡面有很多環境的預設值是為了避免 IP 位置以及其他資訊洩漏而設計。另外因為是獨立完整的作業系統,可以找台電腦用 USB 開機直接跑起來,避免 OS 被埋木馬的問題 (當然如果硬體有問題的話還是沒辦法)。

大多數人用 Tails 的人應該還是拿來跑 Tor Browser,不過我在用的時候發現注音輸入法有問題 (大約三年前?),就跑去開了一張 bug ticket 回報:「Bopomofo input for Chinese is not working」,從裡面的討論可以看到中間有 ping 我,但是我忘記回應了... 直到最近動了起來剛好有看到,就抓了 snapshot ISO 幫忙測了一下,畢竟沒幾個用注音的人在上面可以確認 :o

目前看起來輸入法本身的問題修差不多了,而且有機會在下個版本看到 (或是下下個版本,要看會不會進這次的 merge window)。

想要測試的人,除了要抓這個版本的 snapshot ISO 外 (在 bug ticket 裡有連結),在 Tails 開機時,要記得要在 Language 的地方選擇台灣:

開進去後就可以看到注音輸入法了,用 Super + Space 可以切換輸入法:(Super 通常指的是微軟鍵,或是 Mac 右邊的 Command 鍵,因為左邊的 Command 可能被當 Host key 了)

還有一些小 bug 要另外再處理 (像是切換輸入法的 input focus 會跑掉),不過比以前完全不能用好多了...

荷蘭認為 Cookie Wall 不符合對 GDPR 的規範

Update:弄錯國家了,是荷蘭...

Cookie Wall 指的是不同意接受 cookie policy 就無法使用網站的限制,像是這樣的東西:

在「Cookie walls don’t comply with GDPR, says Dutch DPA」這邊看到荷蘭認為 Cookie Wall 不符合 GDPR 的規範:

Cookie walls that demand a website visitor agrees to their internet browsing being tracked for ad-targeting as the “price” of entry to the site are not compliant with European data protection law, the Dutch data protection agency clarified yesterday.

後面應該會有訴訟,重點會在這...

ACME,RFC 8555

這邊講的是因為 Let's Encrypt 所發明的 ACME 協定,可以協助自動化發憑證的協定。

剛剛看到「Automatic Certificate Management Environment (ACME)」這個頁面,上面標 PROPOSED STANDARD,但點進去的 txt 檔開頭則是 Standards Track 了:

Internet Engineering Task Force (IETF)                         R. Barnes
Request for Comments: 8555                                         Cisco
Category: Standards Track                             J. Hoffman-Andrews
ISSN: 2070-1721                                                      EFF
                                                             D. McCarney
                                                           Let's Encrypt
                                                               J. Kasten
                                                  University of Michigan
                                                              March 2019

不知道是不是兩邊不同步 (或是我對流程有誤會?),但這有一個標準文件可以參考了...

從 StartPage 換回 DuckDuckGo...

把過程記錄下來而已...

前陣子在測試 StartPage (一個後端還是 Google 的搜尋引擎),想看看在沒有個人資訊的前提下是不是能提供夠好的搜尋品質。為了方便切換確認,還寫了 startpage-shortcuts 這個套件,讓我能用快速鍵將同樣的關鍵字傳進 Google。

用了幾個禮拜下來,發現搜尋品質其實很差,有時候甚至跳不出搜尋結果來?(可能是被 Google 擋下?) 先換回 DuckDuckGo 好了...

在 Mac 上跑 DNS-over-TLS

主要是參考「Configuring DNS-over-TLS on macOS」這篇的方法做的:

brew install knot-resolver
echo "policy.add(policy.all(policy.TLS_FORWARD({{'1.1.1.1', hostname='1.1.1.1'}})))" | tee -a /usr/local/etc/kresd/config
sudo brew services restart knot-resolver

然後 127.0.0.1 就有 DNS resolver 可以用了,接下來就是把系統的 DNS 改過去...

移除 Facebook 上的行動電話

Facebook 上的行動電話號碼除了被拿來當作 2FA 的備案外,也被強制分享。更糟的是還被拿來當作廣告的條件:

目前同時有 TOTP (Facebook 的 app 提供的) 與 U2F,完全不會用到簡訊認證,就拔掉吧...