Passkey, parola yerine açık anahtarlı kriptografi kullanan ve kullanıcının cihaz kilidini açarken kullandığı biyometri, PIN veya desenle etkinleştirilen FIDO kimlik bilgisidir. Her passkey belirli bir web sitesi ya da uygulama hesabına bağlıdır. Sunucu özel anahtarı hiçbir zaman almaz; yalnızca kullanıcının cihazında tutulan özel anahtarla imzalanmış, o oturuma özgü bir yanıtı doğrular.
Web ortamında passkey desteğinin temelini WebAuthn API’si oluşturur. WebAuthn, web uygulaması ile tarayıcı/platform arasında açık anahtarlı kimlik bilgisi oluşturma ve kullanma arayüzünü tanımlar. FIDO Alliance’ın CTAP protokolü ise tarayıcı veya işletim sistemi ile haricî güvenlik anahtarı, telefon ya da başka bir authenticator arasındaki iletişimi düzenler. WebAuthn ve CTAP birlikte FIDO2 olarak anılır.
Passkey nasıl çalışır?
Bir passkey iki anahtarlı bir çift üretir:
- Özel anahtar: Kullanıcının authenticator’ında kalır; sunucuya gönderilmez.
- Açık anahtar: Kullanıcı hesabıyla birlikte sunucuda saklanır ve imzaları doğrulamak için kullanılır.
Kayıt sırasında sunucu rastgele bir challenge üretir. Tarayıcı bu challenge’ı, sitenin kimliğini ve kayıt seçeneklerini authenticator’a iletir. Authenticator yeni bir anahtar çifti oluşturur, özel anahtarı korur ve açık anahtarla birlikte imzalı kayıt verisini sunucuya döndürür. Sunucu challenge, origin, relying party kimliği ve diğer güvenlik alanlarını doğruladıktan sonra açık anahtarı hesaba bağlar.
Giriş sırasında sunucu yeniden tek kullanımlık bir challenge üretir. Authenticator, doğru site bağlamında kullanıcı doğrulaması tamamlandığında challenge’a bağlı veriyi özel anahtarla imzalar. Sunucu sakladığı açık anahtarla imzayı doğrular. Saldırganın parola veri tabanı gibi yeniden kullanılabilir bir sır ele geçirebileceği merkezi bir özel anahtar deposu yoktur.
WebAuthn neden oltalamaya dayanıklıdır?
NIST SP 800-63B-4, WebAuthn’ı doğrulayıcı ad bağlama yöntemiyle oltalamaya dayanıklılık sağlayan standart örneklerinden biri olarak gösterir. Passkey, Relying Party ID adı verilen alan adına bağlıdır. Sahte bir alan adında çalışan kimlik avı sitesi, gerçek sitenin passkey’ini kullanamaz.
Bu koruma kullanıcının sahte siteyi fark etmesine bağlı değildir. Tarayıcı ve authenticator, kimlik bilgisinin hangi alan adı için oluşturulduğunu kriptografik işlemde uygular. Geleneksel OTP’de kullanıcı altı haneli kodu saldırgana aktarabilir; WebAuthn’da imza gerçek sitenin alan adı ve oturuma özgü challenge ile bağlıdır.
Oltalamaya dayanıklılık yine de uygulamanın tamamını otomatik olarak güvenli yapmaz. Hatalı hesap kurtarma, zayıf oturum yönetimi, yetkisiz passkey ekleme, açık yönlendirme, XSS veya kötü niyetli tarayıcı eklentisi farklı saldırı yolları oluşturabilir. Passkey güçlü bir kimlik doğrulama mekanizmasıdır; erişim kontrolü ve uygulama güvenliğinin yerine geçmez.
Senkronize ve cihaza bağlı passkey farkı
| Özellik | Senkronize passkey | Cihaza bağlı passkey |
|---|---|---|
| Saklama | Passkey sağlayıcısının uçtan uca şifreli senkronizasyonuyla birden fazla cihaza taşınabilir | Tek cihazda veya fiziksel güvenlik anahtarında kalır |
| Kullanım kolaylığı | Yeni cihazda daha düşük kurtarma yükü | Her cihaz veya anahtar için ayrı kayıt gerekebilir |
| Kurumsal kontrol | Sağlayıcı ve hesap kurtarma modeline bağlı | Donanım envanteri ve cihaz politikasıyla daha sıkı bağ kurulabilir |
| Kayıp riski | Sağlayıcı hesabı üzerinden kurtarma mümkün olabilir | Yedek authenticator yoksa hesap kurtarma ihtiyacı artar |
| Uygun senaryo | Tüketici uygulamaları ve geniş kullanıcı kitlesi | Yüksek ayrıcalıklı yönetici, geliştirici ve düzenlemeye tabi erişim |
FIDO Alliance, “passkey” terimini hem senkronize hem cihaza bağlı FIDO kimlik bilgileri için kullanır. Kurumlar tek bir türü bütün kullanıcılar için zorunlu kılmak yerine risk tabanlı seçim yapmalıdır. Müşteri portalında senkronize passkey dönüşümü artırabilirken üretim yöneticileri için cihaza bağlı güvenlik anahtarı daha uygun olabilir.
WebAuthn mimarisindeki temel bileşenler
- Relying Party (RP): Kimlik doğrulama isteyen web hizmeti ve onun sunucu tarafı.
- RP ID: Kimlik bilgisinin bağlandığı etki alanı. Genellikle sitenin alan adı veya uygun üst alanıdır.
- Origin: Şema, ana makine ve port bileşimi; sunucu tarafından tam olarak doğrulanmalıdır.
- Client: WebAuthn çağrısını yöneten tarayıcı veya işletim sistemi bileşeni.
- Authenticator: Anahtar çiftini oluşturan, özel anahtarı koruyan ve imza üreten donanım ya da platform.
- Credential ID: Sunucunun kullanıcıya ait doğru açık anahtar kaydını bulmasını sağlayan tanımlayıcı.
- Challenge: Her kayıt ve giriş denemesi için sunucuda üretilen, tek kullanımlık rastgele değer.
- User verification: PIN veya biyometri gibi yerel mekanizmayla authenticator’ı kullanan kişinin doğrulanması.
Passkey kayıt akışı
Güvenli bir kayıt akışı aşağıdaki adımları izler:
- Kullanıcı mevcut güvenilir yöntemle oturum açar veya kimliği doğrulanmış kayıt sürecindedir.
- Sunucu en az 128 bit öngörülemez challenge üretir ve kısa süreli oturum kaydına bağlar.
- Sunucu RP ID, kullanıcı kimliği, görünen ad, desteklenen algoritmalar ve doğrulama politikasını içeren seçenekleri döndürür.
- Tarayıcı navigator.credentials.create çağrısıyla authenticator’dan yeni kimlik bilgisi ister.
- Kullanıcı cihazında biyometri veya PIN ile işlemi onaylar.
- Tarayıcı attestation verisini ve credential bilgilerini sunucuya gönderir.
- Sunucu challenge, origin, RP ID hash, kullanıcı doğrulama bayrakları ve algoritmayı doğrular.
- Credential ID, açık anahtar, imza sayacı ve uygun metadata kullanıcı hesabına kaydedilir.
- Challenge tüketilir; aynı değerle ikinci kayıt kabul edilmez.
- Kullanıcıya yeni authenticator eklendiğine dair güvenlik bildirimi gösterilir.
Tarayıcı tarafında kayıt örneği
Aşağıdaki örnek yalnızca akışın iskeletini gösterir. Üretimde base64url dönüşümü, hata yönetimi, zaman aşımı ve sunucu doğrulaması güvenilir bir WebAuthn kütüphanesiyle uygulanmalıdır.
CODE TERMINAL
const options = await fetch('/webauthn/register/options', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
credentials: 'same-origin'
}).then(r => r.json());
options.challenge = base64urlToBuffer(options.challenge);
options.user.id = base64urlToBuffer(options.user.id);
options.excludeCredentials = (options.excludeCredentials || []).map(item => ({
...item,
id: base64urlToBuffer(item.id)
}));
const credential = await navigator.credentials.create({ publicKey: options });
await fetch('/webauthn/register/verify', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
credentials: 'same-origin',
body: JSON.stringify(serializeCredential(credential))
});Challenge tarayıcıda üretilmemelidir. Sunucu challenge’ı kullanıcı oturumu ve işlem amacıyla bağlamalı, doğrulamadan sonra tek kullanımlık olarak tüketmelidir. Kullanıcı kimliği alanında e-posta gibi değişebilir veya kişisel bilgiyi doğrudan taşıyan değer yerine rastgele ve kalıcı bir iç tanımlayıcı kullanılması daha uygundur.
Passkey ile giriş akışı
- Sunucu yeni bir authentication challenge üretir.
- Kullanıcı adı önceden biliniyorsa allowCredentials listesi verilebilir; kullanıcı adı olmadan girişte discoverable credential kullanılabilir.
- Tarayıcı navigator.credentials.get çağrısıyla uygun passkey’i ister.
- Authenticator, RP ID eşleşmesini ve kullanıcı doğrulamasını kontrol eder.
- Authenticator challenge’a bağlı veriyi özel anahtarla imzalar.
- Sunucu credential ID ile açık anahtarı bulur.
- Challenge, origin, RP ID hash, imza, kullanıcı doğrulama bayrakları ve sayaç bilgisi doğrulanır.
- Başarılı doğrulama sonrasında eski oturum kimliği döndürülür ve güvenli yeni oturum başlatılır.
Tarayıcı tarafında giriş örneği
CODE TERMINAL
const options = await fetch('/webauthn/login/options', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
credentials: 'same-origin'
}).then(r => r.json());
options.challenge = base64urlToBuffer(options.challenge);
options.allowCredentials = (options.allowCredentials || []).map(item => ({
...item,
id: base64urlToBuffer(item.id)
}));
const assertion = await navigator.credentials.get({ publicKey: options });
const result = await fetch('/webauthn/login/verify', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
credentials: 'same-origin',
body: JSON.stringify(serializeCredential(assertion))
}).then(r => r.json());
if (!result.ok) throw new Error('Kimlik doğrulama başarısız');İstemci tarafındaki API çağrısının başarılı olması oturum açmak için yeterli değildir. Kimlik doğrulama kararı yalnızca sunucunun kriptografik doğrulamasından sonra verilmelidir.
Sunucuda mutlaka doğrulanması gereken alanlar
- Challenge: Beklenen değerle sabit zamanlı karşılaştırılmalı, süresi dolmamış olmalı ve bir kez kullanılmalıdır.
- Origin: HTTPS şeması, alan adı ve gerekiyorsa port kesin izin listesiyle eşleşmelidir.
- RP ID hash: Sunucunun beklediği RP ID’nin SHA-256 özetiyle eşleşmelidir.
- Type: clientDataJSON içindeki işlem türü kayıt için webauthn.create, giriş için webauthn.get olmalıdır.
- İmza: Kayıtlı açık anahtar ve izin verilen algoritmayla doğrulanmalıdır.
- User presence: Kullanıcının fiziksel varlığını belirten UP bayrağı gereken politikaya uygun olmalıdır.
- User verification: MFA veya parolasız yüksek güvence isteniyorsa UV bayrağı zorunlu tutulmalıdır.
- Credential eşleşmesi: Credential ID doğru kullanıcı hesabına bağlı olmalı; başka hesaba taşınmamalıdır.
- Sayaç veya yedek durumu: Authenticator davranışı ve senkronize passkey özellikleri dikkate alınarak anomali sinyali olarak değerlendirilmelidir.
- Algoritma: Yalnızca sunucunun açıkça izin verdiği modern algoritmalar kabul edilmelidir.
WebAuthn veri yapıları CBOR, COSE ve base64url gibi biçimler içerir. Kendi ayrıştırıcınızı ve imza doğrulamanızı sıfırdan yazmak hata riskini artırır. Aktif bakımı yapılan, test vektörleri bulunan ve dil ekosisteminizde yaygın kullanılan bir sunucu kütüphanesi tercih edilmelidir.
RP ID ve origin yapılandırması
RP ID seçimi passkey tasarımının en kritik kararlarından biridir. app.example.com üzerinde çalışan bir uygulama RP ID olarak app.example.com kullanırsa kimlik bilgisi yalnızca bu alt alan için geçerli olur. example.com seçimi uygun koşullarda birden fazla alt alanın aynı passkey kapsamını kullanmasını sağlayabilir; ancak saldırı yüzeyini de genişletir.
Paylaşılan barındırma, müşteri alt alanları veya güvenilmeyen içerik sunan alt alanlar varsa üst alan RP ID seçimi dikkatle değerlendirilmelidir. Public Suffix List sınırları aşılamaz. Origin doğrulaması wildcard mantığıyla gevşetilmemeli; üretim, test ve geliştirme alanları birbirinden ayrılmalıdır.
Passkey üretimde HTTPS gerektirir. localhost geliştirme istisnası, gerçek ortamda HTTP kullanımına gerekçe değildir. Ters vekil arkasında uygulamanın gördüğü Host ve proto bilgisinin güvenilir proxy yapılandırmasıyla sabitlenmesi gerekir; istemciden gelen rastgele başlıklarla origin türetilmemelidir.
Attestation gerekli mi?
Attestation, authenticator modeline ve üretim zincirine ilişkin ek kanıt sağlayabilir. Tüketici uygulamalarında çoğu zaman attestation değerini none olarak kullanmak gizlilik ve uyumluluk açısından en sade yaklaşımdır. Kurumsal senaryolarda yalnızca onaylı güvenlik anahtarlarına veya yönetilen cihazlara izin vermek için direct ya da enterprise attestation değerlendirilebilir.
Attestation zorunluluğu şu maliyetleri getirir:
- Metadata servisinin ve güven köklerinin güncel tutulması
- Yeni authenticator modellerinin kabul süreci
- Tedarikçi bağımlılığı ve kullanıcı desteği yükü
- Authenticator modelinin kullanıcılar arasında korelasyon oluşturma ihtimali
- Sertifika iptali ve metadata değişikliklerinin yönetimi
Risk gerekçesi yoksa attestation’ı zorunlu kılmak passkey kullanımını gereksiz yere daraltabilir. Yüksek ayrıcalıklı kurum erişiminde ise yönetilen donanım gereksinimi anlamlı olabilir.
Kullanıcı doğrulaması ve biyometri
Passkey kullanırken yüz veya parmak izi verisi web sitesine gönderilmez. Biyometrik eşleştirme kullanıcının cihazında yapılır; sunucu yalnızca authenticator’ın kullanıcı doğrulamasını başarıyla tamamladığına ilişkin kriptografik sonucu görür. Cihaz biyometri desteklemiyorsa yerel PIN veya cihaz parolası kullanılabilir.
WebAuthn seçeneklerindeki userVerification değeri preferred bırakıldığında bazı cihazlar yalnızca kullanıcı varlığıyla işlem yapabilir. Uygulama passkey’i tek başına çok faktörlü kimlik doğrulama olarak kabul edecekse required politikası ve sunucuda UV bayrağı doğrulaması gerekir. Yönetim paneli, para transferi veya anahtar döndürme gibi hassas işlemler için yeniden kimlik doğrulama uygulanmalıdır.
Hesap kurtarma en zayıf halka olabilir
Passkey’e geçip “şifremi unuttum” akışını tek e-posta bağlantısıyla bırakmak, saldırganın güçlü kimlik doğrulamayı atlamasını sağlar. Kurtarma politikası en az giriş politikası kadar dikkatli tasarlanmalıdır.
- Kullanıcılara en az iki authenticator kaydetme olanağı verin.
- Yeni passkey ekleme ve mevcut olanı silme işlemlerinde yakın zamanda yapılmış güçlü kimlik doğrulama isteyin.
- Kurtarma sonrası bütün aktif oturumları ve riskli hatırlama belirteçlerini iptal etmeyi değerlendirin.
- Yüksek riskli hesaplarda manuel kimlik doğrulama veya gecikmeli kurtarma kullanın.
- Kurtarma kanalı değişikliklerinde eski ve yeni kanala bildirim gönderin.
- Destek ekibinin sosyal mühendislikle passkey kaldırmasını önleyen çift kontrol süreci oluşturun.
- Kullanıcıya kayıtlı passkey’leri cihaz adı, oluşturulma zamanı ve son kullanım bilgisiyle yönetme ekranı sunun.
Passkey ekleme ve silme güvenliği
Bir hesabı ele geçiren saldırgan kendi passkey’ini ekleyerek kalıcılık sağlayabilir. Bu nedenle passkey yönetim uçları sıradan profil güncellemesi gibi ele alınmamalıdır.
- İşlem öncesinde yeniden kimlik doğrulama isteyin.
- CSRF korumasını ve same-site oturum çerezlerini uygulayın.
- Yeni passkey’i benzersiz kullanıcı ve credential ID ile atomik olarak kaydedin.
- Aynı credential’ın farklı hesaplara bağlanmasını engelleyin.
- Ekleme ve silme olaylarını değiştirilemez denetim günlüğüne yazın.
- Kullanıcıya anlık güvenlik bildirimi gönderin.
- Şüpheli cihaz veya konumda ek doğrulama ya da bekleme süresi uygulayın.
Paroladan passkey’e güvenli geçiş
Bir gecede bütün parolaları kapatmak geniş kullanıcı tabanında hesap kaybına yol açabilir. Aşamalı geçiş daha güvenlidir:
- Gözlem: Tarayıcı ve cihaz desteğini ölçün; hangi kullanıcıların uygun platforma sahip olduğunu belirleyin.
- İsteğe bağlı kayıt: Başarılı parola ve MFA girişinden sonra passkey oluşturmayı önerin.
- Passkey öncelikli giriş: Desteklenen cihazlarda passkey’i ilk seçenek yapın, parolayı ikincil akışa alın.
- Riskli grupları taşıma: Yöneticiler, geliştiriciler ve finans kullanıcıları için passkey veya güvenlik anahtarı zorunluluğunu başlatın.
- Kurtarma testi: Cihaz kaybı, telefon değişimi, çalışan ayrılışı ve sağlayıcı hesabı kilidi senaryolarını tatbik edin.
- Parolayı kaldırma: Kullanıcının yeterli yedek authenticator’ı ve güvenli kurtarma yolu doğrulandıktan sonra parola girişini kapatın.
Geçiş süresince saldırganlar zayıf olan yolu seçer. Passkey etkin olsa bile parola ve SMS OTP kullanılabiliyorsa hesap hâlâ bu kanallara yönelik oltalamaya açıktır. Risk azaltımı, eski yöntemin kontrollü biçimde devreden çıkarılmasıyla tamamlanır.
Kurumsal dağıtım için öneriler
- Yönetici hesaplarında cihaza bağlı FIDO2 güvenlik anahtarı kullanın.
- Her yöneticiye en az iki ayrı authenticator verin ve yedeği güvenli saklayın.
- AAGUID veya attestation politikasını yalnızca somut güvence ihtiyacı varsa uygulayın.
- Kayıp, çalıntı ve çalışan ayrılışı süreçlerini cihaz yönetimiyle bütünleştirin.
- Passkey ekleme, silme ve kurtarma olaylarını SIEM’e gönderin.
- Yüksek riskli işlemlerde işlem bağlamına uygun yeniden doğrulama isteyin.
- Kimlik sağlayıcının senkronize passkey kurtarma modelini ve destek sınırlarını belgeleyin.
- Yalnızca “MFA var” metriğini değil, oltalamaya dayanıklı giriş oranını izleyin.
Sık yapılan WebAuthn hataları
- Challenge’ı istemcide üretmek veya yeniden kullanmak
- Origin kontrolünü wildcard ya da string contains ile yapmak
- RP ID’yi ters vekilden gelen güvenilmeyen Host başlığıyla dinamik oluşturmak
- User verification required olduğu hâlde UV bayrağını sunucuda kontrol etmemek
- Kayıt yanıtını doğrulamadan açık anahtarı hesaba eklemek
- Credential ID’nin başka bir hesaba bağlı olup olmadığını kontrol etmemek
- Passkey ekleme işleminde yeniden kimlik doğrulama istememek
- Hesap kurtarmayı tek ve oltalanabilir bir kanala bırakmak
- Kendi CBOR, COSE ve ASN.1 ayrıştırıcısını gereksiz yere yazmak
- Passkey etkin kullanıcılar için parolayı süresiz açık tutmak
- Test ve üretim ortamlarında aynı RP ID politikasını kullanmak
- Kullanıcının kayıtlı authenticator’larını görüntüleyip iptal edebileceği arayüz sağlamamak
Test planı
Üretime geçmeden önce yalnızca başarılı giriş testi yapılmamalıdır. Aşağıdaki olumsuz senaryolar otomatik ve manuel olarak doğrulanmalıdır:
- Yanlış, süresi geçmiş ve daha önce kullanılmış challenge reddediliyor mu?
- Farklı origin ve alt alan adından gelen yanıt reddediliyor mu?
- Yanlış RP ID hash ile doğrulama başarısız oluyor mu?
- UV zorunluyken yalnızca kullanıcı varlığı içeren assertion reddediliyor mu?
- Bir credential başka hesaba bağlanmaya çalışıldığında işlem engelleniyor mu?
- Passkey silindikten sonra eski assertion kullanılamıyor mu?
- Oturum sabitleme saldırısına karşı başarılı girişte session ID yenileniyor mu?
- Kurtarma sonrası eski oturumlar ve hatırlama belirteçleri iptal ediliyor mu?
- Bir kullanıcı bütün passkey’lerini kaybettiğinde denetlenebilir ve güvenli kurtarma çalışıyor mu?
- Cross-device ve senkronize passkey akışları desteklenen tarayıcılarda tutarlı mı?
Passkey’ler her durumda MFA sayılır mı?
Passkey bir cihazda saklanan “sahip olunan” faktörü temsil eder. Relying Party kullanıcı doğrulaması istediğinde authenticator biyometri veya PIN ile ikinci faktörü yerel olarak doğrulayabilir. Ancak uygulama userVerification değerini zorunlu kılmaz ve sunucuda UV bayrağını kontrol etmezse her assertion aynı güvence seviyesini sağlamaz.
Bu nedenle ürün arayüzünde “passkey = otomatik MFA” varsayımı yapılmamalıdır. Kimlik doğrulama güvence seviyesi; authenticator türü, kullanıcı doğrulama politikası, attestation gereksinimi, kurtarma yolu ve oturum güvenliği birlikte değerlendirilerek belirlenmelidir.
Uygulanabilir kontrol listesi
- RP ID ve izin verilen origin listesini statik yapılandırın.
- Her işlem için güçlü, tek kullanımlık ve kısa ömürlü challenge üretin.
- Bakımı yapılan bir WebAuthn sunucu kütüphanesi kullanın.
- Challenge, origin, RP ID hash, type, imza, UP ve gerekiyorsa UV alanlarını doğrulayın.
- Credential ID, açık anahtar, kullanıcı bağı ve metadata’yı güvenli saklayın.
- Kullanıcıya birden fazla passkey kaydetme ve iptal etme olanağı verin.
- Passkey ekleme, silme ve kurtarmada yeniden kimlik doğrulama isteyin.
- Kurtarma kanalını oltalamaya dayanıklı tasarlayın.
- Başarılı girişte oturum kimliğini döndürün; çerezleri Secure, HttpOnly ve uygun SameSite değeriyle ayarlayın.
- Yönetici ve yüksek riskli kullanıcılar için cihaza bağlı authenticator politikasını değerlendirin.
- Eski parola ve OTP yollarını aşamalı olarak kapatın.
- Kimlik doğrulama olaylarını izleyin ve anomali kuralları oluşturun.
Sonuç
Passkey, parolayı paylaşılan sır olmaktan çıkarıp her hizmete özgü açık anahtarlı bir kimlik bilgisine dönüştürür. WebAuthn tarayıcı ve web uygulaması arasındaki API ile doğrulama protokolünü, CTAP ise platform ile authenticator arasındaki iletişimi tanımlar; bu iki yapı FIDO2 ekosistemini oluşturur.
Güvenli uygulamanın anahtarı yalnızca navigator.credentials çağrısını eklemek değildir. Sunucu challenge, origin, RP ID hash, imza ve kullanıcı doğrulama bayraklarını eksiksiz doğrulamalı; passkey yaşam döngüsünü, kurtarmayı, oturumları ve denetim günlüklerini bütüncül biçimde yönetmelidir. Aşamalı geçişte eski parola ve OTP yolları açık kaldığı sürece saldırganlar en zayıf yöntemi hedeflemeye devam eder.
Doğru tasarlanan passkey akışı, kullanıcı deneyimini sadeleştirirken oltalama ve kimlik bilgisi doldurma saldırılarına karşı güçlü bir savunma sağlar. Kurumlar senkronize ve cihaza bağlı passkey modellerini risk gruplarına göre seçmeli, yüksek ayrıcalıklı hesaplarda donanım tabanlı authenticator’ları ve güvenli yedeklemeyi önceliklendirmelidir.
Kaynaklar
- W3C – Web Authentication Level 3
- W3C – Web Authentication Level 2 Recommendation
- FIDO Alliance – Passkeys
- FIDO Alliance – FIDO2, WebAuthn ve CTAP özellikleri
- FIDO Alliance – Kurumlarda passkey dağıtımı
- NIST SP 800-63B-4 – Authentication and Authenticator Management
- MDN – Web Authentication API
TR Siber Ekibi