Geçiş anahtarı tek başına hesabı korur mu?

Kısa cevap: Kimlik avını daraltır, bütün saldırı yüzeyini kapatmaz

Geçiş anahtarı, hizmette saklanan açık anahtar ile telefonda, bilgisayarda veya güvenlik anahtarında tutulan özel anahtarın birlikte çalıştığı bir kimlik doğrulama yöntemidir. Giriş sırasında hizmet rastgele bir sınama gönderir; cihaz özel anahtarla imza üretir ve hizmet bunu açık anahtarla doğrular. Parola gibi iki tarafın bildiği ortak bir sır ağ üzerinden gönderilmez. FIDO Alliance bu yapıyı hizmete özgü ve kimlik avına dirençli olarak tanımlar. Kullanıcı özel anahtarı görmez; cihazdaki yüz, parmak izi veya PIN gibi kilit açma yöntemiyle kullanımına izin verir.

Bununla birlikte “kimlik avına dirençli” ile “hesap ele geçirilemez” aynı iddia değildir. Saldırgan açık bir oturumu çalabilir, cihaz kilidini öğrenebilir, hizmetin daha zayıf parola veya SMS yolunu kullanabilir ya da hesap kurtarma akışını hedefleyebilir. Geçiş anahtarı sahte alan adına imza vermeme avantajı sağlar; hizmetin bütün oturum, yetkilendirme ve kurtarma mimarisini tek başına değiştirmez. Güvenlik değerlendirmesi bu yüzden anahtarın kriptografisinden başlayıp işletim sistemi, anahtar yöneticisi, bulut hesabı, yedek cihazlar ve hizmette kayıtlı alternatif giriş yollarına kadar uzanmalıdır.

Alan adına bağlı anahtar kimlik avını nasıl değiştirir?

Parola saldırısında sahte sayfa gerçek hizmete benzeyip kullanıcının sırrını alabilir. Geçiş anahtarında güvenen taraf kimliği ve alan adı, anahtarın oluşturulduğu bağlama bağlanır. NIST’in senkronize kimlik doğrulayıcı eki, doğru yapılandırmada sahte sayfanın başka alan için üretilmiş anahtarı kullanamayacağını ve imzalı yanıtın rastgele nonce nedeniyle tekrar oynatılamayacağını açıklar. Bu özellik kullanıcının URL’deki her küçük yazım farkını fark etmesine daha az bağımlıdır. Yine de güvenen tarafın WebAuthn uygulaması, alan eşlemesi ve oturum yönetimi doğru olmalıdır.

Cihaz kilidini açmak da sunucuya biyometri göndermek değildir. İşletim sistemi yerel olarak kullanıcının yüz, parmak izi veya PIN ile anahtar kullanımını onayladığını bildirir. NIST’te User Verified bayrağı bu yerel doğrulamanın yapılıp yapılmadığını gösterir; hizmetin bu bayrağı denetlemesi gerekir. Biyometri yoksa Windows Hello PIN’e dönebilir. Önemli ayrım şudur: PIN uzak hizmetin parolası değil, yerel cihazdaki anahtarı etkinleştiren sırdır. Ancak cihazın ekran kilidi paylaşılmışsa veya saldırgan açık cihazı ele geçirmişse kriptografik anahtar yine yetkisiz kullanılabilir.

İşletim sistemi hangi parçaları üstlenir?

Windows 11, iOS, macOS ve diğer güncel platformlar WebAuthn isteğini kullanıcıya göstermek, uygun anahtar yöneticisini seçmek ve yerel doğrulamayı çalıştırmak için aracı olur. Microsoft’un 19 Şubat 2025 tarihli referansı, Windows 11 22H2’nin KB5030310 güncellemesi sonrasında yerel passkey yönetimini; 23H2’nin işletim sistemi düzeyinde çapraz cihaz doğrulamasını desteklediğini belirtir. Ancak “Windows destekliyor” demek her tarayıcı ve sitenin aynı özelliği sunduğu anlamına gelmez. Site WebAuthn kaydını, tarayıcı uygun API’yi ve kuruluş politikası seçilen saklama yolunu desteklemelidir.

Apple Platform Security kılavuzu, iCloud Keychain’in parola ve passkey’leri Apple aygıtları arasında senkronize ettiğini; anahtarlık öğelerinin Apple sunucularından geçerken uçtan uca şifrelendiğini ve Apple’ın içeriklerini okuyamadığını açıklar. Bu mimari, “bulutta eşzamanlanıyor” ifadesinin özel anahtar içeriğinin Apple tarafından okunabildiği anlamına gelmediğini gösterir. Anahtarın hizmetteki açık anahtar kaydı, aygıttaki yerel kaydı ve senkronizasyon katmanı yine ayrı yönetim alanlarıdır.

Senkronizasyon kolaylık karşılığında hangi riski ekler?

Senkronize geçiş anahtarı tek cihaz kaybında erişimi korur; yeni cihaz onaylandığında şifreli anahtar materyali geri gelebilir. NIST bu kolaylığı kabul ederken açık koşullar koyar: senkronizasyon dokusuna çıkarılan anahtarlar onaylı kriptografiyle ve yayın tarihinde en az 112 bit güvenlik gücüyle şifrelenmeli, bulut erişimi AAL2 eşdeğeri çok faktörlü doğrulamayla korunmalı ve özel anahtar işlemi yerel cihazda gerçekleşmelidir. Kullanıcıya hangi hizmet için anahtar oluşturduğu, anahtarın senkronize olup olmadığı ve nerelere yayıldığı gösterilmelidir.

Dışa aktarılabilirlik güvence sınıfını değiştirir. NIST, koşullar sağlandığında senkronize anahtarların AAL2’de kullanılabileceğini, fakat AAL3’ün anahtarın dışa aktarılamaması şartını ihlal ettiğini belirtir. Bu, senkronize passkey’in “güvensiz” olduğu anlamına gelmez; hedeflenen tehdit modeli ve güvence düzeyinin farklı olduğunu gösterir. Tüketici hesabında erişilebilirlik ve kimlik avı direnci ağır basabilir. Yüksek değerli kurumsal işlemde cihaza bağlı donanım anahtarı, yönetilen cihaz ve birden fazla kayıtlı kimlik doğrulayıcı istenebilir. Karar, yalnız kullanım kolaylığına veya pazarlama etiketine göre verilmemelidir.

Kurtarma ve silme neden iki ayrı yerde yapılır?

Bir geçiş anahtarını cihazın anahtar yöneticisinden silmek, hizmetin hesabınıza bağlı açık anahtar kaydını her zaman kaldırmaz. Tersi de geçerlidir: Hizmetin güvenlik sayfasından kimlik bilgisini iptal etmek cihaz yöneticisindeki yerel kaydı anında temizlemeyebilir. Kurumsal hesaplarda yönetici, kişisel hesapta kullanıcı bu iki görünümü ayrı kontrol etmelidir. Cihaz kaybolduğunda yalnız uzaktan silmeye güvenmek yerine hizmetin aktif oturumlarını, kayıtlı passkey listesini, kurtarma telefonunu ve diğer doğrulayıcıları gözden geçirmek gerekir. Bu yazı belirli bir hizmetin menüsünü evrensel akış gibi sunmaz.

Kurtarma yolu güvenliğin en zayıf halkasına dönüşebilir. NIST, senkronizasyon hesabına yetkisiz erişim ve kurtarmayı ayrı tehdit olarak listeler; birden fazla kimlik doğrulayıcı bağlama, kurtarma bildirimi ve yeni doğrulayıcı eklerken AAL2 doğrulaması gibi önlemler önerir. Kullanıcı açısından pratik sonuç, tek telefona bağımlı kalmamaktır. İkinci onaylı cihaz veya güvenli yerde tutulan cihaza bağlı anahtar erişim yedeği olabilir. Ancak bir passkey’i silmeden önce bu yedeğin gerçekten ilgili hizmette kayıtlı ve çalışır durumda olduğunu resmî hesap ayarından doğrulamak gerekir.

Bir hizmeti değerlendirirken hangi sorular sorulmalı?

Kontrol listesi ürün adından çok uygulama sınırına bakar: Passkey senkronize mi, cihaza bağlı mı; hangi işletim sistemi ve tarayıcı sürümü gerekiyor; kullanıcı doğrulaması zorunlu mu; eski parola veya SMS yolu açık mı; yeni cihaz ekleme ve hesap kurtarma hangi faktörleri istiyor; kullanıcı kayıtlı anahtarları ve aktif oturumları görebiliyor mu; iptal hem hizmette hem anahtar yöneticisinde nasıl yapılıyor? Kuruluşlar ayrıca attestation, yönetilen hesap, cihaz politikası ve hedef AAL düzeyini belgelemeden “FIDO destekli” etiketini yeterli güvence saymamalıdır.

Sonuç, geçiş anahtarının değerini küçültmez. Alan adına bağlı imza, yeniden oynatma direnci ve ortak sırın sunucuda bulunmaması parola kimlik avı modelini önemli ölçüde değiştirir. Fakat gerçek hesap güvenliği işletim sistemi, anahtar yöneticisi ve hizmet politikasının bileşimidir. Bu paket Windows, Apple veya başka bir platformda saldırı testi yapmadı; ekran görüntülerini sürüm sürüm doğrulamadı ve hesap kurtarmayı denemedi. Verilen sürüm sınırları 26 Temmuz 2026’da kontrol edilen resmî belgelere dayanır; canlı yayında ürün sayfaları yeniden kontrol edilmelidir.

Kullanıcı arayüzündeki yüz veya parmak izi simgesi de tek başına hangi anahtar türünün kullanıldığını göstermez. Aynı yerel doğrulama, Windows Hello’da saklanan cihaza bağlı anahtarı, senkronize bir parola yöneticisini ya da yakındaki telefondaki anahtarı açabilir. Teknik destek veya olay incelemesinde yalnız ekrana bakmak yerine anahtarın kaydedildiği konum, hizmetteki kayıt tarihi ve son kullanılan cihaz ayrı kayda geçirilmelidir.