Passkey Artık Default: Asıl İş Login Değil, Recovery

Passkey, gelişmiş seçenek olmaktan çıkıp varsayılan giriş yöntemi haline geldi. Amazon Cognito managed login içinde passkey ile girişi (yeni sekmede açılır) Kasım 2024’ten beri sunuyor. Microsoft Entra ID Eylül 2026’da passkey’i varsayılan olarak açmaya başlıyor; arkalarındaki WebAuthn spesifikasyonu da Ağustos 2026’da Level 3 ile W3C Recommendation (yeni sekmede açılır) statüsüne ulaştı. E-posta, şifre ve SMS OTP ile çalışan bir login akışının sahibiyseniz geçişin küçük yarısı giriş tarafı: bir feature plan kararı, tek bir yapılandırma bloğu ve birkaç API çağrısı. Büyük yarı, passkey ortada olmadığında ne olacağı; çünkü giriş sertleştikçe saldırı trafiği hesap kurtarmaya, yani recovery tarafına kayıyor. Önce Cognito kurulumu, sonra asıl ağırlığı hak eden kısım: SMS’in yerini alan recovery merdiveni.

SMS OTP Neden Devreden Çıkıyor#

Bugünkü yığının üzerindeki baskı üç ayrı yönden aynı anda geliyor.

İlki standart tarafı. NIST SP 800-63B (yeni sekmede açılır), güncel dördüncü revizyonunda, telefon şebekesi (PSTN) üzerinden out-of-band doğrulamayı kısıtlı (restricted) authenticator sınıfına koyuyor. Kısıtlı statü, SMS ya da sesli kod kullanmayı sürdüren bir kurumun riski değerlendirmesini, kullanıcılara alternatif sunmasını ve elinde bir geçiş planı tutmasını gerektiriyor. Yasak sayılmaz; pratikte ise SMS’i sıradan bir varsayılandan, her denetimde açıklama isteyen bir bulguya çeviriyor.

İkincisi platform tarafı. Microsoft, kurumsal kimlik (workforce) ürünü Entra ID için bir kullanımdan kaldırma takvimi (yeni sekmede açılır) yayımladı: 1 Eylül 2026’dan itibaren passkey otomatik etkinleştirmeyle varsayılan hale geliyor, 1 Şubat 2027’de de Microsoft’un sağladığı SMS ve sesli arama teslimatı tamamen kapanıyor. Uyumluluk gereksinimi olan segmentlere bırakılan yol, müşterinin kendisinin yöneteceği bir telekom sağlayıcısı. Kapsama dikkat: bu karar workforce kimliği için geçerli; tüketici ürünleri dengeyi farklı kuruyor. Alternatifler bölümü bu ayrıma geri dönüyor.

Üçüncüsü saldırı kaydı. Scattered Spider hakkındaki ortak güvenlik bülteni (AA23-320A) (yeni sekmede açılır), login formuna hiç uğramayan saldırıları anlatıyor: saldırgan destek masasını ikna edip şifre sıfırlatıyor ya da MFA kaydını kendi cihazına taşıtıyor; olmadı, numarayı SIM swap ile (numaranın başka bir SIM’e taşınması) üzerine alıyor. Sonra da normal akıştan giriş yapıyor. Zincirin hiçbir halkası şifre gücüne ya da OTP entropisine dokunmuyor.

Passkey kurulumları aynı baskıyı bir adım öteye taşıyor. Unit 42’nin Ağustos 2026’da yayımladığı araştırma (yeni sekmede açılır), Windows üzerinde Google Password Manager’ın arkasındaki credential deposuna karşı gösterilen üç tekniği anlatıyor: Pass-ta-key, Silver Pass-ta-key ve Golden Pass-ta-key. Üçünün de ön koşulu, kurbanın makinesinde sıradan kullanıcı yetkisiyle çalışan bir zararlı; üçü de FIDO protokolünü olduğu gibi bırakıp credential deposunun yeniden kayıt (re-registration) ve onboarding yollarından ilerliyor. Rollout planlayan bir ekip için bu araştırma, baskının bir sonraki adresinin haritası: enrollment, yeniden kayıt ve recovery.

Cognito’da Passkey’i Açmak#

Cognito tarafında işin giriş yarısı kısa: üç ön koşul, ardından tek bir yapılandırma çağrısı.

Passkey, Lite dışındaki bütün user pool feature planlarında (yeni sekmede açılır) mevcut. Yeni pool’lar varsayılan olarak Essentials ile açılıyor; mevcut bir pool UpdateUserPool üzerindeki UserPoolTier alanıyla taşınıyor ve Lite bir pool’da WebAuthn yapılandırma denemesi FeatureUnavailableInTierException ile geri dönüyor. Plan değişikliği aylık aktif kullanıcı başına faturayı değiştirdiği için, kalabalık bir tabanı taşımadan önce güncel tarifeyi Cognito fiyatlandırma sayfasından (yeni sekmede açılır) kontrol etmek gerekiyor. İkinci koşul akış tipi: passkey yalnızca seçim tabanlı (choice-based) kimlik doğrulama akışında (yeni sekmede açılır) çalışıyor, dolayısıyla app client’ın izinli akışlarına ALLOW_USER_AUTH ekleniyor. Üçüncüsü, faktörün pool’un sign-in policy’sine yazılması:

"Policies": {
  "SignInPolicy": {
    "AllowedFirstAuthFactors": ["PASSWORD", "WEB_AUTHN", "EMAIL_OTP"]
  }
}

Konsolda Password seçeneği her zaman açık ve kapatılamıyor; API tarafında ise PASSWORD listenin zorunlu bir üyesi değil. SMS_OTP kabul edilen dördüncü değer ve buradaki varsayılan onu bilinçli olarak dışarıda bırakıyor. WebAuthn davranışının kendisi SetUserPoolMfaConfig üzerinden ayarlanıyor:

"WebAuthnConfiguration": {
  "RelyingPartyId": "auth.example.com",
  "UserVerification": "required",
  "FactorConfiguration": "MULTI_FACTOR_WITH_USER_VERIFICATION"
}

Üç alandan ikisi güvenlik duruşunu taşıyor. UserVerification, authenticator’ın imza atmadan önce sahibini yerelde doğrulamasının (parmak izi, yüz ya da PIN) zorunlu olup olmadığını belirliyor. Konsolda da API’de de varsayılan preferred; preferred, kullanıcı doğrulama yeteneği hiç olmayan authenticator’ların kaydına izin veriyor ve girişlerin bu kontrol olmadan tamamlanmasına ses çıkarmıyor. required ise kontrolü şart koşuyor. Ödünleşim şu: required, kullanıcı doğrulaması yapamayan eski güvenlik anahtarlarını dışarıda bırakıyor ve bazı donanımlarda fazladan bir istem çıkarıyor; karşılığında passkey bir MFA gereksinimini karşılayabiliyor ve assertion’daki UV bayrağı pool’un fiilen uyguladığı bir kontrole dönüşüyor. Bu takas Cognito’da başka platformlardakinden daha kritik, çünkü AWS’nin belgelediği üzere (yeni sekmede açılır) Cognito şu anda attestation doğrulamayı desteklemiyor; attestation, authenticator’ın kendi modeli ve menşei hakkındaki imzalı beyanı demek. Unit 42’nin relying party’lerden istediği tek bir önlem var: kullanıcı doğrulamasını zorunlu tutmak ve her authentication yanıtındaki UV bayrağını denetlemek. Rehberin attestation tarafı ise relying party’lere değil credential yöneticilerine sesleniyor. Cognito’da user pool’un uygulayabildiği yarı bu yüzden UV kontrolü, bu da onu kullanmak için güçlü bir gerekçe.

FactorConfiguration, passkey’in ne olarak sayılacağını belirliyor. SINGLE_FACTOR altında tek bir faktör; kullanıcı doğrulamalı bir passkey’in MFA gereksinimini tek başına karşılaması yalnızca MULTI_FACTOR_WITH_USER_VERIFICATION ile mümkün. Yöne dikkat: Cognito’da passkey her zaman birinci faktördür. Şifreyle girişin ardından ikinci adım olarak passkey isteyen bir akış yok.

Özel arayüzden giriş tek bir istek:

{
  "AuthFlow": "USER_AUTH",
  "AuthParameters": {
    "USERNAME": "user@example.com",
    "PREFERRED_CHALLENGE": "WEB_AUTHN"
  },
  "ClientId": "1example23456789"
}

Cognito buna, parametreleri tarayıcıdaki navigator.credentials.get() çağrısının seçeneklerini taşıyan bir WEB_AUTHN challenge’ı ile cevap veriyor; imzalı sonuç RespondToAuthChallenge içinde CREDENTIAL cevabı olarak geri gidiyor. PREFERRED_CHALLENGE gönderilmezse dönen şey SELECT_CHALLENGE ve o kullanıcının sahip olduğu faktörlerin listesi; managed login’in ekranda düğme olarak çizdiği liste de aynısı. Bunun ötesindeki pool temelleri (custom akışlar, federasyon, çok kiracılılık) Cognito derinlemesine incelemesinde anlatılıyor; burada geçen WebAuthn terminolojisi ise güvenlik sözlüğünde tanımlı.

Relying Party ID Seçimi#

Relying party, bir WebAuthn credential’ının hangi hizmete bağlı olduğunu söyler; RelyingPartyId da bu bağın kurulduğu alan adıdır. Cognito, managed login branding ile birlikte özel alan adı varsa varsayılanı özel alan adına, yoksa prefix alan adına çeker. Public suffix listesinde olmayan her alan adını kabul eder. Belgelenmiş tek istisna şu: özel alan adı olan bir pool, kimlik doğrulamayı managed login ya da klasik hosted UI üzerinden yürütüyorsa, relying party ID o özel alan adının tam nitelikli hali olmak zorunda.

Birden fazla tescilli alan adına yayılmış ürünlerde bir mekanizma daha gerekiyor, çünkü her passkey tam olarak tek bir relying party ID’ye bağlanıyor. WebAuthn Level 3 bu durum için Related Origin Requests (yeni sekmede açılır) mekanizmasını standartlaştırdı: RP ID’nin alan adı /.well-known/webauthn altında bir izin listesi yayımlıyor, tarayıcılar da credential’ı listedeki origin’lerde tanıyor. WebAuthn, istemcilerin en az beş tescilli alan adı etiketini desteklemesini şart koşuyor; pratikte beşin üstüne çıkan tarayıcı yok, bu yüzden geniş bir ülke alan adı portföyü yine gruplama istiyor. Cognito ayrıca native mobil uygulamaların origin kontrolleri için ilişkilendirme dosyasını relying party alan adında arıyor.

Mevcut Kullanıcılara Passkey Kaydettirmek#

Özelliği açmak kimseyi kaydetmiyor. Managed login (yeni sekmede açılır) passkey kurulumunu yalnızca sign-up sırasında öneriyor; rollout’tan önce kaydolmuş kullanıcılar ve yönetici tarafından açılmış hesaplar bu ekranı hiç görmüyor. Cognito ayrıca passkey kaydına izin vermeden önce en az bir tamamlanmış giriş şart koşuyor. Dolayısıyla mevcut tabanın enrollment’ı, geçişin içinde kendi başına bir proje ve iki uygulama yolu var.

Managed login kullanılıyorsa yol bir yönlendirme. Kullanıcı şifre ya da e-posta OTP ile giriş yaptıktan sonra tarayıcı, https://<alan-adiniz>/passkeys/add?client_id=<id>&redirect_uri=<kodlanmis-uri> adresindeki barındırılan kayıt sayfasına gönderiliyor; Cognito bu sayfayı yalnızca kimliği doğrulanmış oturuma sunuyor. Ürün kararı, bu yönlendirmenin ne zaman ve ne kadar ısrarla tetikleneceği; aşağıdaki credential sayısı kontrolü bu kararı besleyebiliyor.

Özel arayüzde kayıt, tarayıcının credential yöneticisi etrafında üç çağrıdan oluşuyor. Bu kod tarayıcıda çalışıyor; aynı SDK istemcisi giriş formunu barındıran sayfada da duruyor:

import {
  CognitoIdentityProviderClient,
  StartWebAuthnRegistrationCommand,
  CompleteWebAuthnRegistrationCommand,
} from "@aws-sdk/client-cognito-identity-provider";

const client = new CognitoIdentityProviderClient({ region: "eu-central-1" });

// Giriş sonrasında tarayıcıda çalışır. Access token'da
// aws.cognito.signin.user.admin scope'u bulunmalıdır.
export async function registerPasskey(accessToken: string): Promise<void> {
  const { CredentialCreationOptions } = await client.send(
    new StartWebAuthnRegistrationCommand({ AccessToken: accessToken }),
  );

  // WebAuthn Level 3 JSON yardımcıları; elle base64url dönüşümü gerekmez
  const credential = (await navigator.credentials.create({
    publicKey: PublicKeyCredential.parseCreationOptionsFromJSON(
      CredentialCreationOptions as PublicKeyCredentialCreationOptionsJSON,
    ),
  })) as PublicKeyCredential;

  // Boş gövdeli HTTP 200, credential'ın kaydedildiği anlamına gelir
  await client.send(
    new CompleteWebAuthnRegistrationCommand({
      AccessToken: accessToken,
      Credential: credential.toJSON(),
    }),
  );
}

Hesap ayarları sayfasının yönetim yüzeyi de aynı API ailesinden geliyor. ListWebAuthnCredentials (yeni sekmede açılır) her credential’ın kimliğini, görünen adını, transport bilgisini ve oluşturulma zamanını döndürüyor; DeleteWebAuthnCredential bir tanesini siliyor. İkisi de kullanıcının access token’ı ve aynı scope ile yetkilendiriliyor; bir kullanıcı en fazla 20 passkey tutabiliyor. Liste çağrısı aynı zamanda rollout’un dümeni: her başarılı girişten sonra sayıya bakın; sıfır passkey kayda, tek passkey ikinci credential’a yönlendirir. Bir sonraki bölüm bu deseni politikaya çeviriyor.

Recovery Merdiveni#

Geçişin SMS’i gerçekten kaldırıp kaldırmayacağına, yoksa yan kapıdan geri mi getireceğine recovery tasarımı karar veriyor. İşleyen tasarım dört basamaklı bir merdiven; ürün yatırımı da en üst basamakta yoğunlaşıyor, çünkü erken çözülen her vaka alttaki pahalı basamaklara hiç inmiyor.

Basamak 0: İkinci Credential’ı Baştan Kaydettirmek#

En ucuz recovery, hiç çalışmayan recovery’dir. FIDO Alliance’ın hesap kurtarma rehberi (yeni sekmede açılır) aynı noktayı 2019’dan beri söylüyor: kaybolan authenticator’ın birincil önlemi, kayıtlı ikinci bir authenticator’dır. Somut karşılığı, ikinci passkey’i ilkinin oluşturulduğu oturumda ya da bir sonraki girişte istemek. Telefon artı dizüstü çoğu durumu karşılıyor; telefon artı taşınabilir güvenlik anahtarı da kalanını. Cognito’da ikinci credential’ı zorunlu kılan bir ayar yok, dolayısıyla kontrol ListWebAuthnCredentials üzerinden uygulama kodunda yaşıyor. Maliyeti tek bir istem ekranı ve bu, rollout’un tamamında getirisi en yüksek ekran.

Senkronize passkey’ler aynı sorunu platform katmanında çözüyor gibi görünüyor ve ilk bakışta gerçekten çözüyor: platform hesabı üzerinden senkronlanan bir credential, tek bir cihazın kaybını sorunsuz atlatıyor. Bedeli ise yoğunlaşma. Unit 42’nin Golden Pass-ta-key tekniği, bir Google hesabındaki bütün senkronize passkey’leri koruyan güvenlik alanı sırrını (security domain secret) hedef alıyor. Araştırma, bu sır bir kez sızdığında onu döndürmenin ya da iptal etmenin bir yolu bulunmadığını aktarıyor; ön koşul yine kullanıcının makinesindeki zararlı. Relying party için makul duruş şu: senkronize credential’ları memnuniyetle kabul edin, yine de kullanıcının kendi kontrolündeki ikinci credential’ı isteyin; çünkü riski üzerine akıl yürütebildiğiniz credential o.

Basamak 1: Self-Servis Fallback Olarak E-posta OTP#

İkinci credential’ı olmayan ve hassas bir varlık taşımayan kullanıcıda self-servis, destek kuyruğunu devreden çıkarır. Buradaki standart fallback, yukarıdaki sign-in policy’de zaten duran EMAIL_OTP. E-posta OTP phishing’e dayanıklı değildir; giriş sayfasını proxy’leyen bir aracı, kodu herhangi bir kod gibi yakalar. Buna karşılık SIM swap’a ve numara taşımaya karşı bağışıktır ve çoğu SaaS ürününde posta kutusu zaten hesabın fiili kökü konumundadır, çünkü şifre sıfırlamaları bugün de oraya düşer. Bu basamak, recovery’yi hesabın zaten bağımlı olduğu tek zayıf köke konsolide ediyor; merdivenin geri kalanı da önemli hesaplarda konsolidasyonun tek başına yetmediği için var.

Basamak 2: Hassas Hesaplarda Yeniden Doğrulama#

Ürünün çizdiği bir hassasiyet çizgisinin üzerinde, bir yere kod göndermek kabul edilebilir bir cevap olmaktan çıkıyor, çünkü kod, kanalının en zayıf özelliğini miras alıyor. Daha güçlü cevap, kimlik ispatını yeniden çalıştırmak: ürünün kayıt sırasında ya da sonrasında doğruladığı ne varsa. Ürüne göre bu, kayıtlı bir ödeme yöntemini teyit etmek, kurtarmayı başka bir cihazda hâlâ açık olan oturumdan onaylatmak, alanın zaten gerektirdiği yerde belge kontrolü ya da B2B müşterinin kendi yöneticisi üzerinden teyit olabilir. Bu, FIDO kurtarma modelinin ikinci yarısı: recovery’den kaçınmak için birden fazla authenticator, kaçınılamadığında ise yeniden kimlik ispatı. Kısıt ise envanter. Basamak 2 ancak üründe yeniden çalıştırılacak ispat sinyalleri varsa var olur; ilkini kurmak da ürün işidir. Envanter sorusu bu yüzden, ilk kilitlenme vakası dayatmadan önce geçiş planında yer almalı.

Basamak 3: Ayrıcalıklı Bir İşlem Olarak Destekli Recovery#

İnsan destekli bir yol, kimse tasarlamasa da vardır; AA23-320A’daki destek masası deseni, tasarlanmamış olanın neye dönüştüğünü gösteriyor. Tasarlamak, destekli sıfırlamaya bir production deploy ciddiyeti vermek demek: sistemde kayıtlı bir iletişim noktasına dışarıdan geri arama, sıfırlama işlemeden önce zorunlu bir bekleme süresi ve kayıtlı her cihaza ve adrese bildirim. Üstüne, kimliği doğrulayan ile sıfırlamayı yürütenin aynı kişi olmamasını sağlayan görev ayrımı ve hepsini kapsayan bir denetim izi geliyor. Cognito tarafındaki temel taşlar AdminSetUserPassword ve AdminResetUserPassword; değerli olan her şey bu çağrıların etrafındaki süreçte duruyor. Ödünleşim açık: bu basamağın güvence tavanı da vaka başına maliyeti de saldırgan ilgisi de en yüksek; geçiş planı bunu bir süreç kalemi olarak bütçelemeli, düğmenin kendisi en küçük kalem.

Recovery Kodlarını Kendiniz Yazmak#

Cognito’da hazır bir recovery kodu özelliği yok, dolayısıyla tek kullanımlık kodlar bir geliştirme kararı; serbestlik de onları yanlış yapmayı kolaylaştıran şey. Kurallar şifre saklamayı aynen izliyor: her kodu hash’leyin, tek kullanımı zorlayın, düz metni yalnızca üretim anında bir kez gösterin, hash’leri ve kalan adedi saklayın, kullanım denemelerini en az ForgotPassword kadar sıkı hız sınırına bağlayın. Basılı tek kullanımlık kodlar teknik bir kitlede Basamak 1’i iyi taşır; geniş bir tüketici tabanında ise kayda değer bir bölümün hiçbir yere kaydedilmeyeceğini baştan kabul edin. Kurallardan herhangi birini atlamak, ortada fiilen ikinci ve daha zayıf bir şifre bırakır.

Basamaklar arasındaki yönlendirme, olaydan olaya birikmiş koşullar yerine açık bir karar ağacını hak ediyor:

SMS bu merdivenin hiçbir yerinde görünmüyor. Yalnızca yazılı bir düzenleyici ya da operasyonel gereksinimin kapsadığı belirli bir kullanıcı segmenti için geri gelir; alternatifler bölümü bu durumu kendi terazisinde ele alıyor.

Cognito’da Recovery Kanalı Çakışması#

Platforma özgü bir etkileşim kendi bölümünü hak ediyor, çünkü doğru yapılandırılmış pool’ların SMS’e geri sürüklendiği nokta burası.

AccountRecoverySetting (yeni sekmede açılır), ForgotPassword kodlarının nereye gideceğini belirliyor. verified_email, verified_phone_number ya da admin_only değerlerini birer öncelikle kabul ediyor ve Cognito kodu tam olarak tek bir hedefe gönderiyor: o kullanıcı için mevcut en yüksek öncelikli olana. Ayar hiç verilmezse eski davranış önce doğrulanmış telefon numarasını deniyor, e-postayı yalnızca telefon niteliği olmayan kullanıcılarda kullanıyor; bu da geçişin istediğinin tam tersi. Bu yüzden 1. önceliğe verified_email yazmak rollout’un parçası ve bu ayar, MFA yapılandırmasıyla belgelenmiş bir biçimde çakışıyor: bir kullanıcının MFA kanalı, aynı kullanıcının recovery kanalı olamıyor.

• MFA tercihi e-posta OTP olan kullanıcı, şifre sıfırlama kodunu e-postayla alamaz.
• MFA’sı SMS olan kullanıcı, kodu SMS ile alamaz.
• AccountRecoverySetting tanımlıyken ve kullanıcıda SMS MFA yapılandırılmışken, SMS o kullanıcı için recovery seçeneği olmaktan tamamen çıkar.

Geçerli hiçbir hedefi kalmayan kullanıcı, ForgotPassword çağrısından InvalidParameterException alır; kullanıcıya yansıyan hali, ilerleyemeyen bir “şifremi unuttum” ekranıdır. AWS’nin belgelediği çözümler, ikinci recovery seçeneği olarak SMS eklemek ya da hem email hem phone_number niteliklerini zorunlu kılıp MFA dışı bir kanalın her zaman var olmasını sağlamak. Bunu ilk bölümle yan yana okuyun: platformun kendi rehberliği, mekanik uygulandığında, NIST’in kısıtladığı kanalı geri getiriyor. Rehberlik kendi ölçütünde doğru şeyi gözetiyor, yani kullanıcıların kilitli kalmamasını. Geçişle tutarlı çözüm ise çakışmayı bir tasarım sinyali olarak okumak; çözüm MFA kanalına göre ikiye ayrılıyor. İkinci bir iletişim niteliği yalnızca MFA’sı e-posta olmayan kullanıcılara yarıyor: onlarda doğrulanmış e-posta adresi recovery için temiz bir hedef oluyor. MFA’sı e-posta OTP olan kullanıcıda ise dışlama e-postanın kendisini izliyor; eklenen telefon numarası kodları yeniden SMS’e yönlendirmekten başka bir şey yapmıyor. O segmenti Basamak 2 yeniden doğrulamaya taşıyıp kod göndermeyi tamamen bırakın.

Hemen yanında belgelenmiş bir etkileşim daha var. OTP birinci faktörleri, pool seviyesinde zorunlu MFA ile uyumsuz; MFA opsiyonelken bile MFA tercihi tanımlamış bir kullanıcı OTP birinci faktörüyle giriş yapamıyor. E-posta OTP’yi açtıktan sonra MFA’yı zorunluya çeviren bir pool, kendi fallback’ini bozar. Operasyonel tarafta ForgotPassword kodu bir saat geçerli kalıyor ve AWS, risk sinyallerine bağlı olarak kullanıcı başına saatte 5 ile 20 arasında istek ya da deneme hakkı belgeliyor; kendi yazdığınız recovery yolu da bu sınırlara uymalı.

Çakışmanın Ötesindeki Tuzaklar#

Bu tür planlar gözden geçirilirken dört tuzak daha öne çıkıyor.

UserVerification alanını preferred bırakmak. Konsolda da API’de de sessiz varsayılan bu. Kayıt, kullanıcısını doğrulayamayan authenticator’ları kabul eder, girişler doğrulama olmadan tamamlanır ve passkey MULTI_FACTOR_WITH_USER_VERIFICATION kapsamına girmez olur. Rollout’un satın alması beklenen güvence hiç gelmez ve hiçbir şey sizi uyarmaz.

Kullanıcı başına tek credential ile yayına çıkmak. Basamak 0 o zaman kimseyi korumaz ve kaybolan ya da sıfırlanan her cihaz en pahalı basamağa düşer. İkinci credential istemi tek bir ekrana mal olur; atlanırsa maliyet, kaybolan her cihaz için destek kuyruğuna taşınır.

Passkey silmeyi sıradan bir ayar gibi ele almak. Son credential’ı silmek, şifre değişikliğiyle aynı sınıfta bir güvenlik olayıdır ve Unit 42’nin bulguları yeniden kaydı yeni saldırı yüzeyinin merkezine koyuyor. Son passkey’in silinmesi yeniden doğrulamayı ve girişin bundan sonra nasıl görüneceğine dair net bir açıklamayı hak eder; silmeyi izleyen taze bir kayıt da hesabın diğer kanallarına bildirim gerektirir.

Rollout’a Lite planda başlamak. WebAuthn ile ilgili hiçbir şey orada çalışmaz ve hata, yapılandırma anında FeatureUnavailableInTierException olarak görünür. Plan değişikliği, geçişin kritik yolunda ve maliyet tahmininde, yukarıdaki yapılandırmaların hepsinden önce durmalı.

Recovery Yolunu Ölçümlemek#

Giriş sertleştiğinde ilginç trafik recovery tarafına taşınır, dolayısıyla ölçümleme rollout yayına çıkmadan önce hazır olmalı. Bunların çoğu, kendi recovery uç noktalarınızın ve API çağrılarınızın etrafında uygulama seviyesinde sayaçlar. Baştan bağlamaya değer küme:

• İki ya da daha fazla kayıtlı credential’ı olan aktif kullanıcı payı, doğrudan ListWebAuthnCredentials üzerinden. Dayanıklılık sayısı budur; tek başına enrollment payı rollout’u olduğundan iyi gösterir.
• Bin aktif kullanıcı başına recovery başlatma sayısı ve kanala göre tamamlanmalar. Tamamlanmalardaki SMS payı, geçişin sıfıra indirmek için var olduğu rakamdır.
• ForgotPassword üzerindeki InvalidParameterException oranı. Sıfırın üstündeki her değer, geçerli recovery hedefi olmayan bir kitle demektir; çakışma bölümünün anlattığı çıkmaz tam olarak bu.
• Birkaç gün içinde yerine yenisi kaydedilmeyen passkey silmeleri. Buradaki kalıcı bir değer, saldırı araştırmasının gösterdiği yeniden kayıt yüzeyine işaret eder.
• Rollout’un her aşamasından önce ve sonra giriş başarısızlık oranı; giriş yarısının regresyon alarmı.

Her sayının ucunda bir karar var: iki credential payı ikinci credential isteminin ne kadar ısrarcı olacağını, SMS tamamlanma payı son telekom bağımlılığının ne zaman biteceğini, exception oranı da iletişim niteliği zorunluluğunun yayına alınıp alınamayacağını belirler.

Ciddiye Alınması Gereken İki Alternatif#

Yukarıdaki her varsayılanın bir esnetme durumu var. Tablo bunları topluyor; geçiş tartışmalarına en çok konu olan iki alternatif de altında ayrıca ele alınıyor.

Karar	Varsayılan	Ne zaman esnetilir	Esnetmenin bedeli
UserVerification	required	Filoda UV yeteneği olmayan donanım anahtarları varsa	Passkey MFA sayılmaz ve Cognito’da uygulanabilen tek Unit 42 önlemi de gider
FactorConfiguration	MULTI_FACTOR_WITH_USER_VERIFICATION	Ayrı bir MFA adımı uygulama kontrolünde kalacaksa	Kurulacak, test edilecek ve desteklenecek daha fazla akış
AllowedFirstAuthFactors	PASSWORD, WEB_AUTHN, EMAIL_OTP	Regüle bir segment telekom kanalı gerektiriyorsa	SMS_OTP geri gelir, kısıtlı authenticator yükümlülükleriyle birlikte
AccountRecoverySetting	1. öncelikte verified_email	E-posta o kullanıcının MFA kanalıysa	Ya ikinci seçenek olarak SMS ya da segment için Basamak 2 yeniden doğrulama
Feature plan	Essentials	Passkey gerçekten kapsam dışıysa	Lite’ta passkey desteği hiç yok
Kullanıcı başına credential	Ürünün istemle teşvik ettiği iki adet	Kiosk ya da ortak cihaz kullanan kitleler	Cihaz kaybı doğrudan Basamak 3’e düşer

SMS OTP’yi Tutmak#

SMS lehine en güçlü argüman, halihazırda çalışıyor olması: kurulu, kullanıcılar alışkın ve e-posta hesabı ele geçirildiğinde ayakta kalıyor; e-posta OTP bunu yapamıyor. Google’ın tüketici rehberliği de bu tarafta duruyor; passkey kullanıcı yolculuğu dokümantasyonu (yeni sekmede açılır), bütün credential’larını silen kullanıcının içeri dönebileceği bir fallback kanalını korumayı öneriyor. Büyük ölçekli bir tüketici ürününde baskın hata modu kilitlenme; Google’ın önerisi ağırlığı ona göre veriyor. Microsoft ise terazinin diğer kefesine bakıyor: workforce kimliğinde baskın hata modu hesabın ele geçirilmesi. Bu yüzden kendi SMS teslimatını kökten kaldırıyor. E-posta kökü üzerine kurulu bir B2B SaaS bu çizginin Microsoft tarafına daha yakın yaşıyor: hesaplar kurumsal veri taşıyor ve destek ekibi, AA23-320A’nın belgelediği sosyal mühendislik senaryosuna aynı şekilde açık. Dolayısıyla esnetme ancak yazılı bir düzenleyici ya da operasyonel gereksinim varsa geçerli; o zaman da ilgili kullanıcı segmentleriyle sınırlı kalır ve risk kararı kayıt altına alınır. Microsoft’un kendi müşterilerine müşteri yönetimli telekom sağlayıcıları üzerinden sunduğu istisna da tam olarak bu.

Fallback Olarak Magic Link#

Magic link, e-posta OTP ile aynı şeyi bir adım daha az sürtünmeyle vadediyor: posta kutusuna sahip olmak tek bir tıklamaya dönüşüyor. Buradaki fallback rolü için aleyhte iki nokta var. Birincisi, Cognito’da magic link bir geliştirme işi. Giriş bağlantısı üreten yerleşik bir birinci faktör yok; magic link demek custom authentication demek: Lambda tetikleyicileriyle CUSTOM_AUTH, passkey’in gerektirdiği seçim tabanlı USER_AUTH akışının yanında paralel, istemci tabanlı bir akış olarak. E-posta OTP ise aynı akışın içinde yerleşik bir faktör, AllowedFirstAuthFactors içinde tek bir dize. İkincisi, güvenlik özellikleri bu fazladan emeğin karşılığını vermiyor. Bağlantı, posta kutusundaki bir bearer sırrıdır, bir kod kadar phishing’e açıktır ve kendi teslimat dertlerini getirir. URL’leri önden açan posta güvenliği ağ geçitleri, tek kullanımlık bağlantıyı kullanıcı görmeden tüketebilir. Bağlantı ayrıca çoğu zaman isteği yapan tarayıcı bağlamından farklı bir bağlamda açılır; bu da oturum sürekliliğini bozar. Custom auth akışlarına zaten yatırım yapmış bir ekip, deneyim tutarlılığı için magic link’i makul biçimde koruyabilir. Bu geçişteki recovery fallback’i olarak ise e-posta OTP ile aynı güven köküne, daha yüksek geliştirme ve operasyon maliyetiyle oturur.

Varsayılanın Sınırları#

Hesapları bugün zaten e-posta üzerinden kurtarılan bir SaaS ürünü için yukarıdaki varsayılan geçerli: birincil faktör olarak passkey ve zorunlu kullanıcı doğrulaması, erken istenen ikinci credential, self-servis taban olarak e-posta OTP, üstünde yeniden doğrulama ve ayrıcalıklı bir işlem olarak yürütülen destekli recovery. İki yerde esner. Kilitlenme riskinin ele geçirilme riskine baskın geldiği ölçekteki tüketici ürünleri, riski tasarımda açıkça yazmak koşuluyla daha geniş bir fallback tutabilir; yazılı telekom gereksinimi olan regüle bir segment de SMS’i yalnızca o kullanıcılarla sınırlı tutar, bir adım ötesine taşımaz. İşe yarayan ilk adım, yukarıdaki bütün API çağrılarından önce gelir: relying party ID’yi sabitleyin ve recovery merdivenini yazıya dökün, çünkü ikisi de ilk credential oluştuğu anda katılaşır.

Kaynaklar#

• Passkeys by default and retirement of Microsoft-provided SMS and voice authentication (yeni sekmede açılır) - Microsoft’un Entra ID takvimi: Eylül 2026’da varsayılan passkey, Şubat 2027’de Microsoft’un sağladığı SMS ve sesli teslimatın kullanımdan kaldırılması.
• Pass the Passkey: A Novel Attack Surface in Passwordless Authentication (yeni sekmede açılır) - FIDO protokolünü olduğu gibi bırakıp credential deposunun yeniden kayıt yolunu hedefleyen üç teknik üzerine Unit 42 araştırması.
• Authentication flows in Amazon Cognito user pools (yeni sekmede açılır) - Passkey ile giriş, relying party ID kuralları, kullanıcı doğrulama ayarları, yalnızca sign-up’ta çıkan passkey istemi ve kullanıcı başına credential sınırı için AWS referansı.
• Configure authentication methods for managed login (yeni sekmede açılır) - User pool ayarlarının managed login’in çizdiği giriş seçeneklerine nasıl dönüştüğü.
• Manage authentication methods in AWS SDKs (yeni sekmede açılır) - Seçim tabanlı USER_AUTH akışı, mevcut challenge adları ve AllowedFirstAuthFactors sign-in policy’si.
• Passwords, account recovery, and password policies (yeni sekmede açılır) - Cognito’nun AccountRecoverySetting modeli ve kullanıcının MFA kanalının aynı zamanda recovery kanalı olamayacağı kuralı.
• ListWebAuthnCredentials API reference (yeni sekmede açılır) - Passkey yönetim ekranının arkasındaki API; access token yetkilendirme modeli ve yanıt alanlarıyla birlikte.
• Amazon Cognito user pool feature plans (yeni sekmede açılır) - Lite, Essentials ve Plus planlarının kapsamı; passkey ile giriş için plan gereksinimi dahil.
• Amazon Cognito pricing (yeni sekmede açılır) - Her feature plan için güncel aylık aktif kullanıcı başına fiyatlandırma.
• Amazon Cognito now supports passwordless authentication (yeni sekmede açılır) - Cognito’da passkey, e-posta OTP ve SMS OTP girişinin Kasım 2024 lansman duyurusu.
• Web Authentication: An API for accessing Public Key Credentials Level 3 (yeni sekmede açılır) - Passkey’lerin arkasındaki W3C spesifikasyonu; kullanıcı doğrulama, relying party tanımlayıcıları ve yukarıdaki kayıt kodunda kullanılan JSON serileştirme yardımcıları dahil.
• Allow passkey reuse across your sites with Related Origin Requests (yeni sekmede açılır) - Tek bir relying party ID’nin /.well-known/webauthn izin listesiyle birden fazla alan adına nasıl hizmet ettiği ve tarayıcıların uyguladığı sınırlar.
• FIDO Alliance Recommended Account Recovery Best Practices (yeni sekmede açılır) - Recovery merdiveninin üzerine kurulduğu iki parçalı model: önce birden fazla authenticator, kaçınılmazsa yeniden kimlik ispatı.
• NIST SP 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management (yeni sekmede açılır) - PSTN üzerinden out-of-band doğrulamayı kısıtlı sınıfına koyan ve yerine geçecek authenticator’ın bağlanma şartlarını tanımlayan rehber.
• Scattered Spider (CISA advisory AA23-320A) (yeni sekmede açılır) - Destek masası sosyal mühendisliğini, SIM swap’ı ve MFA sıfırlama istismarını hesaplara giriş yolu olarak belgeleyen ortak güvenlik bülteni.
• Passkeys user journeys (yeni sekmede açılır) - Google’ın passkey oluşturma istemlerinin zamanlaması ve tüketici hesabının neden çalışan bir fallback yoluna ihtiyaç duyduğu üzerine tasarım rehberi.