在「U2F support in OpenSSH HEAD」這邊看到 OpenSSH 的 HEAD 支援 U2F 了,使用的命名叫做 sk-ecdsa-sha2-nistp256@openssh.com
。
照 mailing list 上更完整的說明「U2F support in OpenSSH HEAD」,看起來是當主要的 key,而不是當 MFA,也許再研究看看...
幹壞事是進步最大的原動力
在「U2F support in OpenSSH HEAD」這邊看到 OpenSSH 的 HEAD 支援 U2F 了,使用的命名叫做 sk-ecdsa-sha2-nistp256@openssh.com
。
照 mailing list 上更完整的說明「U2F support in OpenSSH HEAD」,看起來是當主要的 key,而不是當 MFA,也許再研究看看...
在「Yubico iOS Authentication Expands to Include NFC」這邊看到 iOS 13 上對於 NFC 類的 MFA 會有的進展。
主要是因為之前的 NFC 只有讀取能力,所以 U2F/FIDO2/WebAuthn 之類的應用沒有辦法套用上去:
Previously, NFC on iOS was read-only, which meant that it couldn’t support modern authentication protocols like FIDO U2F, FIDO2/WebAuthn that require both read and write capabilities – but now that has changed.
iOS 13 後開放了 API 可以讀寫,所以有辦法支援這些協定了:
With these recent updates, iPhone users (running iOS 13+) can experience mobile NFC authentication with a YubiKey 5 NFC or Security Key NFC by Yubico on apps and browsers that have added support.
對於主力放在 Apple Ecosystem 的人,總算是等到了...
看到「Disable SMS or voice codes for 2-Step Verification for more secure accounts」這邊的說明,G Suite 的管理員可以將 SMS 與 Voice 強制關閉 (也就是不認為這兩個管道是安全的 2FA)。
主要是因為行動網路一直都不怎麼安全,像是 GPRS 與 3G network 使用的 KASUMI,或是 downgrade attack (用 2G network)。
目前 G Suite 登入有提供的 2FA 除了上面這兩個以外,應該還有 TOTP 與 U2F 類的認證方式,這次影響最大的應該是堅持用非智慧型手機的人?這種:
Facebook 上的行動電話號碼除了被拿來當作 2FA 的備案外,也被強制分享。更糟的是還被拿來當作廣告的條件:
For years Facebook claimed the adding a phone number for 2FA was only for security. Now it can be searched and there's no way to disable that. pic.twitter.com/zpYhuwADMS
— Jeremy Burge ?? (@jeremyburge) March 1, 2019
This is so crazy: even if you deliberately don't include your mobile number in your Facebook profile, they'll harvest it when you use it for two-factor authentication, and let advertisers target you with it. https://t.co/0TIr0zsJOt pic.twitter.com/TigHlGR2zF
— Tom Gara (@tomgara) September 26, 2018
Yubico 在 CES 2019 上宣佈推出兩用版的 YubiKey,同時支援 USB-C 與 Lightning 接頭:「Yubico Launches the Security Key NFC and a Private Preview of the YubiKey for Lightning at CES 2019」。
從照片可以看出來是直接做成兩側各一個頭:
目前是 Private Preview,開發者需要跟 Yubico 申請:
If you are a developer or service that would like to support strong hardware authentication on iOS, we invite you to work with us by applying to participate in the YubiKey for Lightning Program. Selected participants will have access to the private preview of YubiKey for Lightning and also the Yubico Mobile iOS SDK for Lightning.
不過看起來是硬體限制沒辦法朝 NFC 支援?另外如果蘋果下一代 iPhone 換掉變成 USB-C 就搞笑了...
再弄 WordPress 的 U2F 時發現他也可以共存其他 2FA 機制 (也就是可以挑一種方式當 2FA,像是 TOTP),就開始重設 OTP...
結果手賤把 FreeOTP 的 '
改成 '
(因為看起來不順眼 XD),就遇到「FreeOTP stuck crashing at startup if name contains certain characters · Issue #100 · freeotp/freeotp-ios」這個問題,結果 FreeOTP 直接閃退開不起來,而且沒有 workaround 的方式存取其他的 OTP token...
找了一下替代方案,目前先用「mattrubin/Authenticator: Two-Factor Authentication Client for iOS」這套了,要注意有同名而且界面很像的 app 在上面,要確認作者名稱...
然後接下來就是一連串 reset 2FA token 的步驟了,有些當初沒有留 backup code 超麻煩 @_@
CA/Browser Forum 會定時將會議記錄與最後的結論公開放在網站上,有時候有些資訊還蠻有趣的。像是前幾天在「Ballot 221 - Two-Factor Authentication and Password Improvements - CAB Forum」這邊看到 CA/Browser Forum 的成員對密碼與 2FA 提出了修正提案,其中瀏覽器端只有 Microsoft 參與投票,但是被否決了...
不知道否決的原因,但是大概可以猜到幾個點。
第一個是提案提到了 NSA 的 NIST 800-63B Appendix A,這個單位不太受歡迎啊...
第二個則是「For accounts that are accessible only within Secure Zones or High Security Zones, require that passwords have at least twelve (12) characters;」這段強迫使用密碼,而現在有比密碼更安全的方案存在 (以 public key cryptography 為認證基礎的方案),像是早期的 U2F 以及今年定案的 WebAuthn。
應該是這些原因吧...
Adam Langley 的「Testing Security Keys」這篇測試了不少有支援 U2F Security Key 的產品,這邊作者是以 Linux 環境測試。
tl;dr:在 Linux 環境下,除了 Yubico 的產品沒問題外,其他的都有問題... (只是差在問題多與少而已)
Yubico 的沒找到問題:
Easy one first: I can find no flaws in Yubico's U2F Security Key.
VASCO SecureClick 的則是 vendor ID 與 product ID 會跑掉:
If you're using Linux and you configure udev to grant access to the vendor ID & product ID of the token as it appears normally, nothing will work because the vendor ID and product ID are different when it's active. The Chrome extension will get very confused about this.
Feitian ePass 的 ASN.1 DER 編碼是錯的:
ASN.1 DER is designed to be a “distinguished” encoding, i.e. there should be a unique serialisation for a given value and all other representations are invalid. As such, numbers are supposed to be encoded minimally, with no leading zeros (unless necessary to make a number positive). Feitian doesn't get that right with this security key: numbers that start with 9 leading zero bits have an invalid zero byte at the beginning. Presumably, numbers starting with 17 zero bits have two invalid zero bytes at the beginning and so on, but I wasn't able to press the button enough times to get such an example. Thus something like one in 256 signatures produced by this security key are invalid.
Thetis 根本沒照 spec 走,然後也有相同的 ASN.1 DER 編碼問題:
With this device, I can't test things like key handle mutability and whether the appID is being checked because of some odd behaviour. The response to the first Check is invalid, according to the spec: it returns status 0x9000 (“NO_ERROR”), when it should be 0x6985 or 0x6a80. After that, it starts rejecting all key handles (even valid ones) with 0x6a80 until it's unplugged and reinserted.
This device has the same non-minimal signature encoding issue as the Feitian ePass. Also, if you click too fast, this security key gets upset and rejects a few requests with status 0x6ffe.
U2F Zero 直接 crash 沒辦法測 XDDD:
A 1KiB ping message crashes this device (i.e. it stops responding to USB messages and needs to be unplugged and reinserted). Testing a corrupted key handle also crashes it and thus I wasn't able to run many tests.
KEY-ID (網站連 HTTPS 都沒上...) / HyperFIDO 也有編碼問題但更嚴重:
The Key-ID (and HyperFIDO devices, which have the same firmware, I think) have the same non-minimal encoding issue as the Feitian ePass, but also have a second ASN.1 flaw. In ASN.1 DER, if the most-significant bit of a number is set, that number is negative. If it's not supposed to be negative, then a zero pad byte is needed. I think what happened here is that, when testing the most-significant bit, the security key checks whether the first byte is > 0x80, but it should be checking whether it's >= 0x80. The upshot is the sometimes it produces signatures that contain negative numbers and are thus invalid.
所以還是乖乖用 GitHub 帳號買 Yubico 吧...
用軟體實做 U2F,目前是開發在 macOS 上:「Introducing Soft U2F, a software U2F authenticator for macOS」。
實在是不愛這種方式,由於是軟體式的,安全性低了不少... (機器被入侵後就都沒有防護了)
不過 U2F 是目前少數可以在 protocol 層抵抗 phishing 的方式,相較於一般 OTP 的方式還是得很注意網址,所以站在推廣的立場的確是希望能多一點人用...
Facebook 也支援 U2F (Universal 2nd Factor) 了:「Security Key for safer logins with a touch」。
之前買 Yubico 的 Yubikey 好像不支援 U2F (很久前買的版本),好像該買幾顆玩具看看了... 剛剛翻了翻 Amazon,好像不少家都有支援 U2F,也許不一定要買 Yubico 的產品 :o