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].


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 跟俄羅斯軍方的關係也是很知名,這些東西大概要到十來年後才會知道...

Dropbox 也要搞自己的密碼管理器

Dropbox 也要搞自己的密碼管理器 Dropbox Passwords:「Dropbox Passwords coming soon for all users」。

看起來只要是 Dropbox 的付費方案就可以無限使用,而免費版的則是 50 組。從下載頁看起來目前在 PC 上只支援 Microsoft WindowsmacOS,不支援 Linux

Come back to this page on a PC with Windows 10 or a Mac with at least macOS Sierra 10.12 to get the Passwords desktop app.

而行動平台就是 iOSAndroid

How do I use the Android and iPhone password manager?

Once you sign in to the Passwords app, it automatically fills in your usernames and passwords so you can access frequently used apps and websites on your mobile device.

從示意圖看起來有整合瀏覽器,而加密技術的部份沒有講太多,只說是 zero-knowledge encryption,先觀望看看...

LastPass 開始進入「殺」的階段,免費使用者只能在一個平台上使用

LastPass 進入了「套養殺」最後一個階段「殺」,宣佈縮減 LastPass Free 的可用範圍。在 2021/03/16 開始 (一個月後),LastPass Free 的使用者只能選擇一個平台使用,像是「桌機平台」,或是「行動平台」:「LastPass’ free tier will become a lot less useful next month」,官方的新聞稿則是在「Changes to LastPass Free」這邊。

官方有提供第一年的限時優惠 (換算起來應該是一年 USD$27),但不給既有用戶,現有的用戶如果要的話得自己換帳號 export & import,不然就是用原價殺 (一年 USD$36):

If you’d like unlimited device type access and email support, you can upgrade from Free to LastPass Premium for a limited time, for $2.25 per month (billed annually). *

*Additional Terms and Conditions: Advertised price valid for new users on their first year of LastPass Premium. Price not valid for renewals or existing customers and cannot be used for other LastPass plans, products or services.


話說回來,這種東西我自己還是偏好用 open source 方案,然後自己搭同步機制,不過目前看到的方案在跨桌機平台與行動平台的確是痛點... 有需求的人應該還是會選 LastPass 或是 1Password 這樣的方案。

Zoom 預設開啟密碼原因

最早的時候用 Zoom 只需要知道 meeting room 的編號就可以連進去,產生連結時也只需要提供號碼就能進去,後來 (不知道什麼時候開始的) 產生出來的連結會包括一組 token,而預設加入房間也需要密碼了。

現在知道原因了,因為被安全通報了:「Zoom Fixes Flaw Opening Meetings to Hackers」。

除了上面講到的問題以外,另外一個漏洞是本來的連結網頁就有資訊可以辨別是否為合法的 meeting room,可以讓攻擊者很快速的判斷哪些 meeting room 可以連進去。這次的修改變成不檢查,直接帶到 Zoom 的應用程式裡面,增加一些難度,但攻擊者還是可以透過 API 掃出來。



在「HTML attributes to improve your users' two factor authentication experience」這邊看到關於讓使用者輸入 2FA (通常是數字) 比較流暢的設定。

原始是上面這張這樣,目標是希望下面這張這樣,當透過 SMS 2FA 時可以提供選項直接貼上,而且也自動帶出數字鍵盤:

給出的幾個重點在於 inputmodepattern 以及 autocomplete


查了一下 caniuse.com 上面的支援度,pattern 基本上都支援了,autocomplete 在這邊用到的 one-time-code 基本上也沒問題,只有 inputmode 這邊支援度比較差,IE11 (基本上不會更新了)、FirefoxSafari 沒支援。

用 QR Code 讓使用者可以直接登入 WiFi

在「Encoding your WiFi access point password into a QR code」這邊看到的,不過之前在公司頻道裡面也有看到類似的東西...

產生這樣的 QR code 讓使用者掃就可以了: