Нууц үгийн алуурчин уу, шинэ "занга" юу? Passkey стандартын далд эрсдэл хөгжүүлэгчдийн дунд ширүүн маргаан дэгдээв

Сүүлийн 24 цагийн хугацаанд дэлхийн технологийн нийгэмлэг, ялангуяа Hacker News тавцан дээр нийтлэгдсэн нэгэн шүүмж нийтлэл 400 гаруй санал цуглуулж, 200 гаруй хөгжүүлэгчийн ширүүн маргааныг өрнүүллээ. Сэдэв нь: "Passkeys are a trap. Do not use them" (Passkey бол урхи. Үүнийг бүү ашигла).

Big Tech компаниуд болон FIDO Alliance-аас "нууц үггүй эрин үе"-ийн бэлгэдэл, хэрэглэгчийн аюулгүй байдлын туйлын шийдэл хэмээн сурталчилж буй Passkey/WebAuthn технологи нь үнэхээр тийм төгс эд мөн үү? Эсвэл энэ нь хэрэглэгчдийг болон хөгжүүлэгчдийг Apple, Google, Microsoft-ийн хаалттай экосистемд бүрмөсөн түгжих далд бодлого уу?

Мэдээллийн аюулгүй байдал, вэб хөгжүүлэлт хийж буй инженер бүрийн анхаарах ёстой энэхүү маргааны техникийн цаад учир шалтгааныг DEVX тоймлон хүргэж байна.

1. Амлалт ба Бодит байдал: Маркетингийн халхавч

FIDO Alliance (Apple, Google, Microsoft тэргүүтэй консорциум) хэрэглэгчдэд нэг л зүйлийг ойлгуулсан: “Хурууны хээгээ уншуулаад нэвтэр. Нууц үг тогтоох шаардлагагүй, фишингэд өртөхгүй.”

Мэдээж криптограф талаасаа WebAuthn нь Public-Key Cryptography дээр суурилдаг бөгөөд домэйнд уягдсан (domain-bound) байдаг тул хуурамч вэбсайтууд хэрэглэгчийн нууц түлхүүрийг луйвардаж чаддаггүй нь үнэн. Гэвч шүүмжлэгчдийн онцолж буйгаар FIDO Alliance техникийн хувьд эрс тэс ялгаатай олон шинж чанарыг нэг л "Passkey" гэдэг маркетингийн нэрэн дор хольж хутгасан байна:

Copyable vs. Non-copyable: Зарим түлхүүр нь Apple Keychain, Google Password Manager зэрэг үүлэн сангаар синхрончлогдож хуулбарлагддаг байхад, зарим нь зөвхөн тодорхой нэг физик чипэнд түгжигддэг.
Hardware vs. Software-backed: Төхөөрөмжийн Secure Enclave дээр хадгалагдаж буй түлхүүр үү, эсвэл үйлдлийн системийн энгийн санах ойд бичигдсэн эсэх.
Attested vs. Non-attested: Сервер хэрэглэгчийн төхөөрөмжийг криптографын түвшинд "байцаах" эрхтэй эсэх.

Эдгээр олон ялгаатай ойлголтуудыг нэг саванд багтааснаар хэрэглэгчид өөрсдийн дижитал эрх чөлөө, хувийн түлхүүрийнхээ эзэмшлийг мэдэлгүйгээр алдаж байна.

2. Remote Attestation: Жинхэнэ "Трояны морь"

Нийтлэлийн гол шүүмжлэл нь WebAuthn стандартын Remote Attestation (Алсын баталгаажуулалт) гэх функц дээр төвлөрч байна.

Хэрэглэгч системд Passkey үүсгэх үед сервер тал (Relying Party) тухайн түлхүүрийг ямар төхөөрөмж, ямар үйлдлийн систем, ямар тоног төхөөрөмжийн криптограф модуль (TPM/Secure Enclave) дээр үүсгэсэн бэ гэдгийг шалгах гэрчилгээ (attestation statement) нэхэх боломжтой.

Энэ механизм нь цаасан дээрээ аюулгүй байдлыг хангах зорилготой мэт боловч практикт дараах аюулыг авчирдаг:

Хаалттай системийн шахалт: Банк, томоохон цахим худалдаа эсвэл стриминг платформууд "Бид зөвхөн Apple, Google, Microsoft-ийн баталгаажуулсан төхөөрөмжөөс л нэвтрэхийг зөвшөөрнө" гэсэн бодлого хэрэгжүүлж эхэлбэл юу болох вэ?
Линукс болон нээлттэй эх кодын шахалт: Үйлдвэрлэгчийн тусгай криптограф сертификатгүй Linux десктопууд, Root хийсэн Android утаснууд, эсвэл бие даасан нээлттэй хөтчүүд (Firefox-ийн хувилбарууд, Brave г.м) системүүдэд "зөвшөөрөгдөөгүй/итгэлгүй" гэж үзэгдэн хаагдах эрсдэлтэй.
Web Environment Integrity-ийн дахин төрөлт: Өнгөрсөн жилүүдэд Google-ийн дэвшүүлж, олон нийтийн эсэргүүцлээр цуцлагдсан "Web Environment Integrity" (хөтчийг DRM-тэй болгох төсөл) нь үнэн хэрэгтээ Passkey-ийн attestation-аар дамжин арын хаалгаар хэрэгжиж байна гэж шинжээчид анхааруулж байна.

3. Хөгжүүлэгчийн амьдрал дээр: UX ба Инженерийн толгойн өвчин

Энэхүү хэлэлцүүлэг зөвхөн онолын түвшинд өрнөөгүй. Олон инженерүүд Passkey-ийг өөрсдийн системд нэвтрүүлэх явцад бодит асуудлуудтай тулгарч буйгаа хуваалцжээ.

Тухайлбал, сүүлийн үед нууц үгийн менежерүүд (жишээ нь 1Password) WebAuthn стандартын userVerification: required тохиргоог түлхүү шаардах болсноор TouchID байхгүй энгийн компьютер дээр хэрэглэгч сайтууд руу нэвтрэхийн тулд 1Password-ийн master password-оос гадна үйлдлийн системийнхээ нууц үгийг давхар байн байн шивэх төвөгтэй нөхцөл үүссэн байна.

Мөн олон хөгжүүлэгчид AI кодлогч хэрэгслүүдээр (LLM) authentication код бичүүлэхдээ анзааралгүйгээр attestation: "direct" эсвэл userVerification: "required" сонголтуудыг хуулж тавьснаар Линукс хэрэглэгчид болон нээлттэй нууц үгийн менежер (KeePassXC, self-hosted Bitwarden) ашигладаг инженерүүдийг системээсээ өөрсдөө ч мэдэлгүй хасч орхиж байна.

4. Backend болон Full-stack хөгжүүлэгчид юуг анхаарах ёстой вэ?

Хэрэв та өөрийн төсөлдөө WebAuthn / Passkey нэвтрүүлж байгаа бол дараах техникийн зөвлөмжүүдийг анхаарна уу:

Attestation шаардахгүй байх (attestation: "none"): Хэрэв та маш өндөр нууцлалтай цэргийн эсвэл санхүүгийн дотоод систем хөгжүүлээгүй л бол хэрэглэгчийн бүртгэлийн үед attestation-ийг "none" гэж тохируул. Энэ нь хэрэглэгч ямар ч үйлдлийн систем, ямар ч нээлттэй тоног төхөөрөмж (open-source hardware key) ашигласан саадгүй нэвтрэх нөхцөлийг хангана.
Хэрэглэгчийн шалгалтыг уян хатан байлгах (userVerification: "preferred"): "required" гэж хатуу заахын оронд "preferred"-ийг ашигласнаар биометр байхгүй орчинд хэрэглэгчийн туршлага (UX) эвдрэхээс сэргийлнэ.
TOTP болон уламжлалт арга замыг бүрэн бүү хаа: Passkey-г цорын ганц хувилбар болгон тулгах нь хэрэглэгчийг тодорхой нэг клауд эзэмшигчид уяж өгдөг. 2FA Authenticator аппуудыг (TOTP) нөөц хувилбар болгон үлдээх нь дижитал тусгаар тогтнолыг хадгалах хамгийн эрүүл арга зам хэвээр байна.

Дүгнэлт

Passkey нь хэрэглэгчдийг фишинг халдлагаас хамгаалах маш хүчирхэг криптограф шийдэл мөн боловч түүнийг хэрэгжүүлж буй хэлбэр нь "Big Tech-ийн дижитал хашаа"-г өндөрлөх хэрэгсэл болох эрсдэлтэй байна. Системийн архитекторууд, backend хөгжүүлэгчид бид шинэ трендийг сохроор дагалдалгүй, нээлттэй стандартынхаа параметр бүрийг ухамсартайгаар сонгох нь нээлттэй интернэтийн ирээдүйд нэн чухал билээ.

Эх сурвалж: Hacker News (Item #50048312), nonfunctional.substack.com