超過三億筆的密碼 (Hash 過的)

Troy Hunt 放出三億筆 SHA1 hash 過的密碼讓大家研究:「Introducing 306 Million Freely Downloadable Pwned Passwords」。

他引用了 NIST 新的草案中對密碼的建議,阻擋已知外洩的密碼:

檔案可以在「I been pwned? Pwned Passwords」這邊下載。

BoringSSL 的 FIPS 140-2 驗證

看到由 Google 主導的 BoringSSL 有計劃將其中一塊申請 FIPS 140-2 的驗證計畫 (BoringCrypto 的部份):「FIPS 140-2」。

其中 FIPS 140-2 最有名的後門應該是 Dual_EC_DRBG (定義於 NIST SP 800-90A,被 FIPS 140-2 引用),所以特地講清楚他們選擇哪個演算法:

FIPS 140-2 requires that one of its PRNGs be used (which they call DRBGs). In BoringCrypto, we use CTR-DRBG with AES-256 exclusively and RAND_bytes (the primary interface for the rest of the system to get random data) takes its output from there.

而且還花了不少篇幅解釋 PRNG 的細節。

NIST 開始徵求 Post-Quantum Cryptography 演算法

現有常見的幾個加密基礎在量子電腦上都有相當快速的解 (像是整數質因數分解、離散對數),只是現在建不出對應夠大台的量子電腦... 但畢竟只是時間的問題了,所以 NIST 照著慣例對外尋求能夠抵抗量子電腦的演算法:「NIST Asks Public to Help Future-Proof Electronic Information」、「Announcing Request for Nominations for Public-Key Post-Quantum Cryptographic Algorithms」。

類似於 Google 先前在 Google Chrome 上實做的 CECPQ1,對 key exchange 的部份加上保護 (Google Chrome 引入 CECPQ1,開始測試 Post-Quantum Cryptography),這次 NIST 是針對 public key crytpsystem 的部份而發的...

投稿時間在 2017 的十一月底,大約一年後就可以看到有哪些演算法要參加競賽了... 不過因為 NSA 的惡名,不知道會不會有其他單位在同個時段啟動類似的活動...

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.

OpenSSL 的 ECDH 中,224 bits 速度比 160/192 bits 快的原因

openssl speed ecdh 的時候發現很特別的現象:

Doing 160 bit  ecdh's for 10s: 40865 160-bit ECDH ops in 9.99s
Doing 192 bit  ecdh's for 10s: 34169 192-bit ECDH ops in 9.99s
Doing 224 bit  ecdh's for 10s: 60980 224-bit ECDH ops in 9.99s
Doing 256 bit  ecdh's for 10s: 34298 256-bit ECDH ops in 10.00s
Doing 384 bit  ecdh's for 10s: 9602 384-bit ECDH ops in 10.00s
Doing 521 bit  ecdh's for 10s: 9127 521-bit ECDH ops in 9.99s

原因是 Google 這篇論文的貢獻:「Fast Elliptic Curve Cryptography in OpenSSL」,開頭就提到:

We present a 64-bit optimized implementation of the NIST and SECG-standardized elliptic curve P-224.

而實際成果:

full TLS handshakes using a 1024-bit RSA certificate and ephemeral Elliptic Curve Diffie-Hellman key exchange over P-224 now run at twice the speed of standard OpenSSL, while atomic elliptic curve operations are up to 4 times faster.

OpenSSLCHANGES 也可以看到對應的修改,不只是 NIST-P224 有被改善,其他的 NIST-P256 與 NIST-P521 也都有被改善:

Add optional 64-bit optimized implementations of elliptic curves NIST-P224, NIST-P256, NIST-P521, with constant-time single point multiplication on typical inputs.

頗特別的...

因為 NIST 而換掉 AES?

Slashdot 上看到有人因為最近 NIST 被抖出來的事蹟 (SHA-3 的問題),而決定換掉 AES:「Silent Circle Moving Away From NIST Cipher Suites After NSA Revelations」。原報導在「Non-NIST Cipher Suite」。

換掉 AES 不確定這是不是好主意...

Rijndael 從 1998 年公開後,2001 年被選為 AES,之後被廣泛應用在所有資安協定上,也因為被廣泛應用,全世界打了這十多年下來,都還是屬於可用的狀態。換成其他 cipher 會比較安全嗎?

AWS 的 CloudHSM...

AWS 推出 CloudHSM 服務:「AWS CloudHSM - Secure Key Storage and Cryptographic Operations」。

不便宜,看起來是為了需要 NIST FIPS 140-2 需求而設的吧?跑的是 Luna SA - Ethernet-Attached HSM,可以達到 Level 3 的安全性...

然後遇到安全性時的老問題,要怎麼 audit:


感覺上是個口水戰,來拉板凳... XD

NIST 公告選出 SHA-3 的演算法...

NIST 公告選出了 SHA-3 演算法:「NIST Selects Winner of Secure Hash Algorithm (SHA-3) Competition」。

演算法是 Keccak (唸作 catch-ack),這個演算法其中一個優勢是硬體速度:

Keccak has higher performance in hardware implementations than SHA-2 or any of the other finalists.

由於選上的演算法會是 royalty-free license,接下來應該會看到許多 spec 開始納入 SHA-3... (參考 Announcing Request for Candidate Algorithm Nominations for a New Cryptographic Hash Algorithm (SHA-3) Family 這份文件)

伺服器的 BIOS 保護機制

NIST (National Institute of Standards and Technology) 是美國的政府機關 (國家標準技術研究所),訂定了非常多的標準。像是 DES 的制定 (NIST 前身,NBS - National Bureau of Standards) 與 AES 的選拔都是 NIST 的成果。

Slashdot 上看到 NIST 對於伺服器 BIOS 的保護機制提出建議:「NIST Publishes Draft Guidelines For Server BIOS Protection」,NIST 原始公告則是在「Security First: New NIST Guidelines on Securing BIOS for Servers」。都有原始 PDF 連結可以直接點。

BIOS Protection Guidelines for Servers ToC

標題是「BIOS Protection Guidelines for Servers」,目前還是在 draft 階段,頁數也還不太多...