Passkey nedir, kurumsal geçiş nasıl planlanır?

Passkey nedir ve parolalardan farkı nedir?

Passkey, bir kullanıcı hesabı için üretilen açık anahtar (public key) çiftinin ürün tarafındaki adı. Altında yatan standart WebAuthn — tarayıcıların uyguladığı W3C standardı — ve onun cihaz tarafındaki karşılığı olan FIDO2/CTAP. Kayıt sırasında cihazınızdaki authenticator (telefonunuzun güvenli bölgesi, bilgisayarınızın TPM'i ya da bir donanım anahtarı) bir anahtar çifti üretir. Private key cihazdan hiç çıkmaz; sunucuya yalnızca public key gider.

Giriş anında sunucu rastgele bir challenge gönderir, cihaz bunu private key ile imzalar, sunucu da kayıtlı public key ile imzayı doğrular. Buradaki kritik ayrım şu: hiçbir aşamada iki taraf arasında ortak bir sır dolaşmaz. Parolada olduğu gibi sunucunun veritabanında çalındığında işe yarayacak bir değer yoktur; bir saldırgan public key listesinin tamamını ele geçirse bile tek bir hesaba giriş yapamaz.

sunucu   → challenge: 9f2c...  +  rpId: irdaweb.com
tarayıcı → origin kontrolü: https://irdaweb.com  ✓
cihaz    → kullanıcı doğrulaması (biyometri / PIN)
cihaz    → imza = sign(private_key, challenge + origin)
sunucu   → verify(public_key, imza)  ✓

# private key cihazdan hiç çıkmaz
# imza yalnızca o origin için geçerlidir

"Phishing'e dayanıklı" tam olarak neyi garanti ediyor?

Bu ifade pazarlama dili değil, protokolün doğrudan sonucu. İmza üretilirken challenge'ın yanında sayfanın origin'i de imzaya dahil edilir ve passkey yalnızca kayıt edildiği alan adına (rpId) bağlıdır. Kullanıcı irdaweb-giris.com gibi taklit bir alan adına düştüğünde tarayıcı eşleşen bir passkey bulamaz; kullanıcı isterse bile yanlış siteye kimlik bilgisi gönderemez. Yani koruma, kullanıcının dikkatine değil tarayıcının uyguladığı bir kurala dayanır.

SMS ve TOTP tabanlı ikinci faktörlerde durum böyle değil. Kullanıcı kodu okuyup taklit sayfaya girdiği anda, araya giren saldırgan onu gerçek servise anında iletebilir; oturum açılır ve elde edilen çerez saldırganın elinde kalır. SaaS kimlik ihlalleri ve OAuth token'ları üzerinden ilerleyen vakalar üzerine yazdıklarımızda bu örüntü tekrar tekrar karşımıza çıkıyordu: giriş anı değil, giriş sonrası elde edilen erişim kalıcı hasarı yaratıyor.

Passkey'in çözmediği şeyi de net söylemek gerekir: oturum ele geçirme (session hijacking), zararlı yazılım bulaşmış bir uç nokta ya da kullanıcıyı meşru bir uygulamaya yetki vermeye ikna eden onay yorgunluğu saldırıları hâlâ mümkündür. Passkey, kimlik doğrulama anını sağlamlaştırır; oturum ömrü, cihaz sağlığı ve yetki kapsamı ayrı başlıklar olmaya devam eder. Bu katmanların tamamı için Bilgi Merkezi · Kimlik & Erişim rehberimiz iyi bir başlangıç noktası.

Senkronize passkey mi, device-bound passkey mi?

Kurumsal tarafta en çok tartışılan konu bu ve doğru cevap kurumdan kuruma değişiyor. İki modelin farkını bilmek, politikayı yazarken işinizi kolaylaştırır.

• Senkronize passkey — private key, platform sağlayıcının şifreli anahtar deposu üzerinden kullanıcının diğer cihazlarına taşınır (iCloud Keychain, Google Password Manager, kurumsal parola yöneticileri). Kullanıcı telefonunu kaybettiğinde erişimini kaybetmez; benimsenme oranı yüksektir. Karşılığında anahtarın nerede bulunduğu üzerindeki denetiminiz azalır.
• Device-bound passkey — anahtar tek bir donanımda üretilir ve orada kalır; tipik örneği FIDO2 güvenlik anahtarları ve kurum tarafından yönetilen cihazlardır. Denetim güçlüdür, attestation ile anahtarın hangi tip donanımda üretildiğini doğrulayabilirsiniz. Karşılığında kayıp cihaz senaryosu için ciddi bir yedek plan gerekir.
• Karma model — çoğu kurumda en gerçekçi olanı budur: genel çalışan kitlesi için senkronize passkey, yüksek yetkili yönetici ve altyapı hesapları için ikinci bir device-bound anahtar zorunluluğu. Risk seviyesini hesabın yetkisine göre ayarlarsınız.

Kurumsal geçişi nasıl planlarsınız?

Passkey'e geçiş teknik olmaktan çok bir süreç projesidir; kodun kendisi çoğu yığında birkaç günlük iştir, asıl zaman kullanıcı akışlarında ve destek süreçlerinde geçer. İşleyen bir sıralama şöyle görünüyor:

• Önce giriş yollarınızı çıkarın — bir hesaba kaç farklı kapıdan girilebildiğini yazmadan hiçbir şey sertleştirilemez. Parola, SSO, API token'ları, mobil uygulama, eski entegrasyonlar ve kurtarma akışları aynı listede yer almalı.
• Passkey'i zorunlu değil, ek seçenek olarak açın — ilk aşamada parolayla giriş yapan kullanıcıya passkey oluşturmayı önerin. Benimseme oranını ölçün; hangi cihaz ve tarayıcı kombinasyonlarında akışın takıldığını ancak gerçek kullanımda görürsünüz.
• Her kullanıcıdan en az iki passkey isteyin — tek anahtarlı bir hesap, cihaz kaybında doğrudan destek ekibinin kucağına düşer. İkinci bir cihaz ya da donanım anahtarı kaydı, kurtarma taleplerini büyük ölçüde ortadan kaldırır.
• Kurtarma akışını passkey kadar ciddiye alın — "e-posta ile sıfırlama" bırakıldığı sürece hesabın gerçek güvenlik seviyesi e-posta kutusunun seviyesidir. Kurtarma, kimlik doğrulamanın zayıf halkası değil eşdeğeri olmalı.
• Parolayı kademeli olarak kaldırın — önce yüksek yetkili hesaplarda, sonra genel kitlede. Kullanıcının en az bir passkey'i olmadan parolasız moda geçilemeyeceği için bu sıralama kendiliğinden güvenli bir kapı oluşturur.
• Kaydı ve kullanımı loglayın — hangi hesapta kaç passkey var, hangileri hâlâ parolayla giriyor, kurtarma kaç kez kullanıldı? Bu üç metrik olmadan geçişin ne kadar ilerlediğini söylemek mümkün değil.

Uygulama tarafında nelere dikkat etmelisiniz?

WebAuthn'ı kendi uygulamanıza eklerken tekrar eden birkaç ayrıntı var. rpId'yi alt alan adlarını da kapsayacak şekilde doğru seviyede seçmek bunların başında geliyor; sonradan değiştirmek kayıtlı tüm passkey'leri geçersiz kılar. discoverable credential (resident key) kullanmak, kullanıcının önce kullanıcı adı yazmasını gerektirmeyen akışları mümkün kılar — benimseme üzerindeki etkisi düşündüğünüzden büyüktür.

userVerification politikanızı bilinçli belirleyin: required dediğinizde biyometri ya da PIN zorunlu olur ve passkey tek başına iki faktör yerine geçer. Kurumsal denetim gerekiyorsa attestation ile hangi authenticator tiplerine izin verdiğinizi sınırlayabilirsiniz; ancak bunun benimsemeyi yavaşlattığını da hesaba katın. Uygulama katmanındaki diğer başlıklar için Web Uygulama Güvenliği rehberimize, standardın ayrıntıları içinse passkeys.dev kaynağına bakabilirsiniz.

Peki geriye ne kalıyor?

Passkey, kimlik doğrulamayı "kullanıcı doğru davranırsa güvenli" olmaktan çıkarıp "yanlış davranmak teknik olarak mümkün değil" seviyesine taşıyor. Bu, güvenlik tarafında sık rastlanmayan bir kazanç türü: eğitim ve dikkat gerektirmeden, protokolün kendisinden gelen bir koruma. Üstelik kullanıcı deneyimi de iyileşiyor — parola hatırlamak, sıfırlamak ve kod beklemek ortadan kalkıyor.

Geriye kalan iş ise klasik: hesapların yetki kapsamını daraltmak, oturum ömürlerini makul tutmak, kurtarma akışını sertleştirmek ve destek süreçlerini kayıt altına almak. Passkey bunların yerine geçmiyor, hepsinin üzerine sağlam bir temel koyuyor. Kurumunuzdaki giriş akışlarını birlikte gözden geçirmemizi isterseniz bize yazabilirsiniz.