Pass-the-Passkey: Kurumlar İçin WebAuthn Test Rehberi

Passkey'ler kimlik avına dayanıklı oturum açmayı daha fazla kullanıcı için uygulanabilir hâle getiriyor; ancak passkey'i devreye almak güvenlik çalışmasını bitirmiyor. Passkey, belirli bir doğrulama akışında kimlik bilgisinin sahibinde olduğunu kanıtlar. Doğrulayıcı tarafı bu akışı doğru hesap, origin, tarayıcı oturumu ve yeni sunucu challenge'ına bağlamalıdır. Uç nokta da kullanıcıya hangi uygulamanın doğrulama istediğini açıkça göstermelidir.

Pass-the-Passkey saldırı sınıfı, çevredeki kontrollerden biri başarısız olduğunda ne olabileceğini incelemek için yararlı bir çerçevedir. Bu rehber önemli WebAuthn kontrollerini, bunları güvenli biçimde nasıl test edeceğinizi ve kurtarma ile uç nokta davranışlarının passkey akışını zayıflatmasını nasıl önleyeceğinizi anlatıyor.

Pass-the-Passkey ne anlama gelir?

Pass-the-Passkey, saldırganın passkey'in özel anahtarını çıkarmadan kimlik doğrulama sürecinin çevresindeki kontrollerden yararlanmasını anlatır. Zayıflığa göre saldırgan açığa çıkmış assertion verisini, sunucudaki zayıf tekrar kontrollerini, oturum bağlama hatasını veya kullanıcının beklemediği bir uygulamanın başlattığı inandırıcı yerel doğrulama penceresini hedefleyebilir.

Bu ad, passkey'lerin parolalarla aynı olduğu veya kriptografisinin kırıldığı anlamına gelmez. Passkey'ler birçok kimlik avı türüne karşı güçlü koruma sağlar. Buradaki ders şudur: kriptografik anahtarın korunması, doğrulayıcı yanlış assertion'ı kabul ediyorsa veya uç nokta zararlı yazılımın kullanıcıyı beklenmedik girişi onaylamaya yönlendirmesine izin veriyorsa yeterli olmaz.

Güvenli WebAuthn girişi nasıl çalışmalı?

Basitleştirilmiş bir passkey girişinin iki tarafı vardır:

Uygulama sunucusu yeni bir challenge üretir ve bunu girişimi başlatan oturumla ve beklenen kullanıcı veya hesapla ilişkilendirir.
Tarayıcı, relying party için authenticator'dan assertion ister.
Gerekli kullanıcı etkileşiminden sonra authenticator; challenge ve relying party bağlamını içeren veriyi imzalar.
Tarayıcı assertion'ı uygulama sunucusuna iletir.
Sunucu challenge'ı, origin'i, relying-party tanımlayıcısını, imzayı, kimlik bilgisinin hesapla ilişkisini ve gerekli authenticator bayraklarını doğrular.
Sunucu challenge'ı tüketilmiş olarak işaretler ve ancak bütün kontroller başarılıysa oturum açar.

Challenge yeniden kullanılabilir bir giriş belirteci değildir. Tek bir girişimi sunucunun o andaki durumuna bağlayan, bir defalık değerdir. Sunucu aynı challenge'ı tekrar kabul ederse, başka oturumda kullanırsa veya origin ile relying party doğrulamasını atlıyorsa özel anahtar authenticator'dan çıkmadan da önemli korumalar kaybedilebilir.

Doğrulayıcı tarafında kontrol edilmesi gerekenler

Yeni ve tek kullanımlık challenge

Tahmin edilemez, yeterli entropiye sahip ve kısa sürede süresi dolan challenge üretin. Challenge'ı sunucu tarafında saklayın veya istemcinin değiştiremeyeceği, bütünlüğü korunan duruma bağlayın. Başarılı assertion sonrasında tüketildi olarak işaretleyin; süresi dolduğunda, hesap değiştiğinde veya yeni giriş başlatıldığında reddedin.

Tekrarı ve eşzamanlı istekleri de test edin. Aynı assertion'ı neredeyse aynı anda gönderen iki istek iki ayrı geçerli oturum oluşturmamalı. Kullanıcı akışı yeniden başlattıktan veya oturumu kapattıktan sonra challenge geçerli kalmamalı.

Oturuma ve hesaba bağlama

Her challenge'ı onu başlatan oturuma ve beklenen hesap bağlamına bağlayın. Bir tarayıcı oturumu için oluşturulan assertion başka oturumda, başka kiracıda veya başka hesabın giriş işleminde kabul edilmemeli. Paralel sekmeleri, hesap değiştirmeyi ve ikinci bir tarayıcı profilinde açılan giriş bağlantılarını test edin.

Bu kontrol çok kiracılı uygulamalarda özellikle önemlidir. Bir kullanıcı için geçerli kimlik bilgisi, uygulamanın başka kullanıcı veya kiracıyla ilişkilendirdiği oturumu doğrulamamalıdır.

Origin ve relying-party doğrulaması

Desteklediğiniz WebAuthn akışına göre beklenen origin ve relying-party tanımlayıcısını tam olarak doğrulayın. İmza doğrulanıyor diye yanıtı kabul etmeyin. Alt alan adlarını, hazırlık ortamı alan adlarını, özel alan adlarını, gömülü web görünümlerini ve mobil derin bağlantıları inceleyin; yapılandırılmış güven sınırı ürünün gerçek giriş yüzeyiyle uyuşsun.

Kimlik bilgisi, imza ve authenticator verisi

Kimlik bilgisinin doğrulanan hesaba ait olduğunu teyit edin, assertion imzasını doğrulayın ve gerekli authenticator verisi ile kullanıcı doğrulama politikasını kontrol edin. Kayıt, giriş ve hesap kurtarma mantığını birbiriyle uyumlu tutun; saldırganın adımlar arasında kimliği değiştirmesine izin vermeyin.

Tekrar sinyalleri ve authenticator sayaçları

İmza sayacı bazı klonlanmış authenticator veya tekrar durumlarını belirlemeye yardımcı olabilir; ancak tüm passkey uygulamaları aynı sayacı sağlamaz. Senkronize kimlik bilgileri, eski authenticator'lardaki gibi sürekli artan sayaç sunmayabilir. Uygun olduğunda sayaç değişimini risk sinyallerinden biri olarak değerlendirin; challenge tazeliği, tek kullanımlılık ve oturum bağının yerine koymayın.

Oturum oluşturma ve iptal

Başarılı doğrulamadan sonra uygulama oturum kimliğini yenileyin ve diğer güçlü kimlik doğrulama yöntemlerindeki güvenli çerez, süre ve iptal kontrollerini uygulayın. Passkey assertion'ı, ön kimlik doğrulama oturumunu yüksek yetkili hâle getirmemeli. Kullanıcı kimlik bilgisini kaldırdığında, hesabı kapattığında veya şüpheli giriş bildirdiğinde ilgili oturumları ve yenileme belirteçlerini aynı kimlik kontrol düzleminden iptal edin.

Hesap kurtarma ve alternatif girişleri test edin

Güçlü passkey akışı, daha zayıf bir kurtarma yoluyla etkisizleşebilir. Parola sıfırlamayı, e-posta bağlantısıyla kurtarmayı, destek ekibi doğrulamasını, SMS yedeğini, hatırlanan cihazları ve yeni passkey kaydını inceleyin. Passkey kullanamayan bir kişi daha zayıf faktörle aynı hesaba ulaşabiliyor mu? Bu değişiklik güvenlik izleme sisteminde görünür mü?

Her alternatif yol için şunları kaydedin:

Hangi kimlik kanıtının istendiği.
Kimlik doğrulama faktörlerini veya kurtarma iletişim bilgilerini değiştirip değiştirmediği.
İşlemden sonra hangi mevcut oturumların geçerli kaldığı.
Kullanıcının uyarı alıp yetkisiz değişikliği geri alıp alamadığı.
Destek ve güvenlik ekiplerinin hangi olay kayıtlarına erişebildiği.

Passkey akışını güçlü göstermek için kurtarmayı kapatmayın. Kurtarma sürecini hesap riskine göre orantılı, sosyal mühendisliğe dayanıklı ve izlenebilir tasarlayın.

Yerel doğrulama pencereleri de giriş yüzeyidir

İşletim sisteminin passkey pencereleri tanıdık ve meşru görünebilir. Kötü amaçlı yazılım veya güvenilmeyen uygulama, kullanıcının beklemediği anda doğrulama isteği başlatmaya çalışabilir. Bu, WebAuthn'ın otomatik olarak aşıldığı anlamına gelmez: kullanıcının etkileşimi gerekir ve doğrulayıcı yine assertion'ı denetler. Ancak uç nokta bağlamı ve kullanıcı beklentisi önemlidir.

Yönetilen cihazlarda hangi uygulamaların doğrulama başlatabildiğini, uygulama kimliğinin nasıl gösterildiğini ve uç nokta telemetrisinin neleri kaydettiğini inceleyin. Beklenen giriş akışını öngörülebilir kılın. Kullanıcılara her sistem penceresini onaylamayı veya her pencereyi reddetmeyi öğretmeyin; başlatmadıkları istemi bildirebilecekleri bir yol sunun.

Yüksek değerli hesaplar için cihaza bağlı kimlik bilgisi, authenticator attestation'ı veya yönetilen cihaz şartını destekleniyorsa değerlendirin. Zorunlu kılmadan önce kurtarma, gizlilik, erişilebilirlik ve destek maliyetlerini tartın. Bu kontroller passkey kullanımını güçlendirebilir ancak sunucudaki WebAuthn doğrulamasının yerini tutmaz.

Güvenli passkey güvenlik testi planı

Değerlendirmeyi özel test hesaplarıyla; gerçek müşteri, ödeme veya yönetici erişimi olmayan hazırlık ortamında yürütün. Testten önce uygulama ve kimlik sahipleriyle kapsamı netleştirin.

Test durumu	Beklenen sonuç	Saklanacak kanıt
Süresi dolmuş challenge ile assertion gönderme	Kimliği doğrulanmış oturum oluşturmadan reddetme	Assertion verisi maskelenmiş challenge süresi ve ret nedeni
Başarılı girişten sonra assertion'ı tekrar kullanma	Tekrarı reddetme, ilk oturum durumunu koruma	Tek kullanımlı challenge durumu ve istek korelasyon numarası
Assertion'ı farklı tarayıcı oturumunda gönderme	Challenge başlangıç oturumuna bağlı olduğu için reddetme	Oturum numarası veya hassas olmayan korelasyon değeri
Doğrulama sırasında hesap veya kiracı değiştirme	Challenge'ın beklenen kimliği artık eşleşmiyorsa reddetme	Hesap/kiracı bağlamı ve sunucu kararı
Farklı origin veya relying-party bağlamı kullanma	Yapılandırılmış WebAuthn politikasına göre reddetme	Özel kullanıcı verisi içermeyen doğrulanmış origin ve RP ID
Kurtarma tamamlayıp yeni kimlik bilgisi kaydetme	Onaylı kurtarma kuralını uygulama ve kullanıcıyı bilgilendirme	Kurtarma kararı, faktör değişimi ve bildirim olayı
Kullanıcı eylemi olmadan doğrulama penceresi başlatma	Bildirilebilir olay oluşturma ve uç nokta bağlamını inceleme	Ortamda bulunan süreç ve sağlayıcı telemetrisi

Challenge kimliğini veya güvenli korelasyon değerini, istek zamanını, origin'i, relying-party tanımlayıcısını, hesap bağlamını ve sonucu kaydedin. Özel anahtarları saklamayın; ham assertion verisini test için gerekenden uzun tutmayın. Gerçek bir çalışanın doğrulama assertion'ını yakalamayın veya yeniden kullanmayın.

Düzeltmeden sonra aynı başarısız testi ve yakın akışları tekrar edin: başka tarayıcıdan giriş, hesap değiştirme, kurtarma, kimlik bilgisini kaldırma ve oturum iptali. Kod değişikliği ancak uygulama geçersiz durumu reddettiğinde ve meşru kullanıcı akışı çalışmaya devam ettiğinde doğrulanmış sayılır.

Passkey'leri zayıflatan uygulama hataları

Challenge'ı istekler arasında tekrar kullanmak veya giriş akışı bittiğinde geçerli bırakmak.
Challenge'ı kullanıcıya bağlayıp tarayıcı oturumu ya da kiracıyla ilişkilendirmemek.
İmzayı doğrularken origin, relying party veya hesap kontrollerini atlamak.
Authenticator sayacını tek tekrar savunması olarak kullanmak.
Hata ayıklama için ham assertion veya hassas authenticator verisi kaydetmek.
Daha zayıf kurtarma veya faktör kaydetme yolunu güvenlik incelemesi dışında bırakmak.
Ön kimlik doğrulama oturumunu oturum kimliğini yenilemeden ayrıcalıklı hâle getirmek.
Yerel pencere görünmesini, doğru uygulamanın giriş başlattığının kanıtı saymak.

Sık sorulan sorular

Passkey'ler kimlik avına karşı tamamen güvenli mi?

Passkey'ler doğrulamayı relying party'ye bağlayarak yaygın kimlik avına karşı koruma sağlamak üzere tasarlanmıştır. Ele geçirilmiş uç nokta, zayıf kurtarma, yanlış sunucu doğrulaması veya kullanıcının beklenmedik isteği onaylamaya yönlendirilmesi risklerini ortadan kaldırmaz.

Passkey assertion tekrar kullanılabilir mi?

Doğru tasarlanmış doğrulayıcı, yeni ve tek kullanımlık challenge uygulayarak ve her challenge'ı başlangıç oturumuna ve hesap bağlamına bağlayarak tekrar kullanılan assertion'ı reddetmelidir. Yalnızca imza doğrulamasının tekrarı önlediğini varsaymayın; bu kontrolleri doğrudan test edin.

Her kurum cihaza bağlı passkey zorunlu tutmalı mı?

Her zaman değil. Cihaza bağlı kimlik bilgileri yüksek değerli hesapları güçlendirebilir; ancak kullanılabilirlik, kurtarma, cihaz yenileme, erişilebilirlik ve destek ihtiyaçları değişir. Politikayı hesap riskine göre belirleyin ve kayıt ile kurtarma yolunun tamamını test edin.

WebAuthn girişinde hangi kayıtlar tutulmalı?

Kararı, challenge yaşam döngüsünü, origin ve relying-party doğrulama sonucunu, hesap bağlamını, gizliliği koruyan kimlik bilgisi tanımlayıcısını ve istek korelasyon numarasını kaydedin. Yeni tekrar veya gizlilik riski oluşturmamak için özel anahtarları ya da ham assertion değerlerini saklamayın.

Passkey'ler, giriş sisteminin tamamı sağladıkları korumaları sürdürdüğünde güçlü bir temel sunar. Eresus Security; WebAuthn, hesap kurtarma, oturum ve ayrıcalıklı erişim akışlarını uygulama güvenliği değerlendirmesinde test edebilir.