Google Chrome 對只有 SHA-1 fingerprint 的淘汰過程

現在 Google Chrome 是 37 版,接下來的幾個版本會開始針對只有 SHA-1 fingerprint 的 SSL certificate 降低安全評價:「Gradually sunsetting SHA-1」。

這是 39 版預定的情況,會出現警告:

這是 40 版預定的情況,安全 icon 會消失:

而這是 41 版直接廢止的情況,當作不合法的 SSL certificate 處理:

另外,預先安裝的 root certificate 不受影響,因為並不是看 SHA-1 hash:

Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.

整個過程大約會在 2015Q1 告一個階段。

PHP 的 Memcached 的眉眉角角...

PHPMemcached 整理一下,未必適合其他人用。

設定上:

  • 平常應該要打開 libketama 相關設定,包含了 OPT_DISTRIBUTIONOPT_LIBKETAMA_COMPATIBLE
  • 多台 server 要注意使用 hostname 或是 IP address 連線 (尤其跨程式語言時),在 consistent hash 時會有差異。要避免因為 hostname 發生的問題,可以把這段設定放到 JSON 檔裡與其他程式語言共用。
  • 使用 SERIALIZER_JSON,一樣是為了與其他程式語言相容。

使用上:

  • add() 在 key 存在時會失敗,set() 則會覆蓋過去。
  • add()set() 裡的 expiration 參數是 UNIX timestamp,而非直覺的秒數...
  • get() 的 callback 不應該使用,因為無法設定 expire time。
  • memcached 的 manual 有寫預設值是使用冒號 (:) 當作 key 的分隔,這對於統計資料會有幫助。

先整理到這...

PHP 的 crc32、crc32b 以及 hash_file

PHP 上 CRC32 的資料時,查到讓人噴飯的 comment

For those who are wondering, there appears to be no fundamental difference between hash_file('md5')/hash_file('sha1') and md5_file()/sha1_file(). They produce identical output and have comparable performance.

There is, however, a difference between hash_file('crc32') and something silly like crc32(file_get_contents()).

crc32(file_get_contents())'s results are most similar to those of hash_file('crc32b'), just with the octets reversed:

<?php
$fname = "something.png";

$hash = hash_file( 'crc32', $fname );
echo "crc32  = $hash\n";

$hash = hash_file( 'crc32b', $fname );
echo "crc32b = $hash\n";

$hash = sprintf("%x",crc32(file_get_contents($fname)));
echo "manual = $hash\n";
?>

crc32  = f41d7f4e
crc32b = 7dafbba4
manual = a4bbaf7d

不只是 hash_file() 抓出來不一樣,連 algorithm 都來亂...

微軟將在 2016 年會拒絕 SHA-1 的 SSL 安全憑證...

微軟公告將在 2016 年拒絕只有 SHA-1 的 SSL Certificate:「Security Advisory 2880823: Recommendation to discontinue use of SHA-1」。微軟的力量主要是對 IE 瀏覽器的控制。

可以看到文章裡把 MD5 的歷史也拿出來比較,然後對照到 SHA-1,所以宣佈 2016 年後就不吃只有 SHA-1 的 SSL Certificate

比較新的簽章都包含了比較強的 cryptographic hash algorithm,像是 SHA-256 的:

現在差不多 2013 年年底,所以大約還有兩年的時間...

SHA-3 的歷史由來...

Bruce Schneier 的 blog 上看到 SHA-3 的由來:「SHA-3 Status」,而投影片在「Keccak and the SHA-3 Standardization」這裡,裡面有不少資料可以用...

像是 crypto hash function 速度的比較:

後半段看到蠻多有趣的東西,等有空回頭來看...

各種密碼破解速度...

oclHashcat-plus 提供了透過 GPU 破解的 benchmark 數據:

可以看到 PBKDF2、sha512crypt $6$ 以及 bcrypt $2a$ 的速度慢得很漂亮 XD 不過 SHA512 的速度比 SHA256 慢不少倒是頗意外...

PBKDF2 的使用率很高 (因為無線網路 WPA/WPA2 的規格),所以各語言的普及率也高不少,如果要找個標準來用的話,PBKDF2 相當不錯...

Btrfs 的 Hash Collision...

Slashdot 上看到「Denial-of-Service Attack Found In Btrfs File-System」覺得很有趣,結果一看,又是 hash collision... XD

一年前的「n.runs-SA-2011.004 - web programming languages and platforms - DoS through hash table (PDF)」打爆所有主流語言,沒想到在 filesystem 上也發生了 XDDD

不知道要怎麼修正... (已經存在的資料要怎麼 migrate?incompatible change?)

暴力法破解密碼...

MD5SHA-1 或是前陣子通過的 SHA-3,都不是設計用來單向儲存密碼用的。bcrypt 或是 PBKDF2 比較接近這個需求。

針對使用 Cryptographic hash function 儲存密碼的行為,除了可以用 Rainbow table 攻擊外,最近流行使用 GPU 加速暴力運算...

前幾天看到的 cluster 相當威猛,可以在 5.5 小時內計算出「所有 8 個字元的組合」(NTLM):「25-GPU cluster cracks every standard Windows password in <6 hours」。

這個 cluster 用了 25 張 AMD Radeon 卡,如果是針對 SHA-1 計算,每秒可以計算 630 億次,如果是 MD5 的話則可以到每秒 1800 億次,NTLM 則是每秒 3500 億次。

不過算一算也是吃電大怪物... XD

SHA-3 最後審查...

Schneier on Security 上看到 SHA-3 的消息:「SHA-3 to Be Announced」。

1997 年,NIST 要找尋 Data Encryption Standard (DES) 的下一代標準,發起了有名的 AES 遴選計畫,也就是 Advanced Encryption Standard process

公開遴選 AES 的成果就是在 2001 年 NIST 選出 Rijndael,由 Vincent RijmenJoan Daemen 兩位比利時密碼學家所發展出的對稱式加密系統。這個成果以現在來看是相當受到好評的:從 1998 年 Rijndael 問世到現在已經將近 15 年,成為官方標準後也超過 10 年,在這麼長時間接受全世界密碼學家檢驗後,有效的攻擊 (full cycle,可以破解實際流量的演算法) 是 2009 年一系列針對 192bits 與 256bits 的攻擊 (Related-key attack),以及 2011 年針對所有 128bits/192bits/256bits 的攻擊 (Key-recovery attack),仍然都還不到「實用」的程度 (用合理的硬體與資源破解)。

因此,當 MD5SHA-1 被攻的亂七八糟時 (2004 年王小雲教授往 ePrint 上丟出有名的「Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD」論文,給出兩個 vector 直接給出證明已經找到 collision),NIST 也想要透過同樣的遴選過程建立標準。於是,在 2007 年 NIST 宣佈了遴選計畫,這套標準就叫做 SHA-3,遴選過程則可以在 NIST hash function competition 這邊查到。

歷經五年的競爭,SHA-3 終於要宣佈結果了... (也有可能宣佈「沒有得主」?)

儲存密碼的方式

主要是參考「Cryptographic Right Answers」這篇給的建議:

Password handling: As soon as you receive a password, hash it using scrypt or PBKDF2 and erase the plaintext password from memory.
Do NOT store users' passwords. Do NOT hash them with MD5. Use a real key derivation algorithm. PBKDF2 is the most official standard; but scrypt is stronger.
Please keep in mind that even if YOUR application isn't particularly sensitive, your users are probably re-using passwords which they have used on other, more sensitive, websites -- so if you screw up how you store your users' passwords, you might end up doing them a lot of harm.

其中 scrypt 是作者自己發展的演算法,這邊看看就好。

你可以用 PBKDF2 (RFC 2898)。這邊假設的前提是,你不需要常常重複計算使用者的密碼是否正確。在這個前提下,我們可以把演算法弄得很複雜,而且很耗時,要複雜到用硬體加速也無法產生實質上有效的攻擊。

如果你對密碼學這個領域並不熟,Colin Percival 這篇文章可以拿來當做起點,文章裡面告訴你,某些類型的問題會用某些工具解決。