Passkey Nedir? Şifresiz Girişe Geçiş ve Sitenize Ekleme

Bir sabah WordPress yöneticinize girerken tarayıcı size hiç sormadığınız bir şey soruyor: "Bu site için bir geçiş anahtarı kaydedilsin mi?" Aynı hafta bir müşteriniz destek talebi açıyor: "Doğrulama kodunu girdim, yine de hesabıma başkası girmiş." Bu iki olay ilgisiz görünür ama aynı hikâyenin iki ucudur. Birincisi tarayıcıların artık standart hâle getirdiği yeni giriş yöntemi, ikincisi ise o yöntemin çözmek için tasarlandığı somut saldırı.

Passkey — Türkçe karşılığıyla geçiş anahtarı — bir hesaba parola yazmadan, cihazınızın kilidini açtığınız yöntemle (parmak izi, yüz tanıma, cihaz PIN'i) girmenizi sağlayan kimlik doğrulama biçimidir. Arkasındaki standardın adı WebAuthn, onu kapsayan spesifikasyon ailesinin adı FIDO2. Kullanıcı tarafında "parmak izine bastım, girdim" kadar basit görünen bu akışın altında açık anahtar kriptografisi çalışır ve saldırganın çalabileceği bir "sır" ortada dolaşmaz.

Bu yazı son kullanıcı anlatımı değil, site sahibi ve sistem yöneticisi için yazıldı. Sırasıyla şunlara bakacağız: passkey teknik olarak neyi değiştiriyor, oltalamaya karşı neden SMS ve TOTP'den yapısal olarak güçlü, hangi hesaplarda bugün açmanız gerekiyor, WordPress'e ve kendi uygulamanıza nasıl eklenir, cihaz kaybında ne oluyor ve 2FA'yı gerçekten emekliye ayırıyor mu.

Passkey Nedir, Parolanın Yerine Tam Olarak Ne Geçiyor?#

Klasik parola sisteminde sunucu ile kullanıcı aynı sırrı bilir. Siz parolayı yazarsınız, sunucu kendi tarafındaki özetle karşılaştırır. Bu modelin kaçınılmaz zaafı şudur: sır bir yerden diğerine iletildiği için yolda yakalanabilir, sunucu sızarsa toplu hâlde ele geçebilir, kullanıcı yanlış siteye yazarsa saldırganın eline geçer.

Passkey bu modeli tersine çevirir. Kayıt sırasında cihazınız bir anahtar çifti üretir:

• Özel anahtar (private key) cihazın güvenli donanım bölgesinde kalır — telefonlarda Secure Enclave / StrongBox, bilgisayarlarda TPM veya güvenlik anahtarının çipi. Cihazdan hiçbir zaman çıkmaz.
• Açık anahtar (public key) siteye gönderilir ve kullanıcı hesabına iliştirilir. Sunucuda saklanmasında sakınca yoktur; tek başına hiçbir işe yaramaz.

Girişte sunucu rastgele bir veri parçası (challenge) gönderir, cihaz bunu özel anahtarla imzalar, sunucu imzayı kayıtlı açık anahtarla doğrular. Yani ağ üzerinden geçen şey bir parola değil, tek kullanımlık bir imzadır. Sunucu veritabanınız sızsa bile saldırganın eline yalnızca açık anahtarlar geçer; bunlarla kimse giriş yapamaz. Bu, güçlü parola politikası kurmakla elde edemeyeceğiniz bir garantidir — çünkü orada hâlâ çalınabilir bir sır vardır.

Tarayıcı tarafında akışı başlatan çağrı şudur:

// Kayıt: yeni bir passkey oluştur
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: challengeBytes,          // sunucudan gelir, tek kullanımlık
    rp: { id: "ornek.com", name: "Örnek Panel" },
    user: {
      id: userIdBytes,                  // kullanıcı kimliği (e-posta değil)
      name: "[email protected]",
      displayName: "Ayşe Yılmaz"
    },
    pubKeyCredParams: [
      { type: "public-key", alg: -7 },   // ES256
      { type: "public-key", alg: -257 }  // RS256
    ],
    authenticatorSelection: {
      residentKey: "required",           // keşfedilebilir kimlik = kullanıcı adı bile gerekmez
      userVerification: "required"       // biyometri veya PIN zorunlu
    },
    timeout: 60000
  }
});

Buradaki rp.id alanı hikâyenin kalbidir: passkey alan adına bağlanır. Bu tek satır, birazdan anlatacağımız oltalama bağışıklığının teknik sebebidir.

Passkey Oltalamaya Karşı Neden SMS ve TOTP'den Güçlü?#

Klasik iki faktörlü doğrulamanın sessiz zaafı şudur: kod, siteyi tanımaz. Authenticator uygulamanızın ürettiği altı haneli sayı ornek.com için de ornek-giris.com için de aynıdır, çünkü onu üreten uygulama hangi sayfaya yazdığınızı bilmez. Gerçek dünyada saldırı şöyle işler:

1. Kullanıcıya "hesabınız askıya alınacak" temalı bir e-posta gider, içindeki bağlantı sahte panele götürür.
2. Kullanıcı sahte sayfaya parolasını yazar. Saldırganın altyapısı bunu anında gerçek siteye iletir.
3. Gerçek site 2FA kodu ister; sahte sayfa da kullanıcıya kod sorar.
4. Kullanıcı TOTP kodunu yazar, saldırgan onu saniyeler içinde gerçek siteye taşır ve oturumu açar.

Bu senaryoya "ortadaki adam ile gerçek zamanlı aktarma" denir ve hazır araçlarla otomatikleştirilebilir hâle geldiği için artık uzman işi değildir. Konunun insan tarafı için oltalama saldırılarından korunma yazısı iyi bir tamamlayıcıdır; buradaki mesele ise saldırının teknik olarak neden mümkün olduğu.

Passkey'de aynı adımlar çalışmaz. Tarayıcı, imzalamadan önce adres çubuğundaki alan adı ile passkey'in kayıtlı olduğu rp.id değerini karşılaştırır. Kullanıcı ornek-giris.com sayfasındaysa tarayıcı ornek.com için üretilmiş anahtarı hiç göstermez; ekranda "kullanılabilir geçiş anahtarı yok" der. Kullanıcının dikkatli olmasına, adresi harf harf okumasına gerek kalmaz — kontrolü yapan tarayıcıdır ve yanılmaz. Ayrıca imzalanan veri o oturuma özel challenge'ı içerdiği için, yakalanan bir imza başka bir oturumda tekrar kullanılamaz.

Tablodaki "sunucuda saklanan" sütunu ayrıca şunu söyler: TOTP kullanıyorsanız sunucunuzda hâlâ paylaşılan bir sır durur ve veritabanı sızıntısında bu sır da gider. Passkey'de böyle bir sır yoktur. Bu iki farkın toplamı — alan adı bağlama ve paylaşılan sırrın yokluğu — passkey'i kategorik olarak farklı bir sınıfa koyar; "biraz daha güvenli" değil, o saldırı sınıfına kapalıdır.

Yan fayda: passkey açık olan bir hesap, parola deneme saldırılarının hedefi olmaktan çıkar. Brute force saldırısı mantığı denenecek bir parola alanı varsaymaya dayanır; imza tabanlı girişte denenecek bir şey yoktur.

Passkey Nerede Saklanır: Senkron, Cihaza Bağlı ve Donanım Anahtarı#

"Passkey" tek bir şey değil; saklandığı yere göre üç farklı davranış gösterir ve bu fark kullanıcı deneyimini de kurtarma planınızı da belirler.

Senkronize passkey'ler yaygınlaşmanın asıl sebebidir: kullanıcı telefonunu değiştirdiğinde girişleri kaybetmez, çünkü anahtarlar buluttaki kasada uçtan uca şifreli tutulur. Buradaki güven zinciri artık o bulut hesabına kayar; dolayısıyla Apple/Google/Microsoft hesabının kendisini korumak en kritik adım hâline gelir.

Yönetici hesapları içinse tavsiye farklıdır: en az bir adet fiziksel güvenlik anahtarı bulundurun ve onu kasada tutun. Telefon kaybolabilir, bulut hesabı kilitlenebilir; cebinizdeki USB anahtar bunlardan bağımsızdır. Pratikte iyi çalışan kombinasyon şudur: günlük kullanım için telefondaki senkronize passkey, felaket senaryosu için çekmecedeki donanım anahtarı.

Bir de cross-device (çapraz cihaz) akışı vardır: masaüstünde giriş yaparken ekrandaki QR kodu telefonunuzla okutursunuz, imza telefonda atılır. Bu akış Bluetooth üzerinden yakınlık doğrulaması yaptığı için uzaktaki bir saldırgan tarafından tetiklenemez — yani QR kodunu birinin size WhatsApp'tan göndermesi işe yaramaz.

Hangi Hesaplarda Passkey'i Bugün Açmalısınız?#

Her yere aynı anda yaymaya çalışmak yerine, zarar potansiyeline göre sıralayın. Sıralama şu soruya göre yapılır: bu hesap ele geçerse diğer kaç hesabı kaybederim?

1. E-posta hesabınız. Neredeyse her sistemin parola sıfırlama zinciri buradan geçer. E-posta düşerse alan adı paneli, hosting, banka bildirimleri sırayla düşer. İlk sırada olmasının sebebi budur.
2. Alan adı ve DNS yönetim paneliniz. Buraya giren biri MX kaydını değiştirip e-postalarınızı kendine yönlendirebilir; sitenizi kapatmasına bile gerek kalmaz.
3. Hosting / sunucu panelleriniz ve WHM-cPanel erişimi.
4. Kod deposu ve CI/CD hesapları (GitHub, GitLab). Kaynak koda yazma yetkisi, üretime dolaylı erişim demektir.
5. Bulut sağlayıcı ve fatura hesapları.
6. Sosyal medya ve reklam hesapları — doğrudan finansal kayıp üretir.

Kurumsal tarafta ikinci bir öncelik listesi daha vardır: paylaşılan hesaplar. Bir ekipte üç kişinin aynı paroladan girdiği panel, passkey'e geçişin en çok kazandırdığı yerdir; çünkü passkey kişiye ve cihaza bağlıdır, WhatsApp grubunda paylaşılamaz. Bu zorunluluk tek başına "ortak hesap" alışkanlığını kırar.

Passkey 2FA'nın Yerine Geçer mi?#

Kısa cevap: çoğu senaryoda evet, ama geçiş dönemini yönetmek gerekir.

Passkey'i "ikinci faktör" saymak teknik olarak eksik bir tanımdır. Bir passkey ile giriş yaparken iki şey aynı anda kanıtlanır: sahip olduğunuz şey (özel anahtarı taşıyan cihaz) ve olduğunuz/bildiğiniz şey (biyometri veya cihaz PIN'i, yani userVerification). Bu yüzden standart bunu "çok faktörlü tek adım" olarak tanımlar. Buna ek bir SMS kodu istemek güvenliği ölçülebilir biçimde artırmaz, yalnızca sürtünme ekler.

Pratikte doğru kurgu şudur:

• Passkey birincil giriş yöntemi olur.
• Parola bir süre yedek olarak kalır, ama ona bağlı 2FA'nın açık kalması şarttır. Aksi hâlde saldırgan passkey'i hiç denemez, doğrudan "parolamı unuttum" kapısını çalar. Zincir en zayıf halkası kadar güçlüdür ve bu halka çoğu kurulumda parola kurtarma akışıdır.
• Kullanıcıların çoğu passkey'e geçtikten sonra parola girişi tamamen kapatılabilir. Bu noktaya gelene kadar iki faktörlü doğrulama kurgunuzu söküp atmayın.

Dikkat edilecek nokta: passkey'i açıp parolayı zayıf bırakmak, güvenliği artırmaz — sadece kolay bir giriş yolu daha ekler. Geçiş planınızın son adımı her zaman "eski yolu kapatmak" olmalıdır.

WordPress Sitenize Passkey Ekleme#

WordPress çekirdeği passkey desteğini kendi içinde sunmaz; iş eklentiye kalır. WordPress.org deposunda WebAuthn/FIDO2 tabanlı birkaç olgun seçenek bulunur — WP-WebAuthn, Secure Passkeys ve Advanced Passkeys for Secure Login bunların başında gelir. Hepsi aynı standardı uyguladığı için kullanıcı tarafı benzer davranır; seçerken bakılacaklar şunlardır:

• Son güncelleme tarihi ve aktif kurulum sayısı (kimlik doğrulama eklentisinde bakımsızlık kabul edilemez).
• Parola girişini tamamen kapatabilme seçeneği var mı.
• Kullanıcı başına birden fazla passkey kaydına izin veriyor mu (telefon + güvenlik anahtarı).
• REST API ve XML-RPC girişlerini de kapsıyor mu.

Kurulum ve ilk kayıt akışı:

# WP-CLI ile kurulum (SSH erişiminiz varsa en hızlı yol)
wp plugin install wp-webauthn --activate

# Kurulum sonrası mevcut yönetici hesaplarını listeleyin
wp user list --role=administrator --fields=ID,user_login,user_email

Ardından tarayıcıdan Kullanıcılar → Profil ekranına girip kendi passkey'inizi kaydedin. Sıralama önemlidir:

1. Önce kendi hesabınıza passkey ekleyin ve farklı bir tarayıcıda giriş yapıp test edin.
2. Test başarılıysa ikinci bir passkey daha ekleyin (ör. bir donanım anahtarı).
3. Diğer yöneticilere duyurup onların kaydetmesini bekleyin.
4. En son adım olarak parola girişini kısıtlayın.

Uyarı: Parola girişini test etmeden kapatmayın. Passkey kaydı tamamlanmadan bu ayarı açarsanız yönetici panelinden tamamen kilitlenirsiniz. Kurtarma için veritabanından eklenti ayarını değiştirmek ya da wp plugin deactivate ile SSH üzerinden devre dışı bırakmak gerekir — SSH erişiminiz yoksa gerçekten sıkışırsınız.

Passkey, wp-login.php üzerine gelen otomatik parola denemelerini kendiliğinden durdurmaz; sadece o denemelerin işe yaramasını engeller. Sunucu kaynağını korumak için WordPress giriş denemelerini sınırlama önlemlerini yerinde bırakın.

Kendi Uygulamanıza WebAuthn Ekleme#

Kendi PHP veya Node.js uygulamanıza passkey eklerken kriptografiyi elle yazmayın; olgun kütüphaneler mevcut ve doğrulama adımlarını (imza, origin kontrolü, sayaç, attestation) sizin yerinize yapıyorlar.

# PHP tarafı
composer require web-auth/webauthn-lib

# Node.js / TypeScript tarafı
npm install @simplewebauthn/server @simplewebauthn/browser

Akış her dilde aynı dört adımdan oluşur ve iki tur vardır: kayıt (registration) ve doğrulama (authentication).

// 1) Sunucu: kayıt seçeneklerini üret ve challenge'ı oturumda sakla
import { generateRegistrationOptions, verifyRegistrationResponse }
  from "@simplewebauthn/server";

const options = await generateRegistrationOptions({
  rpName: "Örnek Panel",
  rpID: "ornek.com",
  userName: user.email,
  attestationType: "none",
  authenticatorSelection: {
    residentKey: "preferred",
    userVerification: "preferred"
  }
});
req.session.challenge = options.challenge;   // sunucuda tut, istemciye güvenme
res.json(options);

// 2) Sunucu: tarayıcıdan dönen cevabı doğrula ve açık anahtarı kaydet
const verification = await verifyRegistrationResponse({
  response: req.body,
  expectedChallenge: req.session.challenge,
  expectedOrigin: "https://ornek.com",
  expectedRPID: "ornek.com"
});

if (verification.verified) {
  await db.savePasskey({
    userId: user.id,
    credentialId: verification.registrationInfo.credential.id,
    publicKey: verification.registrationInfo.credential.publicKey,
    counter: verification.registrationInfo.credential.counter
  });
}

Giriş turunda generateAuthenticationOptions() ile yeni bir challenge üretir, tarayıcıda navigator.credentials.get() çağrılır, dönen imza verifyAuthenticationResponse() ile doğrulanır. Uygulamada en sık atlanan ve gerçekten kritik olan noktalar şunlardır:

• Challenge sunucuda saklanmalı ve tek kullanımlık olmalı. İstemciden geri gelen challenge'a güvenirseniz tüm mekanizma çöker.
• expectedOrigin sabit olmalı. Bunu isteğin Origin başlığından okumak, oltalama korumasını kendi elinizle kapatmak demektir.
• rpID alan adınızın kökü olmalı (ornek.com), alt alan adı değil. Aksi hâlde passkey panel.ornek.com dışında çalışmaz.
• Sayaç (signature counter) kontrol edin. Klonlanmış bir kimlik doğrulayıcıyı yakalamanın standart yolu budur.
• HTTPS zorunludur. WebAuthn yalnızca güvenli bağlamda çalışır; localhost geliştirme için istisnadır.
• Kullanıcı başına birden fazla passkey kaydına izin verin ve her birine ad/tarih verin; kullanıcı hangi cihazı sildiğini bilmelidir.

Cihazımı Kaybedersem Ne Olur?#

Bu, passkey'e geçişte sorulan ilk sorudur ve haklı bir sorudur. Cevap kurgunuza bağlıdır.

Senkronize passkey kullanıyorsanız telefonun kaybı bir felaket değildir: anahtarlar bulut hesabınızdaki şifreli kasada durur, yeni cihaza giriş yaptığınızda geri gelir. Burada gerçek risk telefon değil, o bulut hesabına erişimi kaybetmektir. Bu yüzden Apple/Google/Microsoft hesabınızın kurtarma bilgilerini (kurtarma kodu, yedek e-posta, güvenilir kişi) güncel tutmak zorunludur.

Cihaza bağlı passkey veya donanım anahtarı kullanıyorsanız kayıp gerçekten kayıptır. Tek çare önceden ikinci bir yöntem tanımlamış olmaktır.

Site sahibi olarak kullanıcılarınıza sunmanız gereken minimum kurtarma seti:

1. En az iki passkey. Kayıt ekranında "ikinci bir cihaz ekleyin" adımını atlanabilir değil, akışın parçası yapın.
2. Tek kullanımlık kurtarma kodları. Kayıt sırasında üretin, indirmesini isteyin, kullanılanı sunucuda geçersizleştirin.
3. Doğrulanmış bir kurtarma e-postası — ama bu adresin kendisi de passkey ile korunuyor olmalı, yoksa zincirin zayıf halkası oraya kayar.
4. Kimlik doğrulamalı destek süreci. Sosyal mühendislikle çalışan bir "hesabımı açın" hattı, tüm kriptografiyi anlamsız kılar; bu risk için sosyal mühendislik saldırıları yazısındaki senaryolar iyi bir kontrol listesidir.

Kendi panelinizde ise kural nettir: kilitlenme senaryosunu üretimde denemeden geçiş yapmayın. Test hesabıyla passkey'i silin, parolayı kapatın ve kurtarma yolunun gerçekten çalıştığını görün. Bu on dakikalık test, gece yarısı yaşanacak bir erişim krizinin yerine geçer.

Sıkça Sorulan Sorular#

Passkey ile parola arasındaki temel fark nedir?#

Parolada siz ve sunucu aynı sırrı bilirsiniz; bu sır ağ üzerinden geçtiği için yakalanabilir, sunucu sızıntısında toplu hâlde ele geçer. Passkey'de özel anahtar cihazınızdan hiç çıkmaz, sunucuda yalnızca açık anahtar durur. Girişte parola değil, o oturuma özel tek kullanımlık bir imza gönderilir. Çalınacak bir sır bulunmadığı için sızıntı ve tekrar kullanım saldırıları anlamsızlaşır.

Passkey kullanırsam iki faktörlü doğrulamayı kapatabilir miyim?#

Passkey zaten iki unsuru tek adımda birleştirir: cihazın sahipliği ve biyometri/PIN doğrulaması. Bu yüzden üstüne SMS kodu eklemek ölçülebilir bir kazanç sağlamaz. Ancak parola girişi açık kaldığı sürece o yola bağlı 2FA'yı kapatmayın; saldırgan passkey'i denemez, doğrudan parola ve kurtarma akışını hedefler. Doğru sıralama: önce passkey'i yaygınlaştırın, sonra parola girişini kapatın.

Telefonumu kaybedersem hesaplarıma erişimim gider mi?#

Senkronize passkey kullanıyorsanız hayır: anahtarlar bulut hesabınızın şifreli kasasında durur ve yeni cihazda geri gelir. Cihaza bağlı passkey veya donanım anahtarındaysa kayıp kalıcıdır. Bu yüzden her kritik hesapta en az iki kayıtlı passkey ve saklanmış kurtarma kodları bulundurun. Bulut hesabınızın kurtarma bilgilerini güncel tutmak da en az bu kadar önemlidir.

WordPress sitemde passkey kullanmak için hangi eklenti gerekiyor?#

WordPress çekirdeği passkey desteği içermez. WordPress.org deposundaki WP-WebAuthn, Secure Passkeys ve Advanced Passkeys for Secure Login gibi WebAuthn tabanlı eklentiler bu işi yapar. Seçerken son güncelleme tarihine, kullanıcı başına birden fazla anahtar desteğine ve parola girişini kapatma seçeneğine bakın. Kurulumdan sonra parola girişini kapatmadan önce mutlaka farklı bir tarayıcıda giriş testi yapın.

Passkey oltalama saldırılarını gerçekten tamamen engelliyor mu?#

Klasik kimlik bilgisi çalma ve gerçek zamanlı aktarma saldırılarına karşı evet. Tarayıcı, imzalamadan önce adres çubuğundaki alan adı ile anahtarın kayıtlı olduğu alan adını karşılaştırır; uyuşmazsa anahtarı hiç göstermez. Kullanıcının dikkatine ihtiyaç kalmaz. Ancak zayıf bir parola kurtarma akışı, kimlik doğrulamasız destek hattı veya ele geçirilmiş bir cihaz hâlâ risktir; passkey bu kapıları kapatmaz.

Passkey her tarayıcı ve işletim sisteminde çalışır mı?#

Güncel Chrome, Safari, Edge ve Firefox sürümleri ile güncel iOS, Android, macOS ve Windows sürümleri WebAuthn'u destekler. Pratikte sorun çıkan yerler eski kurumsal Windows makineleri, güncellenmemiş Android cihazlar ve bazı uygulama içi tarayıcılardır. Bu yüzden passkey'i tek giriş yöntemi yapmadan önce kullanıcı kitlenizin cihaz dağılımına bakın ve geçiş süresince alternatif bir yol açık tutun.

Passkey sunucuma ek yük veya lisans maliyeti getirir mi?#

Hayır. Doğrulama sunucu tarafında yalnızca bir imza kontrolüdür; kaynak tüketimi ihmal edilebilir düzeydedir ve parola özeti hesaplamaktan bile ucuzdur. WebAuthn açık bir standarttır, lisans ücreti yoktur. Kullanacağınız kütüphaneler de açık kaynaktır. Tek gereksinim geçerli bir HTTPS sertifikasıdır; passkey güvensiz bağlantı üzerinde hiç çalışmaz.