NIST 的密碼原則將禁止服務商要求「混合字元」

在「NIST to forbid requirement of specific passwords character composition (mastodon.social)」這邊看到的消息,出自 Fediverse 上的「Lukasz Olejnik: "GREAT change is approaching. NIST will standardis…" - Mastodon」這則,在講密碼規則中不得要求「混合字元」,像是要求要有「至少一個大寫 + 一個小寫 + 一個特殊符號」這樣的條件被禁止了。

現行的 NIST Special Publication 800-63B 是在 2017 年發表的第三版:「NIST Special Publication 800-63B」,這個版本關於混合字元的說明是 SHOULD NOT

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

這次第四版 draft (目前可以在「https://pages.nist.gov/800-63-4/sp800-63b.html」這邊看到) 則是改成 SHALL NOT

Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.

這邊的 SHOULD NOTSHALL NOT 有定義在文件開頭,這邊的定義與 RFC 2119 類似:

The terms “SHALL” and “SHALL NOT” indicate requirements to be followed strictly in order to conform to the publication and from which no deviation is permitted.

The terms “SHOULD” and “SHOULD NOT” indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited.

也就是說從建議變成強制性的要求了。

NIST SP 800-63B 算是重要的 reference,我記得前陣子有看到社群在蒐集整理密碼要求,要送到政府單位當作外部意見的,裡面也是引用了不少 NIST SP 800-63B 的內容,但一時間沒找到... (好像是放在 HackMD 上?)

密碼裡面不能有 SELECT/INSERT/UPDATE/DELETE/DROP

這是在 Hacker News 上看到的:「Password may not contain: select, insert, update, delete, drop (uni-lj.si)」,原網站在「Password reset - ID portal」,熱鬧的地方在於原作者 (或是外包商?) 也在 Hacker News 上面回應...

禁止密碼裡面有某些字元還蠻常見的,但這次看到的很有趣 (然後被貼到 Hacker News 上):

Your password must also not contain the following character combinations: script, select, insert, update, delete, drop, --, ', /*, */.

從網域及英文版的介面可以查到這是盧比安納大學的系統,作者 (或是外包) 在 id=39079030 提到了這是上面的要求:

Oooh! I put that string there! It was a request by management, and I still don't know why. This site doesn't store any passwords, it's basically just a nice interface to external account management.

I heard a rumour that some legacy apps have weird validation on their login fields, so students wouldn't be able to log in with passwords containing certain strings. But I don't actually know of any examples.

就... 很好玩?

LSAs 與 application password 不同...

前天在「使用 application password 的 Google 服務將在 2024/09/30 停止支援」這邊寫完後,yan12125 在文章留言的地方提到:

看起來這次只有停止支援 Less Secure Apps, application password 還是可以用的。公告中提到:

> If the app you are using does not support OAuth, you will need to switch to an app that offers OAuth or create an app password to access these apps.

回頭去翻了一下 LSA 是什麼 (出自「Limiting access to less secure apps to protect G Suite accounts」這篇):

A less secure app (LSA) is an app that connects to Google accounts using only username and password verification for access and not OAuth. Generally, you should only allow your users to use external apps that connect to Google accounts via OAuth, as LSAs make user accounts more vulnerable to hijacking.

看起來這邊指的是用原始的 Google 帳號與密碼登入,我一直以為這個方式早就被拔掉了,所以這次的公告以為是拔掉 application password,但看起來不是這樣。

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 都是大幅領先的情況 (台積電幫了不少?)。

LastPass 離職員工的爆料

這次 LastPass 出包搞的蠻大的,在官方的「Notice of Recent Security Incident」的裡面有提到這次的資料外洩包括了使用的 encrypted vault data 也被洩漏了:

The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data.

官方一直強調這是 encrypted data,但離職員工爆料加密強度不足的問題:「1606428769731878913.html」,其中這段在講 legacy 版本的加密問題,居然曾經用過 ECB mode

Lots of vault entries may be encrypted with ECB mode AES-256. I worked on supporting unauthenticated CBC mode. But re-encrypting a users vault entries requires having their master key.

這個如同 Hacker News 上的討論「I worked at LastPass as an engineer (twitter.com/ejcx_)」提到的,以 1980 年代的標準就已經知道 ECB mode 的問題了:

> Lots of vault entries may be encrypted with ECB mode AES-256.
Wtf wtf wtf. This would be considered wildly insecure even by the standards of the 80s

其他提到 PBKDF2 的強度是逐步增加,從早期的 5000 到現在預設的 100100,這點倒是可以理解。

要避免依賴廠商的資安,一種方式是用目前成熟的開源 Password Manager,並且使用檔案儲存 (像是 KeePassXC 這類工具),再搭配 file sync 的工具跨機器使用 (像是 Syncthing 這樣獨立確認每個 device 身份的方式),但方便性不會像這些商用方案這麼好用就是了...

這次故事好像還沒結束,遇到西方的長假,反應都比較慢...

KeePassX 宣佈不再維護了

Daily Lobsters 上看到 KeePassX 宣佈不再繼續維護了:「Development stopped」,在 Lobsters 上的討論也可以翻翻:「KeePassX development stopped」。

KeePassX 與 KeePassXC 都是 open source 版本的 password manager,單檔的設計可以配合很多不同的服務同步,自己架 Syncthing 或是用 Dropbox 之類的同步都是可行的,看對安全性的要求如何。

KeePassX 上次的更新是 2016 年推出的 2.0.3,已經超過五年沒有更新了。官方建議的替代方案是 KeePassXC

KeePassX is no longer actively maintained.

You might want to switch to KeePassXC which is based on KeePassX.

算是接棒交接出去...

密碼輸入上的 UX

Hacker News 上看到「Gmail password first character is case insensitive on mobile device (support.google.com)」這篇,在講密碼輸入上的 UX。

在 Hacker News 上的討論看到這則:

This is a well-understood feature. Facebook does the same thing[0].

Quote:

Facebook actually accepts three forms of your password:

* Your original password.

* Your original password with the first letter capitalized. This is only for mobile devices, which sometimes capitalize the first character of a word.

* Your original password with the case reversed, for those with a caps lock key on.

[0]: https://www.zdnet.com/article/facebook-passwords-are-not-case-sensitive-update/

接受三種密碼,第一種是完全正確的密碼,第二種是第一個字如果是大寫時的密碼 (在行動裝置上可能的行為),第三種是大小寫全部相反的密碼,這在沒注意到 caps lock 時會發生。

強度不會削弱太多,但對於 user experience 好很多的設計。

Kaspersky Password Manager 的漏洞

Hacker News Daily 上看到「Kaspersky Password Manager: All your passwords are belong to us」這篇,講 Kaspersky Password Manager (KPM) 嚴重的安全漏洞,另外在 Hacker News 上的討論「Kaspersky Password Manager: All your passwords are belong to us (ledger.com)」也有提到一些有趣的東西。

標題的 All your passwords are belong to us 是出自「All your base are belong to us」這個梗的變形。

這包安全問題主要的原因是因為 KPM 沒有使用 CSPRNG,而且也沒有正確 seed,所以極為容易被猜出密碼本身。

KPM 的 Web 版使用了 Math.random(),在各家瀏覽器主要是用 xorshift128+ 實做 Math.random(),作者沒有針對這塊再花時間研究,但很明顯的 Math.random() 不是個 CSPRNG:

The underlying PRNG used by Chrome, Firefox and Safari for Math.random() is xorshift128+. It is very fast, but not suitable to generate cryptographic material. The security consequences in KPM has not been studied, but we advised Kaspersky to replace it with window.crypto.getRandomValues(), as recommended by the Mozilla documentation page previously mentioned.

Note: Math.random() does not provide cryptographically secure random numbers. Do not use them for anything related to security. Use the Web Crypto API instead, and more precisely the window.crypto.getRandomValues() method.

而桌機版則是用了 MT19937,理論上取得 624 bytes 的輸出後就可以重建整個 PRNG 的內部狀態 (於是就可以預測後續的 output),但這代表你要知道其他網站的密碼,這點其實有點困難。

但作者發現 KPM 在產生 MT19937 的 seed 只跟時間有關,超級容易被預測:

So the seed used to generate every password is the current system time, in seconds. It means every instance of Kaspersky Password Manager in the world will generate the exact same password at a given second.

於是可以直接暴力解出所有的可能性:

The consequences are obviously bad: every password could be bruteforced. For example, there are 315619200 seconds between 2010 and 2021, so KPM could generate at most 315619200 passwords for a given charset. Bruteforcing them takes a few minutes.

Hacker News 上有不少陰謀論的討論,像是:

Getting some DUAL_EC prng vibes.

Insert Kaspersky owned by Russia intelligence conspiracy here...

另外 Kaspersky 跟俄羅斯軍方的關係也是很知名,這些東西大概要到十來年後才會知道...