Giriş Kanıtının Adresi: Kimlik Avına Direnç Nasıl Kurulur?

Bir giriş kodunun yalnız bir kez kullanılabilmesi, onu isteyen sayfanın doğru sayfa olduğunu göstermez. Kullanıcı doğru hesabı açmak istediği halde kodunu sahte bir arayüze yazabilir; o arayüz de geçerli çıktıyı gerçek hizmete taşıyabilir. Kimlik avına dirençli doğrulama, bu sorunu yalnız “daha dikkatli bak” uyarısıyla ele almaz. Giriş kanıtının hangi hizmet veya bağlantı için üretildiğini protokolün içine yerleştirir. Böylece kullanıcı niyetinin yanında, kanıtın kullanılabileceği yere ilişkin teknik bir sınır da bulunur.

NIST’in 31 Temmuz 2025’te kesinleşen SP 800-63B-4 yayını bu ayrımı açık biçimde kurar. Belge ağ üzerinden kimlik doğrulama ve doğrulayıcıların yönetimini ele alır. Burada özellikle kimlik avına direnç, yeniden oynatmaya direnç ve eşzamanlanabilir anahtarlar üzerine bölümler inceleniyor. Bilgi kesim tarihi 13 Ekim 2026’dır. NIST rehberinin teknik gereksinimleri, dünyanın bütün hizmetlerine kendiliğinden uygulanmış zorunlu bir hukuk kuralı olarak sunulmuyor. [1][2][3]

Yeni bir kod ile doğru alıcı farklı şeylerdir

Yeniden oynatma saldırısında önceki bir doğrulama mesajı kaydedilip daha sonraki işlemde tekrar kullanılır. NIST, işlemdeki yeniliği göstermek için nonce veya meydan okuma değerleri kullanılmasını anlatır. Eski yanıt yeni işlemin beklediği değeri içermediğinde doğrulayıcı bunu ayırt edebilir. Tek kullanımlık kodlar da belirli koşullarda yeniden oynatmaya dirençli doğrulayıcı örnekleridir. Buna karşılık kullanıcı tarafından elle girilen kodlar, bu nedenle otomatik olarak kimlik avına dirençli sayılmaz.

Sorun yalnız kodun eski olması değildir. Kod geçerli olduğu anda yanlış alıcıya verilirse, sahte doğrulayıcı onu gerçek doğrulayıcıya aktarabilir. NIST’in ayrımı burada önemlidir: Çıktının tek bir oturuma veya doğrulayıcıya bağlanmaması, kısa ömrüne rağmen bir aktarım yolu bırakır. “Bir kez” sözü kullanım sayısıyla ilgilidir; “yalnız bu hizmette” sözü ise kullanım bağlamıyla. Bir sistem ilk özelliğe sahip olup ikinci özelliği sağlamayabilir. [2]

Kriptografik doğrulamada hizmet yeni bir meydan okuma gönderir ve doğrulayıcı araç anahtar üzerindeki denetimini bir yanıtla kanıtlar. Açık anahtarlı örnekte hizmet, ilgili açık anahtarla yanıtı denetler. Kullanıcı her girişte uzun süreli özel anahtarını bir form alanına yazmak yerine, bu anahtarla üretilmiş kanıtı sunar. Bunun güvenliği yalnız “şifre yazılmıyor” görünüşünden değil, yanıtın doğru bağlamda üretildiğinin ve doğrulandığının kontrolünden gelir.

Bağlanabilecek iki bağlam

NIST iki yaklaşımı tanır: Kanal bağlama ve doğrulayıcı adına bağlama. Kanal bağlamada korumalı bağlantıya ait bilgi doğrulama çıktısıyla güçlü biçimde ilişkilendirilir. Belge, istemci kimlik doğrulamalı TLS’yi örnek verir. Böylece bir bağlantıda üretilen kanıtın başka bir bağlantıya aktarılması engellenir. Buradaki TLS ifadesi, tarayıcıda herhangi bir kilit simgesi görmenin tek başına bu özelliği sağladığını söylemez; istemcinin doğrulanmasına katılan belirli bir protokol düzeninden söz edilir.

Doğrulayıcı adına bağlamada ise kanıt, protokol içinde doğrulanmış hizmet kimliğiyle ilişkilendirilir. Alan adı kullanılıyorsa hangi adın kabul edildiğine ilişkin kurallar bulunur. NIST, WebAuthn’ı bu yaklaşımın bir örneği olarak verir: Kullanılan doğrulama sırrı, doğrulanmış alan adına göre seçilir. Başka bir alan adıyla aynı görünen bir arayüz yapmak, onu ilgili hizmetin alan adı haline getirmez. Bu bağlamı koruyan uygulamada sahte sayfa, gerçek hizmette işe yarayacak çıktıyı yalnız görünüşü taklit ederek elde edemez. [2]

İki yöntem de rehberin kimlik avına direnç gereksinimlerini karşılayabilir; belge kanal bağlamayı sertifika sorunları karşısındaki özelliği nedeniyle daha güçlü olarak niteler. Bu karşılaştırma, bütün uygulamaların her bakımdan aynı güvenlik seviyesinde olduğunu söylemez. Farkı anlamak için hangi kanıtın hangi bağlama bağlandığını sormak gerekir. Ürün adını bilmek, tek başına bu sorunun yanıtı değildir.

Anahtarın başka cihaza taşınması

Eşzamanlanabilir doğrulayıcılar, doğrulama anahtarının başka cihazlara kopyalanmasına imkân verir. Bir eşzamanlama altyapısı, örneğin bulut depolama, bu aktarımda görev alabilir. Kullanıcı ek cihazıyla da giriş yapabildiğinde kolaylık artar; ancak anahtarın korunacağı alan da değişir. Artık yalnız ilk cihazın güvenliğine bakmak yeterli değildir. Anahtarın saklandığı altyapıya erişim, yeni cihaz ekleme ve hesap kurtarma süreçleri de doğrulama düzeninin parçalarıdır. [3]

NIST’in ilgili eki, bu anahtarların şifreli biçimde saklanmasını ve eşzamanlama altyapısında anahtarlara erişimin uygun çok faktörlü doğrulamayla korunmasını ister. Özel anahtar işlemlerinin yerel cihazda yapılması da gereksinimler arasındadır. Bulutta yedek bulunması, her girişte imzalama işleminin bulut hizmetine devredildiği anlamına gelmez. Yedekleme ve işlemi yürütme iki farklı görevdir. Kullanıcıya hangi hizmet için anahtar oluşturulduğu ve anahtarın nerelerde eşzamanlandığı hakkında bilgi verilebilmesi, yaşam döngüsünün görünürlüğünü artırır.

Eşzamanlamanın sağladığı kolaylık her güvence düzeyiyle uyumlu değildir. Rehberin AAL2 düzeyinde gerekli koşullar sağlandığında kullanılabilen eşzamanlanabilir anahtarlar, dışarı aktarılamama şartı bulunan AAL3 için aynı biçimde kabul edilmez. Bu, bütün eşzamanlanan anahtarların işe yaramadığı sonucu değildir. Daha sınırlı bir tasarım ayrımıdır: Başka cihaza aktarılabilme özelliğiyle hiçbir biçimde dışarı aktarılamama özelliği aynı anahtara aynı anda yüklenemez.

Dokunmak, doğrulanmak ve yedeklenmek

WebAuthn yanıtındaki kullanıcı hazır bulunma bilgisi, kullanıcının doğrulayıcıyla bir etkileşim gerçekleştirdiğini gösterebilir. Kullanıcının doğrulanmış olduğunu gösteren bilgi ise yerel doğrulama yönteminin kullanılıp kullanılmadığına ilişkindir. Bir donanım aracına dokunmakla yerel kimlik doğrulamasından geçmek, aynı bilgi değildir. NIST bu yüzden hazır bulunma ve kullanıcı doğrulama işaretlerini ayrı ele alır. Çok faktörlü değerlendirme için yalnız dışarıdan görülen hareket değil, yanıttaki doğrulama bilgisi de önemlidir.

Yedeklemeye uygunluk ve yedekleme durumu da ayrılır. Anahtarın eşzamanlanabilecek olması, gerçekten eşzamanlandığı anlamına gelmez. Bu ayrım özellikle kurumun anahtarların hangi cihazlara taşınabildiğini değerlendirdiği durumda anlamlıdır. Ekte, kurum içi kullanım ile halka açık hizmetlerin sınırlı görünürlüğü de ayrı tartışılır. Her kullanıcı cihazını kurum tarafından yönetilen cihaz gibi varsaymak, rehberin kurduğu bu farkı kaybettirir. [3]

Kimlik avına direnç bütün hesap risklerinin yok edilmesi demek değildir. Eşzamanlama hesabının kurtarılması, yetkisiz anahtar paylaşımı veya doğrulayıcının kaybı ayrıca yönetilmelidir. NIST’in ekindeki tehdit tartışması bu sorunları açıkça içerir. Kanıta dayalı sonuç, yeni bir giriş yönteminin başarısını yalnız kaç kod yazıldığıyla ölçmemektir. Kanıtın adresi, tazeliği, yerel kullanıcı doğrulaması ve anahtarın taşınma düzeni birlikte değerlendirilir. Yanlış sayfayı tanıma yükünün bir bölümünü protokole aktarmak değerlidir; fakat anahtarın bütün yaşam döngüsünü koruma işinin yerine geçmez.

Kaynaklar

[1] NIST CSRC, SP 800-63B-4: Digital Identity Guidelines — Authentication and Authenticator Management, kesin sürüm kaydı, 31 Temmuz 2025. https://csrc.nist.gov/pubs/sp/800/63/b/4/final

[2] NIST SP 800-63B-4, Authenticators; kriptografik doğrulama, kimlik avına direnç ve yeniden oynatmaya direnç bölümleri. https://pages.nist.gov/800-63-4/sp800-63b/authenticators/

[3] Aynı yayın, Syncable Authenticators eki; anahtar saklama, yerel işlemler, işaretler, güvence düzeyleri ve yaşam döngüsü riskleri. https://pages.nist.gov/800-63-4/sp800-63b/syncable/

Bilgi kesim tarihi: 13 Ekim 2026. Kaynak erişimi ve olgu kontrolü: 14 Ekim 2026. Özgün teknik açıklama; doğrudan alıntı veya hukuki uygunluk değerlendirmesi içermez.