WebAuthn Geçiş Anahtarı QR Kodları ve Bluetooth: Hibrit Taşıma

Geçiş anahtarları, kullanıcı kimlik doğrulamasında standart olarak parolaların yerini giderek daha fazla alıyor. Geleneksel parolaların aksine, geçiş anahtarları bir ekosisteme bağlıdır (ör. iCloud Anahtar Zinciri, Google Şifre Yöneticisi, Windows Hello veya 1Password ya da Dashlane gibi bir şifre yöneticisi); ezberlenmek için değil, cihazlarınızla sorunsuz bir şekilde entegre olacak şekilde tasarlanmışlardır ve kutudan çıktığı gibi harika bir kullanıcı deneyimi sunarlar.

Kişisel bilgisayarınızdan uzakta, belki bir halka açık terminalde veya bir arkadaşınızın dizüstü bilgisayarında olduğunuzu ve geçiş anahtarıyla korunan hesabınıza giriş yapmanız gerektiğini düşünün. Bu senaryo oldukça yaygındır ve güvenli ancak kullanışlı bir kimlik doğrulama yöntemi gerektirir. Ancak geçiş anahtarları söz konusu olduğunda, bu durumda geçiş anahtarları hemen kullanılamadığı için birçok kişi ne yapacağını bilemez. Böyle bir durumda size yardımcı olacak geçiş anahtarı özelliklerinden biri, QR kodları ve Bluetooth teknolojisi aracılığıyla geçiş anahtarlarınızı birden fazla cihazda kullanabilme yeteneğidir. Bu süreç, WebAuthn spesifikasyonunda resmi olarak hibrit taşıma olarak bilinir (spesifikasyonun önceki sürümlerinde bulut destekli Düşük Enerjili Bluetooth caBLE olarak anılırdı).

Süreç basittir: geçiş anahtarlarınızın saklandığı ve fotoğraf çekebilen bir cihaza ihtiyacınız var, yani büyük olasılıkla bir akıllı telefon veya tablet. Bu cihaz, yalnızca o kimlik doğrulama işlemi için yeni cihaza bir tünel açabilir. Bu, yalnızca geçiş anahtarınızın bütünlüğünü korumakla kalmaz, aynı zamanda nerede olursanız olun veya kimin cihazını kullanmak isterseniz isteyin, yeni cihazlarda hesabınıza erişim sağlanabilmesini de temin eder.

Ancak, bu geçiş anahtarları platformlar arası kimlik doğrulama özelliği, hem kullanışlılığı hem de teknik uygulaması açısından yanlış anlamalar ve kafa karışıklığı ile çevrilidir. Bu, yakın zamanda yerel bir BT güvenliği buluşmasına katıldığımda tekrar fark ettiğim bir şeydi. Bu makale aracılığıyla, karmaşıklıkları çözmeyi ve bu platformlar arası geçiş anahtarı kimlik doğrulama (hibrit taşıma) akışını uygulamak için öneriler sunmayı amaçlıyoruz, böylece kullanıcılarınıza en iyi giriş deneyimini sağlayabilirsiniz.

Geçiş anahtarları, geleneksel parolayı daha güvenli ve kullanışlı bir kriptografik açık-özel anahtar çiftiyle değiştiren bir kullanıcı kimlik doğrulama biçimidir. Bu anahtar çifti her kullanıcıya özgüdür ve karmaşık parolaları hatırlama zahmeti olmadan kimliği doğrulamak için kullanılır.

Geçiş anahtarlarının avantajları, parola öncüllerine kıyasla çok sayıdadır. Sahte bir web sitesiyle paylaşılmaları için kandırılamadıklarından, oltalama riskini önemli ölçüde azaltırlar. Dahası, parolaları kırmak için kullanılan yaygın yöntemler olan kaba kuvvet ve sözlük saldırılarına karşı bağışıktırlar. Geçiş anahtarları ayrıca daha kullanıcı dostudur ve uzun bir parola listesini hatırlama veya yönetme ihtiyacını ortadan kaldırır.

Geçiş anahtarları, Google Şifre Yöneticisi veya Apple iCloud Anahtar Zinciri (Microsoft, Windows Hello ile yakında takip edecek) gibi bulut hesaplarında veya 1Password veya Dashlane gibi modern geçiş anahtarına hazır şifre yöneticilerinde saklananlar gibi senkronize edilir. Ancak, varsayılan olarak geçiş anahtarlarının ekosisteme ve ilgili bulut hesabı senkronizasyonuna bağlı olduğunu bilmek önemlidir. İşletim sistemleri özel anahtarları dışa aktarmak için bir arayüz sağlamaz ve çoğu cihazda, özel anahtarlara herhangi bir erişimi önlemek için ek güvenlik önlemleri sağlayan bir donanım bileşeni bulunur; örneğin iOS cihazlarındaki güvenli bölge veya Windows cihazlarındaki güvenilir platform modülü (TPM). Yalnızca işletim sistemi sağlayıcısı, geçiş anahtarlarını şifreli bir şekilde diğer cihazlara senkronize edebilir (sonuçta kullanıcının biyometrisi, parolası veya PIN'i ile korunur). Özel anahtarlar yalnızca parola / PIN kullanılarak geri yüklenebilir ve şifresi çözülebilir ve bulut hesabına çok fazla başarısız giriş denemesi olması durumunda yok edilir (ör. Apple, bulut arka ucunda ayrıcalıklı bir konumdan bile kaba kuvvet saldırılarını önlemek için bir hız sınırı uygular; Google da aynısını yapar).

Bu doğal tasarım, geçiş anahtarları açıklandığı gibi senkronize edilmezse, yeni bir cihazda geçiş anahtarlarınıza erişmenin bir zorluk teşkil edebileceği anlamına gelir. Geçiş anahtarı platformlar arası kimlik doğrulaması (hibrit taşıma) için QR kodu ve Bluetooth yakınlık kontrolü ile hibrit taşıma yönteminin var olmasının nedeni tam olarak budur. Geçiş anahtarlarınızı bir bulut hesabı / şifre yöneticisi aracılığıyla senkronize etme ihtiyacı olmadan cihazlar arasında güvenli bir köprü sağlar, böylece geçiş anahtarlarının yalnızca kullanıcıda kalabileceği ilkesini korur.

Platformlar arası geçiş anahtarı kimlik doğrulamasını (hibrit taşıma) kullanmak, bir hesaba yalnızca geçiş anahtarlarıyla erişildiğinde cihazlar arası sorunların üstesinden gelmeye yardımcı olur. Tüm geçiş anahtarları bulut hesaplarında veya şifre yöneticilerinde senkronize edilmediğinden, özellikle yeni bir cihaza geçerken veya paylaşılan bir cihazda erişim gerektiğinde, cihazlar arasında geçiş anahtarlarına erişmek için güvenilir bir yönteme olan ihtiyaç kritik hale gelir.

Geçiş anahtarı platformlar arası kimlik doğrulamasını (hibrit taşıma) kolaylaştırmak için aşağıdaki donanım gereksinimleri vardır:

• WebAuthn Desteği: Cihazlar WebAuthn desteklemelidir. En son geçiş anahtarı veri analizimize göre bu, cihazların %99'unda zaten mevcuttur.
• QR Kodu Tarama için Kamera: Cihazların QR kodlarını tarayabilen bir kameraya ihtiyacı olacaktır. Çoğu modern akıllı telefon, bu işlevselliğe sahip kameralarla donatılmıştır. Dahası, kameranın yerleşik QR tarama yeteneklerine sahip olması gerekir (çoğu cihazda kutudan çıktığı gibi mevcuttur). Kameranız desteklemiyorsa, çevrimiçi bir QR tarayıcı da iyi bir seçenektir. Aksi takdirde, bir QR kodu uygulaması yüklemek de uygundur.
• Bluetooth Yeteneği: Bulut destekli Düşük Enerjili Bluetooth (caBLE), cihazlar arasında yakınlık tabanlı güvenli bir bağlantı kurmak için kullanılır. Aranacak sürümler, WebAuthn için caBLE uzantısını etkinleştiren Bluetooth 4.0 veya daha yükseğidir.
• İnternet Bağlantısı: Her iki cihazda da kararlı bir internet bağlantısı bulunmalıdır, çünkü değişim, gerçek zamanlı veri aktarımı gerektiren doğrulama adımlarını gerçekleştirmek için bir tünel açmayı içerir.

Yazılım açısından aşağıdaki gereksinimler mevcuttur:

• WebAuthn Sunucu Yapılandırması: Açıkçası, açık anahtarları yöneten bir WebAuthn sunucusuna sahip olmanız gerekir. Bu aynı zamanda kullanıcının hesabının birden fazla doğrulayıcıyla ilişkilendirilmesini sağlamayı ve sunucuyu kimlik doğrulama seremonisini başlatacak şekilde ayarlamayı da içerir.
• Web Bluetooth API: Bluetooth yakınlık kontrolü için, cihazın Bluetooth yeteneklerini bir tarayıcıdan tetikleyen Web Bluetooth API'sine erişmeniz gerekecektir.
• İşletim Sistemi Gereksinimleri: Mart 2025 itibarıyla farklı işletim sistemleri için Cihazlar Arası Kimlik Doğrulama desteği hakkında lütfen aşağıdaki tabloya bakın. Doğrulayıcı, cihazın bir geçiş anahtarı tutan cihaz olarak hizmet edebileceği anlamına gelir (bizim senaryomuzda akıllı telefon). İstemci, QR kodunu oluşturan ve kullanıcının giriş yapmaya çalıştığı cihaz anlamına gelir (bizim senaryomuzda masaüstü):

Kaynak: passkeys.dev

Geçiş anahtarı platformlar arası kimlik doğrulamasını (hibrit taşıma) QR kodu aracılığıyla kullanma süreci aşağıdaki gibi görünür:

Geçiş anahtarı platformlar arası kimlik doğrulaması (hibrit taşıma) için QR kodu, bir kullanıcı kayıtlı geçiş anahtarının bulunmadığı bir cihazda bir hizmete erişmeye çalıştığında, ancak hizmet kullanıcının bir geçiş anahtarına sahip olması gerektiğini bildiğinde oluşturulur. Genellikle, kimlik doğrulama arayüzünde bir QR kodu tara düğmesi veya benzer bir eylem çağrısı sağlanır.

Kullanıcı isteği üzerine, cihaz bir QR kodu oluşturulmasını başlatır. Bu QR kodu, benzersiz, zamana duyarlı bir oturum tanımlayıcısı kodlar. Bu tanımlayıcı, kimlik doğrulama sunucusunun kimlik doğrulama işleminin tamamlanmasını beklerken geçici olarak sürdürdüğü bir oturuma bağlıdır.

Kullanıcı, geçiş anahtarının bulunduğu bir cihazla bu QR kodunu tarar. Güvenlik önlemleri şunları içerir:

• Tek kullanımlık: QR kodu içindeki oturum tanımlayıcısı tek bir kullanım için geçerlidir ve tekrar saldırılarını önler.
• Şifreleme: QR kodu içindeki tüm veriler şifrelenir, bu da ele geçirilen herhangi bir iletişimin yetkisiz taraflarca deşifre edilememesini sağlar.

Okunan QR kodu, FIDO şemasına sahip belirli bir URI içerir, örn.: FIDO:/07824133892604070278923969472008301099476228966286113051476699183587 6383562063181103169246410435938367110394959927031730060360967994421 343201235185697538107096654083332

QR kodunun taranması, kullanıcının ikinci cihazını (ör. akıllı telefon veya tablet) FIDO URI'sini yorumlamaya ve kimlik doğrulama sunucusuyla iletişim kurmaya tetikler, bu da kullanıcının yeni bir cihaz (ör. arkadaşının dizüstü bilgisayarı) aracılığıyla kimlik doğrulamaya çalıştığına dair bir sinyal gönderir. Bu eylem, sunucunun bu kimlik doğrulama denemesine özgü bir kriptografik sınama oluşturmasını ister.

Sınama, kullanıcının geçiş anahtarının saklandığı ikinci cihazına (ör. akıllı telefon veya tablet) geri gönderilir. Cihaz daha sonra geçiş anahtarıyla ilişkili özel anahtarı kullanarak bir dijital imza oluşturur, özel anahtar cihazdan (ör. akıllı telefon veya tablet) hiç ayrılmaz. İmzalanan sınama (imza) daha sonra internet üzerinden güvenli, şifreli bir tünel aracılığıyla sunucuya geri gönderilir, bu da kimlik doğrulama denemesinin bütünlüğünü ve kaynağını doğrular.

Sunucu, kullanıcının hesabıyla zaten ilişkili olan ilgili açık anahtarı kullanarak imzayı doğrular. Başarılı doğrulamanın ardından sunucu kimlik doğrulamasını onaylar ve kullanıcının yeni cihazda hizmete erişmesine izin verir.

Dikkate alınması gereken bazı önemli gizlilik ve güvenlik hususları:

• Bluetooth Veri Değişimi Yok, Tamamen İnternet: Bu QR kodu tabanlı geçiş anahtarı platformlar arası kimlik doğrulamasında (hibrit taşıma), Bluetooth'un veri değişiminde yer almadığını belirtmek önemlidir. Bu süreç, cihazlar ve sunucu arasında şifrelenmiş verilerin iletimi için tamamen bir İnternet bağlantısına dayanır. Ancak, Bluetooth iki cihazın yakınlık kontrolü için kullanılır.
• Özel Anahtarlar Cihazdan Ayrılmaz: Bu süreç boyunca, kullanıcının özel anahtarları cihazlarında güvenli bir şekilde kalır.
• Hassas Veri İfşası Yok: Kimlik doğrulama işlemi sırasında hiçbir hassas geçiş anahtarı bilgisi veya özel anahtar aktarılmaz veya ifşa edilmez.
• Asimetrik Kriptografi: Sınama-yanıt mekanizması, gönderilenlerin yalnızca yeniden kullanılamayan, yetkisiz erişim için istismar edilemeyecek sınamaların imzalı sürümleri olmasını sağlar.

Bu teknik ve güvenlik protokollerine bağlı kalarak, geçiş anahtarı platformlar arası kimlik doğrulaması (hibrit taşıma) için QR kodu yöntemi, kullanıcıların yeni cihazlarda kimliklerini doğrulamaları için uygun bir yol sağlarken yüksek bir güvenlik standardını korur.

QR kodu tarama sürecinin yanı sıra, Bluetooth (caBLE) aracılığıyla bir yakınlık kontrolü de vardır. İstemcinin ve doğrulayıcının fiziksel olarak birbirine yakın olduğundan emin olmak, WebAuthn protokolünün en büyük faydalarından biridir. Bu sürecin iç işleyişi hakkında daha fazla bilgi aşağıda açıklanmaktadır:

Düşük Enerjili Bluetooth (BLE), kısa menzilli veri alışverişi için tasarlanmış bir kablosuz iletişim teknolojisidir. Kimlik doğrulama işlemi sırasında cihazların fiziksel yakınlığını doğrulamada önemli bir rol oynar.

caBLE, BLE kullanarak cihazlar arasında kimlik doğrulama bilgilerinin güvenli bir şekilde aktarılmasını kolaylaştıran bir protokoldür. Geçiş anahtarı platformlar arası kimlik doğrulaması (hibrit taşıma) için caBLE kullanıldığında, geçiş anahtarını tutan cihaz, istekte bulunan cihazın yakınlığını BLE sinyalleri aracılığıyla onaylar. Yakınlık doğrulandıktan sonra, kimlik doğrulama süreci güvenli, yerel iletişim için BLE'den yararlanarak ilerler.

Bu yöntem genellikle daha az doğrudan kullanıcı etkileşimi gerektirdiğinden kullanıcı deneyimi iyileştirilir; fiziksel olarak yakın olan cihazlar birbirlerini otomatik olarak algılar. Güvenlik açısından, caBLE önemli bir avantaj sunar - kimlik doğrulama işleminin yalnızca iki cihaz birbirine yakın olduğunda gerçekleştirilmesini sağlar, bu da uzaktaki saldırganların kimlik doğrulama sürecini başlatmasını önler.

Kötü amaçlı bir siteye yönlendiren bir QR kodu aldığınızı hayal edin. Kimlik doğrulama bu QR kodu aracılığıyla gerçekleştirilirse, oturumun veya çerezin ele geçirilme riski vardır. BLE, görsel bir taramaya değil, cihazların fiziksel varlığına dayanarak bu sorunu aşar. Bu yakınlık kontrolü, yakınlık kontrolü internet veya görsel bir ortam üzerinden gerçekleşmediği için ortadaki adam saldırıları riskini en aza indirir.

Diğer yöntemlerin aksine, caBLE aslında geçiş anahtarları gibi kimlik doğrulama verilerini değiştirmez. Bunun yerine, cihazların fiziksel olarak yakın olduğunu belirlemek için BLE'yi bir onay kanalı olarak kullanır. Bu kontrol, BLE yakınlığının faktörlerden biri olduğu bir çok faktörlü kimlik doğrulama sürecinin bir parçası olarak tasarlanmıştır, bu da diğer faktörler tehlikeye atılsa bile fiziksel yakınlık olmadan erişim verilmemesini sağlar.

caBLE protokolünü entegre ederek, geliştiriciler kimlik doğrulama sürecinin genel güvenliğini artıran, geçiş anahtarı platformlar arası kimlik doğrulaması (hibrit taşıma) için güvenli ve kullanıcı dostu bir yöntem sunabilirler. Yakınlık kontrolü, kullanıcılar için basit olan ancak belirli türdeki karmaşık siber saldırılara karşı etkili bir şekilde koruma sağlayan ek bir koruma katmanı ekler.

Bu geçiş anahtarı platformlar arası kimlik doğrulama (hibrit taşıma) yönteminin aşağıdaki faydaları mevcuttur:

QR kodu ve Bluetooth (hibrit taşıma) aracılığıyla platformlar arası geçiş anahtarı kimlik doğrulaması, hiç bir olasılık sunmamaya kıyasla platformlar arası senaryolarda kullanıcı deneyimini iyileştirmenin bir yoludur. Ancak, kullanıcı akışı çoğu kullanıcı için tamamen yenidir ve birçok teknik olmayan kullanıcının bu akışla ilk karşılaştıklarında ne olduğunu anlamasını beklemiyoruz. QR kodu akışını tanıtmanın tek benzerliği, QR kodlarının kullanıldığı WhatsApp Web veya Discord gibi giriş akışları olabilir (burada işlevsellik farklıdır). Dolayısıyla, analiz edilen platformlar arası geçiş anahtarı kimlik doğrulama süreci QR kodu / Bluetooth (hibrit taşıma) aracılığıyla, platformlar arası senaryoda kullanıcı çabasını en aza indirir, çünkü manuel olarak herhangi bir kimlik bilgisi girmeye gerek yoktur, ancak yine de genel akış çoğu kullanıcı için bilinmemektedir.

Geçiş anahtarı platformlar arası kimlik doğrulamasının (hibrit taşıma) güvenliği, gelişmiş kriptografik tekniklerle güçlendirilmiştir. Kimlik doğrulama için bir QR kodu tarandığında veya bir Bluetooth bağlantısı yapıldığında, kriptografik sınamalar ve yanıtlar, yalnızca hedeflenen cihazın kimlik doğrulama sürecini başarıyla tamamlayabilmesini sağlar.

Bluetooth aracılığıyla yapılan yakınlık kontrolleri, kimlik doğrulama denemesinin ikincil cihaza fiziksel erişimi olan biri tarafından yapıldığını doğrulayarak ek bir güvenlik katmanı ekler.

Platformlar arası kimlik doğrulama (hibrit taşıma) süreci sırasında, geçiş anahtarları asla aracı cihazlarda veya sunucularda geçici olarak saklanmaz, bu da aktarım işlemi sırasında geçiş anahtarlarının ele geçirilmesi veya sızdırılması riskini önler. Kimlik doğrulama gerçek zamanlı olarak gerçekleşir ve geçiş anahtarı kullanıcının birincil cihazına bağlı kalarak bütünlüğünü korur.

QR kodu ve Bluetooth kimlik doğrulama yöntemleri, doğası gereği oltalama saldırılarına karşı koruma sağlar. Kullanıcıların, kimlik doğrulama süreci kullanıcının güvendiği cihazlara özgü fiziksel eylemler gerektirdiğinden, kötü amaçlı bir site için bir geçiş anahtarı sağlamaya kandırılma olasılığı daha düşüktür.

Bir QR kodunu tarama veya Bluetooth ile bağlanma süreci genellikle güvenilir bir ortamda gerçekleşir, bu da kullanıcıların kimlik bilgilerini istemeden tehlikeye atma olasılığını azaltır.

Bu geçiş anahtarı platformlar arası kimlik doğrulama (hibrit taşıma) yönteminin aşağıdaki dezavantajları mevcuttur:

Herhangi bir yeni teknolojiyi tanıtmak, özellikle kullanıcılar teknolojiye yatkın değilse, kullanıcı kafa karışıklığına yol açabilir. QR kodu ve Bluetooth (hibrit taşıma) aracılığıyla geçiş anahtarı platformlar arası kimlik doğrulaması, geleneksel kimlik doğrulama yöntemlerinden önemli bir geçiştir ve bazı kullanıcılar yeni süreci kavramakta zorlanabilir, bu da potansiyel olarak daha yavaş bir benimseme oranına yol açabilir. Ancak, kullanıcıların zamanla buna alışmasını bekliyoruz, bu nedenle değişiklik başlangıçta daha zor olabilir ve zamanla daha sorunsuz ve daha kabul görmüş hale gelecektir.

Geçiş anahtarı platformlar arası kimlik doğrulamasının (hibrit taşıma) başarısı, büyük ölçüde kullanıcının cihazının QR kodlarını tarayabilen bir kamera ve Bluetooth işlevselliği gibi gerekli yeteneklere sahip olmasına bağlıdır. Bu özelliklerden yoksun eski cihazlara sahip kullanıcılar, geçiş anahtarı platformlar arası kimlik doğrulamasından (hibrit taşıma) yararlanamayacak ve donanım sınırlamalarına dayalı bir dijital uçurum yaratacaktır.

Kullanıcı davranışı öngörülemez olabilir ve kullanıcıların bir QR kodunu taramak veya Bluetooth'u etkinleştirmek gibi belirli eylemleri gerçekleştirmesine güvenmek, kullanıcı hatalarına yol açabilir. Örneğin, Bluetooth bazen eşleştirme sorunları, keşif sorunları ve güvenli işlemler için kablosuz teknolojilere genel kullanıcı güvensizliği nedeniyle bir kullanıcı deneyimi zorluğu olarak görülebilir.

Geliştiriciler, en son kimlik doğrulama yöntemlerini desteklemek için sistemleri sürekli olarak güncelleme ve bakım yapma göreviyle karşı karşıyadır. Geçiş anahtarı platformlar arası kimlik doğrulamasını (hibrit taşıma) mevcut sistemlere entegre etmek, geliştiricilerin yeni standartlardan haberdar olmalarını, yeni API'leri benimsemelerini ve geriye dönük uyumluluğu sağlamalarını gerektirir, bu da kaynak yoğun ve zaman alıcı olabilir.

iCloud Anahtar Zinciri veya bir şifre yöneticisi gibi senkronize bir bulut hesabı kullanılmıyorsa, her yeni cihaz veya sonraki giriş isteği için yeni bir geçiş anahtarı oluşturulması gerekir. Bu, kullanıcı deneyimine karmaşıklık katabilir ve kullanıcılar sürece aşina değilse veya sezgisel hale getirilmemişse hayal kırıklığı yaratabilir.

Geçiş anahtarı platformlar arası kimlik doğrulaması (hibrit taşıma) gibi yeni güvenlik yöntemleri uygularken doğal bir kullanıcı eğitimi ihtiyacı vardır. Kullanıcıların QR kodlarını ve Bluetooth'u güvenli bir şekilde nasıl kullanacaklarını anlamalarını sağlamak, net iletişim ve muhtemelen kapsamlı müşteri desteği gerektirir.

QR kodu ve Bluetooth (hibrit taşıma) aracılığıyla geçiş anahtarı platformlar arası kimlik doğrulaması, kimlik doğrulama teknolojisinde önemli bir ilerleme sunsa da, bu potansiyel dezavantajlar, kullanıcı dostu tasarım, sağlam destek sistemleri ve geleneksel yöntemlerden yenilikçi olanlara kademeli, iyi iletişim kurulmuş bir geçiş ihtiyacını vurgulamaktadır. Her teknolojik değişimde olduğu gibi, yeniliğin faydalarını zorluklarıyla dengelemek, başarılı uygulama ve yaygın kullanıcı kabulünün anahtarı olacaktır.

Bir feragatname olarak: aşağıdaki testte donanım güvenlik anahtarlarını (ör. YubiKey'ler) göz ardı ediyoruz ve yalnızca cihazlara yerleşik olan platform doğrulayıcılarını kullanıyoruz (ör. Face ID, Touch ID, Windows Hello). Donanım güvenlik anahtarları (ör. YubiKey) durumunda, transports için değerler örneğin usb veya nfc olacaktır.

Davranışı test etmek için aşağıdaki cihaz / tarayıcı kombinasyonlarını ve Passkeys Hata Ayıklayıcısını kullanıyoruz. Android, platformlar arası kimlik doğrulama (hibrit taşıma) istemcisi olarak hizmet veremediği için dikkate alınmamıştır (yukarıdaki tabloya bakın):

Davranışı test etmek için, her kombinasyon için aşağıdaki özelliklere sahip yeni bir geçiş anahtarı oluşturuyoruz:

• userName: alex muller (bu testte etkisi yok)
• authenticatorAttachment: platform (çünkü YubiKey gibi donanım güvenlik anahtarlarını hariç tutmak istiyoruz)
• residentKey: preferred (bu testte etkisi yok)
• userVerification: preferred (bu testte etkisi yok)
• attestation: none (bu testte etkisi yok)
• hints: empty (aşağıdaki açıklamaya bakın)
• usePRF: no (bu testte etkisi yok)

Geçiş anahtarının başarılı bir şekilde oluşturulmasından sonra, WebAuthn sunucusu [allowCredentials](/glossary/allowcredentials) özelliğindeki girdiyi değiştiriyor ve bir giriş isteği başlatıyoruz. Geçiş anahtarını oluşturduğumuz cihazda silinmiş bir geçiş anahtarını taklit etmek istiyoruz, böylece cihaz / tarayıcı QR kodu / Bluetooth aracılığıyla bir geçiş anahtarı sağlayabilecek başka bir cihaz arar. Bu nedenle, kimlik bilgisi ID'sini değiştiriyor ve eşleşmenin başarısız olması için CHANGED-ID değerini atıyoruz. Ayrıca, [allowCredentials](/glossary/allowcredentials) içindeki bir WebAuthn kimlik bilgisinin transports özelliğini değiştiriyor ve her cihaz / tarayıcı kombinasyonu için aşağıdaki değerleri atıyoruz:

1. transports: [internal, hybrid]: Geçiş anahtarları platform doğrulayıcısından (ör. Face ID, Touch ID, Windows Hello) veya platformlar arası kimlik doğrulama yoluyla kullanılabilir
2. transports: [internal]: Geçiş anahtarları platform doğrulayıcısından (ör. Face ID, Touch ID, Windows Hello) kullanılabilir
3. transports özelliği ayarlanmadı: herhangi bir kısıtlama getirmeyen varsayılan davranış

WebAuthn test sitesinde, kullanıcı aracıları için yeni WebAuthn Seviye 3 özelliği olan hints de sağlanmaktadır. Bu özellik, dayanan tarafın giriş isteğinin en kullanıcı dostu şekilde nasıl tamamlanabileceği konusunda belirli varsayımları varsa kullanıcı deneyimini iyileştirebilir. Bu testte, henüz yaygın olarak kullanılmadığı için bu özelliği göz ardı ettik. Daha fazla ayrıntı için lütfen spesifikasyonlara göz atın.

Beklendiği gibi, yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız ve başka bir cihazdaki geçiş anahtarını kullanmanız öneriliyor (çünkü sistem bu kullanıcı için bir geçiş anahtarı olduğunu biliyor).

Oldukça kafa karıştırıcı bir şekilde, yalnızca dahili kimlik bilgilerine izin vermemize rağmen QR kodu burada da görüntüleniyor. Bu davranış için geçerli bir neden bulamadık.

Yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız veya bir donanım güvenlik anahtarı (ör. YubiKey) / platformlar arası doğrulayıcı / gezici doğrulayıcı kullanmanız öneriliyor.

Bir nedenden ötürü, pencerenin bazı kısımları yüklü dillerden biri olan Almanca olarak görünüyor.

Beklendiği gibi, tüm geçiş anahtarı kimlik doğrulama biçimlerine izin verilir: Windows Hello aracılığıyla, QR kodu aracılığıyla, bilinen cihazlar aracılığıyla ve donanım güvenlik anahtarları aracılığıyla.

Beklendiği gibi, yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız ve başka bir cihazdaki geçiş anahtarını kullanmanız öneriliyor (çünkü sistem bu kullanıcı için bir geçiş anahtarı olduğunu biliyor).

Oldukça kafa karıştırıcı bir şekilde, yalnızca dahili kimlik bilgilerine izin vermemize rağmen QR kodu burada da görüntüleniyor. Bu davranış için geçerli bir neden bulamadık.

Yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız veya bir donanım güvenlik anahtarı (ör. YubiKey) / platformlar arası doğrulayıcı / gezici doğrulayıcı kullanmanız öneriliyor.

Bir nedenden ötürü, pencerenin bazı kısımları yüklü dillerden biri olan Almanca olarak görünüyor.

Beklendiği gibi, tüm geçiş anahtarı kimlik doğrulama biçimlerine izin verilir: Windows Hello aracılığıyla, QR kodu aracılığıyla, bilinen cihazlar aracılığıyla ve donanım güvenlik anahtarları aracılığıyla.

Geçiş anahtarını oluştururken aşağıdaki hatayı aldık (yine de bir geçiş anahtarı oluşturuldu):

hata: TypeError: 'toJSON' PublicKeyCredential arayüzünü uygulamayan bir nesne üzerinde çağrıldı.

Beklendiği gibi, yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız ve başka bir cihazdaki geçiş anahtarını kullanmanız öneriliyor (çünkü sistem bu kullanıcı için bir geçiş anahtarı olduğunu biliyor).

Oldukça kafa karıştırıcı bir şekilde, yalnızca dahili kimlik bilgilerine izin vermemize rağmen QR kodu burada da görüntüleniyor. Bu davranış için geçerli bir neden bulamadık.

Yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız veya bir donanım güvenlik anahtarı (ör. YubiKey) / platformlar arası doğrulayıcı / gezici doğrulayıcı kullanmanız öneriliyor.

Bir nedenden ötürü, pencerenin bazı kısımları yüklü dillerden biri olan Almanca olarak görünüyor.

Beklendiği gibi, tüm geçiş anahtarı kimlik doğrulama biçimlerine izin verilir: Windows Hello aracılığıyla, QR kodu aracılığıyla, bilinen cihazlar aracılığıyla ve donanım güvenlik anahtarları aracılığıyla.

Beklendiği gibi, yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız ve başka bir cihazdaki geçiş anahtarını kullanmanız öneriliyor (çünkü sistem bu kullanıcı için bir geçiş anahtarı olduğunu biliyor). Ayrıca, oradan bir geçiş anahtarı kullanmak için bilinen cihazlardan birini doğrudan seçebilirsiniz.

Pencere, Windows'taki Chrome 119'daki karşılığından oldukça farklı.

Bu beklenen bir davranıştır, çünkü yalnızca dahili geçiş anahtarlarını kullanmaya izin veriyoruz ancak cihazda dahili bir kimlik bilgisi bulamıyoruz (hibrit geçiş anahtarlarını kullanmamıza izin verilmiyor). Geçiş anahtarı kimlik doğrulaması bu adımda başarısız olur ve gerçek hayattaki uygulamalarda bir yedek kimlik doğrulama yöntemi sağlamanız gerekir.

Yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız veya bir donanım güvenlik anahtarı (ör. YubiKey) / platformlar arası doğrulayıcı / gezici doğrulayıcı kullanmanız öneriliyor. Ayrıca, oradan bir geçiş anahtarı kullanmak için bilinen cihazlardan birini doğrudan seçebilirsiniz.

Pencere, Windows'taki Chrome 119'daki karşılığından oldukça farklı.

Beklendiği gibi, tüm geçiş anahtarı kimlik doğrulama biçimlerine izin verilir: Touch ID aracılığıyla, QR kodu aracılığıyla, bilinen cihazlar aracılığıyla ve donanım güvenlik anahtarları aracılığıyla.

Beklendiği gibi, yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız ve başka bir cihazdaki geçiş anahtarını kullanmanız öneriliyor (çünkü sistem bu kullanıcı için bir geçiş anahtarı olduğunu biliyor).

Oldukça kafa karıştırıcı bir şekilde, yalnızca dahili kimlik bilgilerine izin vermemize rağmen QR kodu burada da görüntüleniyor. Bu davranış için geçerli bir neden bulamadık.

Yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız veya bir donanım güvenlik anahtarı (ör. YubiKey) / platformlar arası doğrulayıcı / gezici doğrulayıcı kullanmanız öneriliyor.

Beklendiği gibi, çoğu geçiş anahtarı kimlik doğrulama biçimine izin verilir: Touch ID aracılığıyla, QR kodu aracılığıyla ve donanım güvenlik anahtarları aracılığıyla. Bir nedenden ötürü bilinen cihazlar görüntülenmiyor.

Beklendiği gibi, yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız ve başka bir cihazdaki geçiş anahtarını kullanmanız öneriliyor (çünkü sistem bu kullanıcı için bir geçiş anahtarı olduğunu biliyor).

Oldukça kafa karıştırıcı bir şekilde, yalnızca dahili kimlik bilgilerine izin vermemize rağmen QR kodu burada da görüntüleniyor. Bu davranış için geçerli bir neden bulamadık.

Yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız veya bir donanım güvenlik anahtarı (ör. YubiKey) / platformlar arası doğrulayıcı / gezici doğrulayıcı kullanmanız öneriliyor.

Beklendiği gibi, çoğu geçiş anahtarı kimlik doğrulama biçimine izin verilir: Face ID aracılığıyla, QR kodu aracılığıyla ve donanım güvenlik anahtarları aracılığıyla. Bir nedenden ötürü bilinen cihazlar görüntülenmiyor.

Beklendiği gibi, yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız ve başka bir cihazdaki geçiş anahtarını kullanmanız öneriliyor (çünkü sistem bu kullanıcı için bir geçiş anahtarı olduğunu biliyor).

Oldukça kafa karıştırıcı bir şekilde, yalnızca dahili kimlik bilgilerine izin vermemize rağmen QR kodu burada da görüntüleniyor. Bu davranış için geçerli bir neden bulamadık.

Yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız veya bir donanım güvenlik anahtarı (ör. YubiKey) / platformlar arası doğrulayıcı / gezici doğrulayıcı kullanmanız öneriliyor.

Beklendiği gibi, çoğu geçiş anahtarı kimlik doğrulama biçimine izin verilir: Face ID aracılığıyla, QR kodu aracılığıyla ve donanım güvenlik anahtarları aracılığıyla. Bir nedenden ötürü bilinen cihazlar görüntülenmiyor.

Aşağıda, Windows 10 cihazları için bir seviye daha ileri giderek, genel olarak bir Windows 10 makinesinde Bluetooth devre dışı bırakıldığında veya mevcut olmadığında davranışın nasıl göründüğünü analiz etmeye karar verdik. Özellikle eski masaüstü cihazlar için bu hala çok yaygın bir senaryodur, çünkü bu cihazlar genellikle bir Bluetooth modülüne sahip değildir, bu da QR kodu ve Bluetooth aracılığıyla platformlar arası kimlik doğrulamayı imkansız hale getirir.

8.8.1.1 transports: [internal, hybrid]

Beklendiği gibi, yerel bir geçiş anahtarı eşleşmiyor, bu nedenle başka bir cihazdaki geçiş anahtarını kullanmanız (sistem bu kullanıcı için bir geçiş anahtarı olduğunu bildiği için - ilk ekran görüntüsü) veya QR kodunu taramayı seçmeniz (ikinci ekran görüntüsü) önerilir.

8.8.1.2 transports: [internal]

Oldukça kafa karıştırıcı bir şekilde, kimlik bilgisi ID'sini değiştirmemize rağmen (yani aslında [allowCredentials](/glossary/allowcredentials) özelliğinde belirtilmediği için kimlik bilgisini bulamaması gerekir) Windows Hello PIN kodunuzu (veya cihazda ayarlanmışsa parmak izi / yüz taraması) girmeniz istenir. Ancak, Windows Hello PIN kodunu gönderdikten sonra bir hata atılır: "NotAllowedError: İşlem ya zaman aşımına uğradı ya da izin verilmedi. Bkz: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Kullanıcı açısından bu oldukça kafa karıştırıcı bir davranıştır ancak kullanıcının onayı olmadan kullanıcının geçiş anahtarları hakkında bilgi sağlayabileceği için mantıklıdır.

8.8.1.3 transports özelliği ayarlanmadı

Yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız veya bir donanım güvenlik anahtarı (ör. YubiKey) / platformlar arası doğrulayıcı / gezici doğrulayıcı kullanmanız önerilir.

8.8.1.4 Boş allowCredentials

Beklendiği gibi, tüm geçiş anahtarı kimlik doğrulama biçimlerine izin verilir: Windows Hello aracılığıyla, QR kodu aracılığıyla, bilinen cihazlar aracılığıyla ve donanım güvenlik anahtarları aracılığıyla.

8.8.2.1 transports: [internal, hybrid]

Bu, kullanıcılar için gerçekten kafa karıştırıcı bir mesajdır, çünkü ne yapmaları gerektiği ve nasıl kimlik doğrulaması yapabilecekleri açıkça belirtilmemiştir. Sahip oldukları tek seçenek "İptal"e tıklamaktır, bu da bu senaryoyu bir çıkmaza sokar.

8.8.2.2 transports: [internal]

Bu davranış, Bluetooth'un etkin olduğu durumla aynıdır. Kimlik bilgisi ID'sini değiştirmemize rağmen (yani aslında [allowCredentials](/glossary/allowcredentials) özelliğinde belirtilmediği için kimlik bilgisini bulamaması gerekir) kullanıcının Windows Hello PIN kodunu (veya cihazda ayarlanmışsa parmak izi / yüz taraması) girmesi istenmesi çok kafa karıştırıcıdır. Ancak, Windows Hello PIN kodunu gönderdikten sonra bir hata atılır: "NotAllowedError: İşlem ya zaman aşımına uğradı ya da izin verilmedi. Bkz: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Kullanıcı açısından bu oldukça kafa karıştırıcı bir davranıştır ancak kullanıcının onayı olmadan kullanıcının geçiş anahtarları hakkında bilgi sağlayabileceği için mantıklıdır.

8.8.2.3 transports özelliği ayarlanmadı

Yerel bir geçiş anahtarı eşleşmiyor, bu nedenle sahip olduğunuz tek seçenek bir donanım güvenlik anahtarı (ör. YubiKey) / platformlar arası doğrulayıcı / gezici doğrulayıcı kullanmaktır.

8.8.2.4 Boş allowCredentials

Geçiş anahtarı kimlik doğrulaması yalnızca Windows Hello ve donanım güvenlik anahtarları aracılığıyla mümkündür.

8.9.1.1 transports: [internal, hybrid]

Beklendiği gibi, yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız ve başka bir cihazdaki geçiş anahtarını kullanmanız önerilir (çünkü sistem bu kullanıcı için bir geçiş anahtarı olduğunu bilir).

8.9.1.2 transports: [internal]

Oldukça kafa karıştırıcı bir şekilde, kimlik bilgisi ID'sini değiştirmemize rağmen (yani aslında allowCredentials özelliğinde belirtilmediği için kimlik bilgisini bulamaması gerekir) Windows Hello PIN kodunuzu (veya cihazda ayarlanmışsa parmak izi / yüz taraması) girmeniz istenir. Ancak, Windows Hello PIN kodunu gönderdikten sonra bir hata atılır: "NotAllowedError: İşlem ya zaman aşımına uğradı ya da izin verilmedi. Bkz: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Kullanıcı açısından bu oldukça kafa karıştırıcı bir davranıştır ancak kullanıcının onayı olmadan kullanıcının geçiş anahtarları hakkında bilgi sağlayabileceği için mantıklıdır.

8.9.1.3 transports özelliği ayarlanmadı

Yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız veya bir donanım güvenlik anahtarı (ör. YubiKey) / platformlar arası doğrulayıcı / gezici doğrulayıcı kullanmanız önerilir.

8.9.1.4 Boş allowCredentials

Beklendiği gibi, tüm geçiş anahtarı kimlik doğrulama biçimlerine izin verilir: Windows Hello aracılığıyla, QR kodu aracılığıyla ve donanım güvenlik anahtarları aracılığıyla. Bir nedenden ötürü, bilinen cihazlar görüntülenmiyor.

8.9.2.1 transports: [internal, hybrid]

Bu, kullanıcılar için gerçekten kafa karıştırıcı bir mesajdır, çünkü ne yapmaları gerektiği ve nasıl kimlik doğrulaması yapabilecekleri açıkça belirtilmemiştir. Sahip oldukları tek seçenek "İptal"e tıklamaktır, bu da bu senaryoyu bir çıkmaza sokar.

8.9.2.2 transports: [internal]

Bu davranış, Bluetooth'un etkin olduğu durumla aynıdır. Kimlik bilgisi ID'sini değiştirmemize rağmen (yani aslında allowCredentials özelliğinde belirtilmediği için kimlik bilgisini bulamaması gerekir) kullanıcının Windows Hello PIN kodunu (veya cihazda ayarlanmışsa parmak izi / yüz taraması) girmesi istenmesi çok kafa karıştırıcıdır. Ancak, Windows Hello PIN kodunu gönderdikten sonra bir hata atılır: "NotAllowedError: İşlem ya zaman aşımına uğradı ya da izin verilmedi. Bkz: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Kullanıcı açısından bu oldukça kafa karıştırıcı bir davranıştır ancak kullanıcının onayı olmadan kullanıcının geçiş anahtarları hakkında bilgi sağlayabileceği için mantıklıdır.

8.9.2.3 transports özelliği ayarlanmadı

Yerel bir geçiş anahtarı eşleşmiyor, bu nedenle sahip olduğunuz tek seçenek bir donanım güvenlik anahtarı (ör. YubiKey) / platformlar arası doğrulayıcı / gezici doğrulayıcı kullanmaktır.

8.9.2.4 Boş allowCredentials

Geçiş anahtarı kimlik doğrulaması yalnızca Windows Hello ve donanım güvenlik anahtarları aracılığıyla mümkündür.

8.10.1.1 transports: [internal, hybrid]

Beklendiği gibi, yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız ve başka bir cihazdaki geçiş anahtarını kullanmanız önerilir (çünkü sistem bu kullanıcı için bir geçiş anahtarı olduğunu bilir).

8.10.1.2 transports: [internal]

Oldukça kafa karıştırıcı bir şekilde, kimlik bilgisi ID'sini değiştirmemize rağmen (yani aslında allowCredentials özelliğinde belirtilmediği için kimlik bilgisini bulamaması gerekir) Windows Hello PIN kodunuzu (veya cihazda ayarlanmışsa parmak izi / yüz taraması) girmeniz istenir. Ancak, Windows Hello PIN kodunu gönderdikten sonra bir hata atılır: "NotAllowedError: İşlem ya zaman aşımına uğradı ya da izin verilmedi. Bkz: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Kullanıcı açısından bu oldukça kafa karıştırıcı bir davranıştır ancak kullanıcının onayı olmadan kullanıcının geçiş anahtarları hakkında bilgi sağlayabileceği için mantıklıdır.

8.10.1.3 transports özelliği ayarlanmadı

Yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız veya bir donanım güvenlik anahtarı (ör. YubiKey) / platformlar arası doğrulayıcı / gezici doğrulayıcı kullanmanız önerilir.

8.10.1.4 Boş allowCredentials

Beklendiği gibi, tüm geçiş anahtarı kimlik doğrulama biçimlerine izin verilir: Windows Hello aracılığıyla, QR kodu aracılığıyla ve donanım güvenlik anahtarları aracılığıyla. Bir nedenden ötürü, bilinen cihazlar görüntülenmiyor.

8.10.2.1 transports: [internal, hybrid]

Bu, kullanıcılar için gerçekten kafa karıştırıcı bir mesajdır, çünkü ne yapmaları gerektiği ve nasıl kimlik doğrulaması yapabilecekleri açıkça belirtilmemiştir. Sahip oldukları tek seçenek "İptal"e tıklamaktır, bu da bu senaryoyu bir çıkmaza sokar. Bir nedenden ötürü, Windows Güvenliği penceresinin bazı kısımları da Almanca (bu cihazda yüklü ikinci bir dil) olarak görüntülenir.

8.10.2.2 transports: [internal]

Bu davranış, Bluetooth'un etkin olduğu durumla aynıdır. Kimlik bilgisi ID'sini değiştirmemize rağmen (yani aslında allowCredentials özelliğinde belirtilmediği için kimlik bilgisini bulamaması gerekir) kullanıcının Windows Hello PIN kodunu (veya cihazda ayarlanmışsa parmak izi / yüz taraması) girmesi istenmesi çok kafa karıştırıcıdır. Ancak, Windows Hello PIN kodunu gönderdikten sonra bir hata atılır: "NotAllowedError: İşlem ya zaman aşımına uğradı ya da izin verilmedi. Bkz: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Kullanıcı açısından bu oldukça kafa karıştırıcı bir davranıştır ancak kullanıcının onayı olmadan kullanıcının geçiş anahtarları hakkında bilgi sağlayabileceği için mantıklıdır.

8.10.2.3 transports özelliği ayarlanmadı

Yerel bir geçiş anahtarı eşleşmiyor, bu nedenle sahip olduğunuz tek seçenek bir donanım güvenlik anahtarı (ör. YubiKey) / platformlar arası doğrulayıcı / gezici doğrulayıcı kullanmaktır.

8.10.2.4 Boş allowCredentials

Geçiş anahtarı kimlik doğrulaması yalnızca Windows Hello ve donanım güvenlik anahtarları aracılığıyla mümkündür.

8.11.1.1 transports: [internal, hybrid]

Beklendiği gibi, yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız ve başka bir cihazdaki geçiş anahtarını kullanmanız önerilir (çünkü sistem bu kullanıcı için bir geçiş anahtarı olduğunu bilir).

8.11.1.2 transports: [internal]

Oldukça kafa karıştırıcı bir şekilde, kimlik bilgisi ID'sini değiştirmemize rağmen (yani aslında allowCredentials özelliğinde belirtilmediği için kimlik bilgisini bulamaması gerekir) Windows Hello PIN kodunuzu (veya cihazda ayarlanmışsa parmak izi / yüz taraması) girmeniz istenir. Ancak, Windows Hello PIN kodunu gönderdikten sonra bir hata atılır: "NotAllowedError: İşlem ya zaman aşımına uğradı ya da izin verilmedi. Bkz: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Kullanıcı açısından bu oldukça kafa karıştırıcı bir davranıştır ancak kullanıcının onayı olmadan kullanıcının geçiş anahtarları hakkında bilgi sağlayabileceği için mantıklıdır.

8.11.1.3 transports özelliği ayarlanmadı

Yerel bir geçiş anahtarı eşleşmiyor, bu nedenle QR kodunu taramanız veya bir donanım güvenlik anahtarı (ör. YubiKey) / platformlar arası doğrulayıcı / gezici doğrulayıcı kullanmanız önerilir.

8.11.1.4 Boş allowCredentials

Beklendiği gibi, tüm geçiş anahtarı kimlik doğrulama biçimlerine izin verilir: Windows Hello aracılığıyla, QR kodu aracılığıyla ve donanım güvenlik anahtarları aracılığıyla. Bir nedenden ötürü, bilinen cihazlar görüntülenmiyor.

8.11.2.1 transports: [internal, hybrid]

Bu, kullanıcılar için gerçekten kafa karıştırıcı bir mesajdır, çünkü ne yapmaları gerektiği ve nasıl kimlik doğrulaması yapabilecekleri açıkça belirtilmemiştir. Sahip oldukları tek seçenek "İptal"e tıklamaktır, bu da bu senaryoyu bir çıkmaza sokar.

8.11.2.2 transports: [internal]

Bu davranış, Bluetooth'un etkin olduğu durumla aynıdır. Kimlik bilgisi ID'sini değiştirmemize rağmen (yani aslında allowCredentials özelliğinde belirtilmediği için kimlik bilgisini bulamaması gerekir) kullanıcının Windows Hello PIN kodunu (veya cihazda ayarlanmışsa parmak izi / yüz taraması) girmesi istenmesi çok kafa karıştırıcıdır. Ancak, Windows Hello PIN kodunu gönderdikten sonra bir hata atılır: "NotAllowedError: İşlem ya zaman aşımına uğradı ya da izin verilmedi. Bkz: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Kullanıcı açısından bu oldukça kafa karıştırıcı bir davranıştır ancak kullanıcının onayı olmadan kullanıcının geçiş anahtarları hakkında bilgi sağlayabileceği için mantıklıdır.

8.11.2.3 transports özelliği ayarlanmadı

Yerel bir geçiş anahtarı eşleşmiyor, bu nedenle sahip olduğunuz tek seçenek bir donanım güvenlik anahtarı (ör. YubiKey) / platformlar arası doğrulayıcı / gezici doğrulayıcı kullanmaktır.

8.11.2.4 Boş allowCredentials

Geçiş anahtarı kimlik doğrulaması yalnızca Windows Hello ve donanım güvenlik anahtarları aracılığıyla mümkündür.

• Saf WebAuthn API'sinin karmaşıklıklarının bir kısmını soyutlayan kütüphaneler ve çerçeveler kullanın.
• Geniş bir kullanıcı tabanının geçiş anahtarı uygulamanızdan faydalanabilmesini sağlamak için platformlar arası kimlik doğrulama senaryolarını baştan düşünün. Tasarım tercihlerinize bağlı olarak, bu senaryolarda alternatif giriş yöntemleri de sunabilirsiniz.
• Cihaz sınırlamaları nedeniyle geçiş anahtarı platformlar arası kimlik doğrulamasının (hibrit taşıma) mümkün olmayabileceği senaryolar için yedek mekanizmalar geliştirin.
• En büyük tasarım kararı, QR kodu / Bluetooth (hibrit taşıma) aracılığıyla platformlar arası geçiş anahtarı kimlik doğrulamasını teşvik edip etmeyeceğinize ve bunu geçiş anahtarı kimlik doğrulaması için belirgin bir yöntem haline getirip getirmeyeceğinize veya aktif olarak teşvik etmemek için ipuçları kullanıp kullanmayacağınıza karar vermektir. İkinci durumda, her zaman hemen dahili olarak depolanan geçiş anahtarlarını kullanmaya çalışılır ve yalnızca dahili bir geçiş anahtarı bulunamazsa, platformlar arası kimlik doğrulama (hibrit taşıma) için bir QR kodu görüntülenir. Bu, WebAuthn sunucunuzun seçeneklerinde [excludeCredentials](/glossary/excludecredentials) ve [allowCredentials](/glossary/allowcredentials) özelliklerinde tanımlanmalıdır. WebAuthn sunucunuzun [excludeCredentials](/glossary/excludecredentials) özelliğinde, zaten oluşturulmuş kimlik bilgileri hakkında taşıma bilgilerini görebilirsiniz. [allowCredentials](/glossary/allowcredentials) özelliğinde, giriş sürecindeki davranışı belirtebilirsiniz (yukarıdaki testlere bakın).
• Ayrıca, platformlar arası geçiş anahtarı kimlik doğrulamasını (hibrit taşıma) tamamen engelleyemezsiniz (transports: \[internal] ile yapılan yukarıdaki testlere bakın), bu nedenle kullanıcılarınızın bu yöntemi bulacağına ve soruları olacağına hazırlıklı olmanız gerekir. Bu platformlar arası kimlik doğrulamasının (hibrit taşıma) ortaya çıkması, özellikle kullanıcılar yerel olarak geçiş anahtarlarını silmeye başladığında meydana gelecektir.

• Kullanıcılara geçiş anahtarı platformlar arası kimlik doğrulama (hibrit taşıma) sürecinde yol gösteren kapsamlı kılavuzlar ve öğreticiler oluşturun.
• Kullanıcıları ilk geçiş anahtarı platformlar arası kimlik doğrulama (hibrit taşıma) deneyimleri sırasında yönlendirmek için uygulama içi araç ipuçları ve bağlamsal yardım bölümleri kullanın.
• Web sitenizde veya uygulama içinde SSS ve sorun giderme bölümleri sağlayın.

• Erişimin yalnızca geçici ve güvenli olmasını sağlamak için QR kodu veya Bluetooth aracılığıyla geçiş anahtarı girişleri için zaman sınırlı oturumlar uygulayın.
• Geçiş anahtarı platformlar arası kimlik doğrulamasının (hibrit taşıma) mevcut güvenlik protokollerini baltalamadığından, kullanıcı verilerinin bütünlüğünü koruduğundan emin olun.
• Gizlilik etkilerini göz önünde bulundurun ve geçiş anahtarı platformlar arası kimlik doğrulaması (hibrit taşıma) aracılığıyla verilen herhangi bir geçici erişimin güvenlik en iyi uygulamalarına göre günlüğe kaydedildiğinden ve izlendiğinden emin olun.

QR kodu / Bluetooth (hibrit taşıma) aracılığıyla geçiş anahtarı platformlar arası kimlik doğrulaması, güvenlik ve kullanıcı deneyimi arasında bir denge sunar. Ancak, çoğu kullanıcı için tamamen yeni bir süreçtir ve birçok kafa karıştırıcı duruma neden olabilir, bu nedenle teşvik edip etmeyeceğinizi dikkatlice düşünmeniz gerekir.

QR kodu / Bluetooth aracılığıyla geçiş anahtarı platformlar arası kimlik doğrulama (hibrit taşıma) konusuna biraz ışık tutabildiğimizi, işlerin nasıl kurulacağını ve farklı cihaz / tarayıcı kombinasyonlarındaki davranışın nasıl göründüğünü açıklayabildiğimizi umuyoruz. Herhangi bir sorunuz varsa, geçiş anahtarları topluluğumuz aracılığıyla bize ulaşmaktan veya geçiş anahtarları Substack'imize abone olmaktan çekinmeyin. Geçiş anahtarlarını yayarak İnternet'i daha güvenli bir yer haline getirelim.