bcrypt

Hashcat 在 3090 與 4090 上的速度差異

想到的時候查了一下，發現進步頗大的...

可以參考「Hashcat v6.1.1 benchmark on the Nvidia RTX 3090」與「Hashcat v6.2.6 benchmark on the Nvidia RTX 4090」這兩份資料。

已經被打到爛的 $1$ 或是 $apr1$ 就不看了，主要還是看比較有抵抗性的 KDF 的速度。

撞老牌的 bcrypt，在 4090 的速度快要是 3090 的兩倍了：

Hashmode: 3200 - bcrypt $2*$, Blowfish (Unix) (Iterations: 32)
Speed.#1.........:    96662 H/s (36.29ms) @ Accel:8 Loops:16 Thr:11 Vec:1

* Hash-Mode 3200 (bcrypt $2*$, Blowfish (Unix)) [Iterations: 32]
Speed.#1.........:   184.0 kH/s (50.22ms) @ Accel:4 Loops:32 Thr:24 Vec:1

但是在看 scrypt 的時候不知道為什麼 3090 跑的 iterations 是 1，這兩個不對等：

Hashmode: 8900 - scrypt (Iterations: 1)
Speed.#1.........:  2308.2 kH/s (8.64ms) @ Accel:16 Loops:1 Thr:16 Vec:1

* Hash-Mode 8900 (scrypt) [Iterations: 16384]
Speed.#1.........:     7126 H/s (29.16ms) @ Accel:128 Loops:1024 Thr:32 Vec:1

改看 9300 這組的話，iterations 還是 1：

Hashmode: 9300 - Cisco-IOS $9$ (scrypt) (Iterations: 1)
Speed.#1.........:    85331 H/s (122.39ms) @ Accel:16 Loops:1 Thr:8 Vec:1

* Hash-Mode 9300 (Cisco-IOS $9$ (scrypt)) [Iterations: 16384]
Speed.#1.........:    83890 H/s (1.76ms) @ Accel:128 Loops:1024 Thr:32 Vec:1

再來是看 PBKDF2 類的，這邊先抓 9200 這組，可以看到 4090 的速度是 3090 的兩倍多：

Hashmode: 9200 - Cisco-IOS $8$ (PBKDF2-SHA256) (Iterations: 19999)
Speed.#1.........:   187.2 kH/s (91.61ms) @ Accel:16 Loops:256 Thr:1024 Vec:1

* Hash-Mode 9200 (Cisco-IOS $8$ (PBKDF2-SHA256)) [Iterations: 19999]
Speed.#1.........:   430.1 kH/s (60.71ms) @ Accel:16 Loops:512 Thr:512 Vec:1

另外 10900 這組也是兩倍多：

Hashmode: 10900 - PBKDF2-HMAC-SHA256 (Iterations: 999)
Speed.#1.........:  3785.4 kH/s (87.58ms) @ Accel:4 Loops:999 Thr:1024 Vec:1

* Hash-Mode 10900 (PBKDF2-HMAC-SHA256) [Iterations: 999]
Speed.#1.........:  8865.7 kH/s (50.50ms) @ Accel:64 Loops:124 Thr:512 Vec:1

考慮到單位價錢的效能，與單位功率的效能，4090 都是大幅領先的情況 (台積電幫了不少？)。

改 Open Distro for Elasticsearch 預設密碼的方式

AWS 弄出來的 Open Distro for Elasticsearch 因為內建了安全性的功能 (參考「AWS 對 Elastic Stack 實作免費的開源版本 Open Distro for Elasticsearch」)，應該是目前新架設 Elasticsearch 的首選。

不過裝好後預設有五個帳號，但從 Open Distro 的 Kibana 介面無法修改改其中兩個使用者的密碼 (admin 與 kibanaserver)，要修改密碼發現得花不少功夫，不知道為什麼要這樣設計 :/

這邊講的是透過 RPM (以及 deb) 的方式的修改方式，如果是 Docker 的方式請參考後面提到在 AWS blog 上的文章：「Change your Admin Passwords in Open Distro for Elasticsearch」。

首先先透過 hash.sh 產生 bcrypt 的 hash，像是這樣 (輸入 password 當密碼)：

bash /usr/share/elasticsearch/plugins/opendistro_security/tools/hash.sh
WARNING: JAVA_HOME not set, will use /usr/bin/java
[Password:]
$2y$12$QchkpgY8y/.0TL7wruWq4egBDrlpIaURiBYKoZD50G/twdylgwuhG

然後修改 /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/internal_users.yml 檔案裡面的值，順便改掉 readonly 的部分。

接下來是把這個 internal_users.yml 檔案的設定更新到 Elasticsearch 裡。由於這邊需要讀 /etc/elasticsearch/ 的東西，所以偷懶用 root 跑：

sudo bash /usr/share/elasticsearch/plugins/opendistro_security/tools/securityadmin.sh -cd ../securityconfig/ -icl -nhnv -cacert /etc/elasticsearch/root-ca.pem -cert /etc/elasticsearch/kirk.pem -key /etc/elasticsearch/kirk-key.pem

做完後可能要重跑 Elasticsearch 與 Kibana：

sudo service elasticsearch restart
sudo service kibana restart

或是重開機... 順便測試看看重開後有沒有生效。理論上修改完成後，就是用新的帳號密碼連到 Kibana。

上面的方法是參考了「Default Password Reset」(先找到這篇) 與「change admin password」(後來在 AWS blog 的文章上發現的 GitHub issue 連結) 這邊的資訊。

官方的說明文件則是在寫這篇文章時才找到的，平常搜尋時不太會出現：「Apply configuration changes」。

Twitter 密碼中槍...

Twitter 發了公告請大家改密碼：「Keeping your account secure」。不只是 Twitter 自家的密碼，如果你有重複使用同一組密碼，也建議一起修改：

Out of an abundance of caution, we ask that you consider changing your password on all services where you’ve used this password.

雖然使用 bcrypt，但因為透過 log 記錄下了未加密的密碼，所以就中槍了：

We mask passwords through a process called hashing using a function known as bcrypt, which replaces the actual password with a random set of numbers and letters that are stored in Twitter’s system. This allows our systems to validate your account credentials without revealing your password. This is an industry standard.

Due to a bug, passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again.

這時候就要再推 Password manager 這種東西了，在每個站台都使用完全不同的密碼，可以降低這類問題帶來的衝擊...

Imgur 也漏資料了... (帳號與密碼)

Imgur 官方發佈公告說明他們發現資料洩漏了：「Notice of Data Breach」，資料的洩漏是發生在 2014 年，包括了帳號與密碼：

Early morning on November 24th, we confirmed that approximately 1.7 million Imgur user accounts were compromised in 2014. The compromised account information included only email addresses and passwords. Imgur has never asked for real names, addresses, phone numbers, or other personally-identifying information (“PII”), so the information that was compromised did NOT include such PII.

然後 2014 年用的是 SHA-256：

We have always encrypted your password in our database, but it may have been cracked with brute force due to an older hashing algorithm (SHA-256) that was used at the time. We updated our algorithm to the new bcrypt algorithm last year.

以單台八張 GTX 1080 跑 hashcat 的速度來看 (出自「8x Nvidia GTX 1080 Hashcat Benchmarks」)，是 23GH/z 左右：

Hashtype: SHA256

Speed.Dev.#1.: 2865.2 MH/s (96.18ms)
Speed.Dev.#2.: 2839.8 MH/s (96.65ms)
Speed.Dev.#3.: 2879.5 MH/s (97.14ms)
Speed.Dev.#4.: 2870.6 MH/s (96.32ms)
Speed.Dev.#5.: 2894.2 MH/s (96.64ms)
Speed.Dev.#6.: 2857.7 MH/s (96.78ms)
Speed.Dev.#7.: 2899.3 MH/s (96.46ms)
Speed.Dev.#8.: 2905.7 MH/s (96.26ms)
Speed.Dev.#*.: 23012.1 MH/s

這對於鍵盤可以打出的所有字元來計算 (95 chars)，八個字的密碼只要 3.33 天就可以跑完；如果只考慮英文數字 (62 chars)，九個字的密碼只要 6.81 天。

這些還不是最新的 GPU，而且是單機計算，對於現在的攻擊應該會用 ASIC，可以考慮多三到四個數量級的數度在算 (看財力才會知道買多少機器)。

不過 Imgur 的帳號主要是參與討論 (因為不用帳號密碼也可以上傳圖片)，一般比較不會在上面註冊... 真的有註冊的因為沒有其他個資，主要是怕共用密碼的問題。如果有用 password manager 應該也還好。

歡樂的 md5crypt 密碼...

作者寫了一篇關於以前在 WHOIS 記錄上看到一串 $1$ 開頭的 md5crypt 密碼 XDDD：「I mean, why not tell everyone our password hashes?」。

Now the fields are filtered but this is a reasonably recent change. Prior to July 2015 the hashed passwords were shown to anyone who whois’d the maintainer object and used md5 passwords. Which was nearly all of them in my experience.

Mntner:         DTAG-NIC
Descr:          Deutsche Telekom Internet Services NIC
Admin-c:        KK281-RIPE
Tech-c:         HI56-RIPE
Auth:           MD5-PW $1$KQ3NSRfS$/bcvLAz2BKyf5HF4VkPMh/
Mnt-by:         DTAG-NIC
Referral-by:    RIPE-DBM-MNT

不知道有沒有人去跑看看... XD

話說 md5crypt 已經被認為不安全 (當初的發明人 phk 也有出來建議大家換掉了：「Md5crypt Password scrambler is no longer considered safe by author」)，從目前 Hashcat 的攻擊速度就可以看出來... 找個最近的例子來說，可以參考「8x Nvidia GTX 1080 Hashcat Benchmarks」這篇。

Hashtype: md5crypt, MD5(Unix), FreeBSD MD5, Cisco-IOS MD5

Speed.Dev.#1.:  9918.1 kH/s (97.10ms)
Speed.Dev.#2.:  9830.1 kH/s (97.70ms)
Speed.Dev.#3.: 10017.4 kH/s (97.36ms)
Speed.Dev.#4.:  9986.5 kH/s (96.92ms)
Speed.Dev.#5.:  9976.8 kH/s (97.74ms)
Speed.Dev.#6.:  9889.2 kH/s (97.29ms)
Speed.Dev.#7.: 10010.5 kH/s (97.40ms)
Speed.Dev.#8.: 10083.0 kH/s (96.94ms)
Speed.Dev.#*.: 79711.6 kH/s

而隔壁的 bcrypt 對 Hashcat 的防禦性完全在不同等級：

Hashtype: bcrypt, Blowfish(OpenBSD)

Speed.Dev.#1.:    13094 H/s (47.51ms)
Speed.Dev.#2.:    13076 H/s (47.63ms)
Speed.Dev.#3.:    13292 H/s (46.88ms)
Speed.Dev.#4.:    13250 H/s (47.17ms)
Speed.Dev.#5.:    13296 H/s (46.86ms)
Speed.Dev.#6.:    13160 H/s (47.30ms)
Speed.Dev.#7.:    13260 H/s (46.98ms)
Speed.Dev.#8.:    13280 H/s (46.80ms)
Speed.Dev.#*.:   105.7 kH/s

直接相除是 754 倍左右。

以 85 個字元的組合計算 ([0-9A-Za-z] 62 個，特殊字元 22 個，加上空白 1 個)，抗性多了 1.5 個字 (log₈₅(754) 大約是 1.49)？如果以 62 個字元來看也有 1.6 個字，強了不少...

Dropbox 儲存密碼的方式

記得 Dropbox 前陣子才強迫所有使用者重設密碼：「The Dropbox hack is real」，官方的報告在這：「Resetting passwords to keep your files safe」，當時洩漏出來的資訊可以知道 2012 年的時候 Dropbox 用的是 SHA1：

What we've got here is two files with email address and bcrypt hashes then another two with email addresses and SHA1 hashes.

三個多禮拜候，Dropbox 說明了現在的密碼儲存策略：「How Dropbox securely stores your passwords」，現在是先 SHA512，再 bcrypt，然後存在資料庫裡時使用 AES256 保護：

比較特別一點的是先 SHA512 的部份，除了 72bytes 常見限制外，另外一個原因是為了避免 DoS，不過還是覺得有點怪就是了：

Other implementations don’t truncate the input and are therefore vulnerable to DoS attacks because they allow the input of arbitrarily long passwords.

而 AES256 的部份則是確保就算 SQL injection 或是其他方式將儲存的密碼撈出去後，也還有相當程度的保護能力。

這次的 Ashley-Madison 資料外洩

在「Notes on the Ashley-Madison dump」這邊給了這次婚外情約會網站 Ashley Madison 資料外洩的註解，甚至還包括 BitTorrent 的 magnet:// 下載連結...

將近四千萬筆資料的資料外洩 (實際約三千六百萬)，男性為大宗，約 28 million 是男性，5 million 女性 (依據 gender 欄位)，有 2 million 無法確認。不過如果交叉比對信用卡資料，會發現只有男性付費：

It's heavily men. I count 28-million men to 5 million woman, according to the "gender" field in the database (with 2-million undetermined). However, glancing through the credit-card transactions, I find only male names.

另外是密碼儲存方式是 bcrypt：

Passwords hashed with bcrypt. Almost all the records appear to be protected with bcrypt. This is a refreshing change. Most of the time when we see big sites hacked, the passwords are protected either poorly (with MD5) or not at all (in "clear text", so that they can be immediately used to hack people). Hackers will be able to "crack" many of these passwords when users chose weak ones, but users who strong passwords are safe.

整包是 9.7GB 的壓縮資料... FreeBuf.COM 也整理了一篇：「七夕将至，婚外情网站数据终于裸奔了」。

Slack 密碼外洩

Slack 由於發現密碼外洩，剛剛發佈了資安通報：「March 2015 Security Incident and the Launch of Two Factor Authentication」。

這次也因此推出了兩個功能：

Two Factor Authentication (2FA)，使用者可以設定 2FA 登入。
Password Kill Switch，管理者可以強制重設所有人的密碼。

另外也透漏使用 bcrypt 為密碼演算法，只要密碼強度夠強，即使透漏出去應該也是不會有問題 (當然換掉還是比較好)。

各種密碼破解速度...

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

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

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

htpasswd 的 SHA 不會帶 salt (seed)...

剛剛發現 htpasswd (Apache 的 .htpasswd 檔案產生程式) 提供的 SHA-1 不會使用 salt，不過 MD5 格式會...

以密碼「test」測試：

gslin@colo-p [~] [17:44/W7] touch test.txt
gslin@colo-p [~] [17:44/W7] htpasswd -b -m test.txt test1 test
Adding password for user test1
gslin@colo-p [~] [17:44/W7] htpasswd -b -m test.txt test2 test
Adding password for user test2
gslin@colo-p [~] [17:44/W7] htpasswd -b -s test.txt test3 test
Adding password for user test3
gslin@colo-p [~] [17:44/W7] htpasswd -b -s test.txt test4 test
Adding password for user test4

結果是：

test1:$apr1$GU6SyO0y$I.Ng9o4H8Tcje.M2A6ECb0
test2:$apr1$uqoX9b/x$7zGMAKqRjvoi6HHSKtaRO.
test3:{SHA}qUqP5cyxm6YcTAhz05Hph5gvu9M=
test4:{SHA}qUqP5cyxm6YcTAhz05Hph5gvu9M=

依照說明，htpasswd 使用的 SHA 是移植自 Netscape server 的 LDAP Directory Interchange Format (ldif)：

Use SHA encryption for passwords. Facilitates migration from/to Netscape servers using the LDAP Directory Interchange Format (ldif).

在安全疑慮 (Security Considerations) 上也有註明 htpasswd 使用的 SHA 是不帶 salt：

The SHA encryption format does not use salting: for a given password, there is only one encrypted representation.

現在密碼儲存應該是朝 bcrypt 與 PBKDF2 發展，參考依林姊姊的「請愛用 bcrypt 和 PBKDF2」，後者 PBKDF2 被用在 WPA2 上。