draft

SQLite 目前在規劃的 Strict Table，以及我從來不知道原來可以這樣惡搞...

在 Hacker News Daily 上看到「STRICT Tables」這篇，在講 SQLite 目前在規劃 strict table，對應的討論可以參考「Strict Tables – Column type constraints in SQLite - Draft (sqlite.org)」這邊。

我在 draft 文件開頭看到這個驚人的事實：轉型失敗的時候會直接寫進去，不是錯誤或是 0 或是 NULL 之類的值 XDDD

For example, if a table column has a type of "INTEGER", then SQLite tries to convert anything inserted into that column into an integer. So an attempt to insert the string '123' results in an integer 123 being inserted. But if the content cannot be losslessly converted into an integer, for example if the input is 'xyz', then the original string is inserted instead. See the Datatypes In SQLite document for additional information.

實際上測試建了一個表格測試：

SQLite version 3.31.1 2020-01-27 19:55:54
Enter ".help" for usage hints.
sqlite> CREATE TABLE a (id INTEGER PRIMARY KEY NOT NULL, col1 INTEGER);
sqlite> INSERT INTO a (id, col1) VALUES (1, 'a');
sqlite> SELECT * FROM a;
id          col1      
----------  ----------
1           a

我果然跟 SQLite 不熟...

OAuth 2.0 Device Authorization Grant

看到「OAuth 2.0 Device Authorization Grant」這個變成 PROPOSED STANDARD 了，看了一下歷史是 2015 年年底的時候被提出來的，記得在前公司的時候有用這個 (當時還是 draft) 做智慧型電視上的 OAuth 認證：

The OAuth 2.0 device authorization grant is designed for Internet-connected devices that either lack a browser to perform a user-agent-based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.

因為這些裝置的輸入設備受限，照原來 OAuth 2.0 的方式授權，使用者體驗不會太好 (可以想像用遙控器登入 Google 或是 Facebook 帳號？)，所以設計了替代的方案，讓使用者可以用手機授權 (比較常見的是透過 QR code)，然後電視機再去取得 access token。

Cloudflare 同時支援 TLS 1.2 與 TLS 1.3 的過程

Cloudflare 算是很早就參與 TLS 1.3 發展的廠商。在參與過程中他們希望讓支援 TLS 1.3 draft 的瀏覽器可以開始使用 TLS 1.3 draft，但又不希望因為 draft 頻繁修改而導致本來的使用者受到影響，所以就找了方法讓兩者並存：「Know your SCM_RIGHTS」。

這個方法就是 SCM_RIGHTS，可以讓另外一個 process 存取自己的 file description。

You can use UNIX-domain sockets to pass file descriptors between applications, and like everything else in UNIX connections are files.

所以他們的作法就是先讀取 TLS 裡 Client Hello 的資料，如果裡面有看到想要使用 TLS 1.3 的訊息，就透過前面提到的 SCM_RIGHTS 丟進 Golang 寫的程式跑：

We let OpenSSL read the “Client Hello” message from an established TCP connection. If the “Client Hello” indicated TLS version 1.3, we would use SCM_RIGHTS to send it to the Go process. The Go process would in turn try to parse the rest of the “Client Hello”, if it were successful it would proceed with TLS 1.3 connection, and upon failure it would give the file descriptor back to OpenSSL, to handle regularly.

這樣本來的 stack 就只要修改一小段程式碼，將當時還很頻繁修改的 TLS 1.3 draft 丟到另外一個 process 跑，就比較不用擔心本來的 stack 會有狀況了。

保護 TLS 的 Hostname

看到「Encrypted Server Name Indication for TLS 1.3」這個，由 Fastly、Cloudflare、Apple 的人聯手推出的 draft，想要保護 TLS 連線一開始明文傳輸的 hostname 部分。看起來是透過 DNS 發佈 public key，然後使用者用這把 public key 保護 hostname 的部分...

而 DNS 的部分可以透過 DNS over TLS 或是 DNS over HTTPS 來保護，這樣讓 ISP 沒有任何資訊可以看到 hostname，把暴露的資訊再降低...

來繼續關注這個技術...

NIST 新的密碼規範

由 NIST 所提出來的規範 (Special Publication 800-63-3: Digital Authentication Guidelines)，雖然還在 Draft 階段，但可以看出目前密碼規範的趨勢跟以前的不同：「NIST’s new password rules – what you need to know」。

整份規範可以在 GitHub 上讀到，不過 markdown 好像沒處理好，直接在 GitHub 上看到的有點亂，不過還算看得懂就是了...

在 NIST 網站上有 html 版本「Digital Authentication Guideline: Public Preview」可以讀，應該會好一些。

整份 guideline 很長，密碼的部份主要是在「DRAFT NIST Special Publication 800-63B Digital Authentication Guideline」這份裡面關於「Memorized Secrets」的部份。

先講對一般業者最不能理解的事情：

有「安全問題」反而會讓系統安全變弱。
要求使用者有大小寫、特殊符號這種讓使用者更難記密碼的限制，反而會讓使用者選出更差的密碼。讓使用者自由選擇密碼，同時用黑名單機制把常見的密碼擋下來會是比較好的選擇。
定期換密碼反而會讓使用者選擇更差的密碼 (因為要花力氣記，所以會選擇簡單的密碼)，不如讓使用者選一個強一點的密碼一直用。同時要合理設計限制登入錯誤的機制。
絕對不可以存明碼。

下面開始 copy & paste 然後給簡單的註釋...

首先是對最低長度的定義，至少要八碼。而對最大長度的限制是「至少你要讓使用者可以輸入 64 碼」：

Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHALL permit user-chosen memorized secrets to be at least 64 characters in length.

密碼不應該限制特殊字元，只要可以印出來的 ASCII 與空白都應該被允許，而 Unicode 也應該要被允許：

All printing ASCII [RFC 20] characters as well as the space character SHALL be acceptable in memorized secrets; Unicode [ISO/ISC 10646:2014] characters SHOULD be accepted as well.

空白可以被濾掉來判斷，但其他的字元都應該被當作強密碼的一部分來判斷：

Verifiers MAY remove space characters prior to verification; all other characters SHALL be considered significant.

要注意的是，為了強度，每一個 Unicode 應該只算一個有效字元：

For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character.

當密碼是隨機被系統設定時，可以是六個字元的強隨機數字：

Memorized secrets that are randomly chosen by the CSP (e.g., at enrollment) or by the verifier (e.g., when a user requests a new PIN) SHALL be at least 6 characters in length and SHALL be generated using an approved random number generator.

另外很重要的是，不應該有提示存取的功能，也就是「安全問題」不安全，所以要被禁止：

Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant. Verifiers also SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets.

然後針對已知的弱密碼 (像是字典單字，以及之前被洩漏出來的密碼) 都應該擋下來：

When processing requests to establish and change memorized secrets, verifiers SHOULD compare the prospective secrets against a dictionary of known commonly-used and/or compromised values. This list SHOULD include passwords from previous breach corpuses, as well as dictionary words and specific words (such as the name of the service itself) that users are likely to choose. If the chosen secret is found in the dictionary, the subscriber SHOULD be required to choose a different value. The subscriber SHOULD be advised that they need to select a different secret because their previous choice was commonly used.

另外不應該要求使用者要特殊字元或是大小寫這種限制，而且也不應該要求使用者定期換密碼 (除非確認被破了)：

Verifiers SHOULD NOT impose other composition rules (mixtures of different character types, for example) on memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) unless there is evidence of compromise of the authenticator or a subscriber requests a change.

另外禁止用明碼存密碼，必須用 PBKDF2 這類可以防禦快速離線計算的演算法：

Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Secrets SHALL be hashed with a salt value using an approved hash function such as PBKDF2 as described in [SP800-132]. The salt value SHALL be a 32 bit (or longer) random value generated by an approved random number generator and is stored along with the hash result. At least 10,000 iterations of the hash function SHOULD be performed. A keyed hash function (e.g., HMAC), with the key stored separately from the hashed authenticators (e.g., in a hardware security module) SHOULD be used to further resist dictionary attacks against the stored hashed authenticators.

HTTPS 因為安全性而不能使用 Referrer 的問題

在 Nuzzel 上看到老文章在討論 HTTPS 環境下因為安全性考量，而不能帶出 Referrer 的問題：「Where did all the HTTP referrers go?」。

原文中「Fixing Referrers in HTTPS: The Meta Referrer」這邊就有提到 HTML5 meta referrer，也就是 W3C 的「Referrer Policy」，問題是到現在還是 Draft 啊...

也因為過了三年，其實 draft 裡面多了不少參數可以用：

~~never~~ 或 no-referrer 表示不傳。
origin 表示只傳 protocol + host 的部份，後面 path 的部份不要傳。
~~default~~ 或 no-referrer-when-downgrade 表示當 downgrade 時 (HTTP request 的部份) 不要傳。
origin-when-cross-origin 表示當跨站時用 origin 的邏輯，但本站還是用完整的路徑。
~~always~~ 或是 unsafe-url 則是永遠都傳。

其中刪節號表示 W3C 不建議再使用，應該用後者比較新的。

不過因為在 Can I use 上面可以看到 Microsoft Edge 只支援舊的關鍵字 (也就是刪節號的那些)，所以還是可以考慮先用舊的關鍵字，讓 Microsoft Edge 也可以被保護到：「Referrer Policy」。

英國法院認為 GCHQ 偷黑別人機器是合法的

出自「Tribunal rules computer hacking by GCHQ is not illegal」這篇報導。在 Edward Snowden 爆料美國與英國政府都在幹黑的後，Privacy International 就提出訴訟控告 GCHQ，但前幾天法院認定這樣是合法的：

Campaigners Privacy International have lost a legal challenge claiming the spying post's hacking operations are too intrusive and break European law.

The case was launched after revelations by US whistleblower Edward Snowden about the extent of US and UK spying.

接下來的戰場會變成在 Investigatory Powers Bill 上面？還是會繼續有上訴？

.onion 的域名保護

.onion 被用在 Tor 的 hidden service，而現在從不同的面向要保護這個 root domain 不被註冊，在 IETF 的 blog 上看到「.onion」這篇文章就是其中一個方向。

這邊的計畫是把 .onion 域名當作像是 .local、.localhost、.example 這樣的特殊域名保護 (參考 RFC 6761「Special-Use Domain Names」) 而提了一個新的 RFC (目前是 draft)：「The .onion Special-Use Domain Name」。

如果通過的話，就有一個標準可以遵循，不然現在對 .onion 一直都是 De-facto standard...

Firefox 也要支援 Public Key Pinning Extension for HTTP

在「Mozilla to Support Key Pinning in Firefox 32」看到的新聞，目前的標準還是 draft：「Public Key Pinning Extension for HTTP」。

被簡稱 PKP 與 HPKP：(一般比較常用前者)

We call this "public key pinning" (PKP); in particular, this document describes HTTP-based public key pinning (HPKP).

可以看到 Google Chrome 程式碼裡面是怎麼使用 PKP 技術預載的：「/trunk/src/net/http/transport_security_state_static.json」。

目前 Google Chrome 使用的方式是限制 Google 的網域只能由某些特定的 CA 才能簽，這樣可以降低其他 CA 簽出高經濟價值的 SSL certificate 的效益。

在 Mozilla 的 wiki 上面可以看到對應的條目：「SecurityEngineering/Public Key Pinning」，目前 Firefox 的版本是 31，也就是從下一個版本就支援了。

第一波的 32 版會支援 Mozilla 自己的某些站台，以及一些 Twitter 的網域。

第二波的 33 版會把 Twitter 的部份擴充到 *.twitter.com，另外還會支援 Google 所擁有的網域。

第三波的 34 版會支援 Firefox account (*.accounts.firefox.com)、Tor 以及 Dropbox。

維基百科測試「草稿」功能...

維基百科正在測試「草稿」功能：「New draft feature provides a gentler start for Wikipedia articles」。

在「Why we need drafts on Wikipedia」有提到，在比較小的維基百科社群裡，偏向讓使用者編輯完成後，盡快發表出來讓大家修改。但比較大的維基百科社群因為有要求比較高的質量，有可能在發表出來的幾分鐘內就被掛上模板要求改善。維基百科分析英語、西班牙語、法語、俄羅斯語四個維基百科的資料，發現新使用者建立的條目有 80% 最後會被刪除 (Research:Wikipedia article creation)，而這對新血來說並不是友善的象徵...

來看看這個功能對於維基百科有多少幫助？