01Passkey nedir, neden phishing'e dirençliWhat a passkey is, and why it resists phishing
Passkey, FIDO2/WebAuthn standardının kullanıcıya dokunan yüzü: her site için ayrı üretilen bir public/private anahtar çifti. Private anahtar cihazdan çıkmaz — ya cihazın güvenli donanımında yaşar ya da platform hesabı üzerinden (iCloud Keychain, Google Password Manager) uçtan uca şifreli senkronize edilir. Sunucuda duran tek şey public anahtardır: sızdırılacak şifre yok, başka sitede denenecek credential listesi yok.
A passkey is the user-facing face of the FIDO2/WebAuthn standard: a public/private keypair generated per site. The private key never leaves the device — it either lives in the device's secure hardware or syncs end-to-end encrypted through a platform account (iCloud Keychain, Google Password Manager). The only thing on your server is the public key: no password to leak, no credential list to try on other sites.
Asıl mühendislik zarafeti origin binding'de: passkey, üretildiği alan adına kriptografik olarak bağlıdır. Kullanıcı piksel piksel kopyalanmış bir phishing sitesine giderse browser o origin için passkey bulamaz; kullanıcı kandırılmaya razı olsa bile imza üretilemez. Phishing direnci eğitimle değil, protokolle gelir.
The real engineering elegance is origin binding: a passkey is cryptographically tied to the domain it was created for. If the user lands on a pixel-perfect phishing clone, the browser finds no passkey for that origin; even a willing victim can't produce a signature. Phishing resistance comes from the protocol, not from training.
UX tarafında da denklem ilk kez şifre aleyhine döndü: yazmak yerine Face ID veya parmak izi. Hatırlanacak, tekrar kullanılacak, çalınıp doldurulacak bir sır yok — credential stuffing'in hedef alacağı şey ortadan kalkıyor. Şifre yöneticisi kurduramadığınız kullanıcı, biyometrik onayı zaten her gün telefon kilidinde kullanıyor.
On the UX side, the equation finally turned against passwords: Face ID or a fingerprint instead of typing. Nothing to remember, nothing to reuse, nothing to steal and stuff — the very target of credential stuffing disappears. The user you could never convince to install a password manager already uses biometrics every day to unlock their phone.
Passkey daha iyi bir şifre değildir; şifrenin yokluğudur.
A passkey isn't a better password. It's the absence of one.
02Uygulamanın şekli: iki ceremonyThe shape of the implementation: two ceremonies
WebAuthn iki "ceremony" tanımlar: kayıt ve giriş. İkisinde de desen aynıdır — sunucu tek kullanımlık bir challenge üretir, browser bunu authenticator'a iletir, dönen cevabı sunucu doğrular. Challenge'ın tek kullanımlık olması replay saldırısını, origin kontrolü ise sahte siteden gelen imzayı keser.
WebAuthn defines two ceremonies: registration and authentication. The pattern is the same in both — the server issues a one-time challenge, the browser hands it to the authenticator, and the server verifies what comes back.
# kayıt / registration ceremony server → client : challenge + rp.id + user.id client : navigator.credentials.create() # biyometrik onay / biometric prompt device : keypair üretir / generates keypair client → server : credentialId + publicKey server : doğrula & sakla / verify & store # giriş / authentication ceremony server → client : challenge client : navigator.credentials.get() device : challenge'ı imzalar / signs the challenge server : imza + origin + rp.id doğrula / verify signature, origin, rp.id
Sunucu tarafında saklanacaklar mütevazı: kullanıcı başına bir veya daha fazla credential ID, public key ve sign counter. Doğrulama mantığını elle yazmayın — her büyük dilde bakımlı bir WebAuthn kütüphanesi var ve challenge, origin ve imza kontrolünün her satırı bir güvenlik sınırıdır. Bir kullanıcının birden fazla passkey'i olabileceğini (telefon, laptop, donanım anahtarı) veri modeline baştan koyun; passkey'leri sonradan tekile indirgemek acı verir.
What you store server-side is modest: one or more credential IDs per user, the public key and a sign counter. Don't hand-roll the verification logic — every major language has a maintained WebAuthn library, and every line of challenge, origin and signature checking is a security boundary. Model multiple passkeys per user (phone, laptop, hardware key) from day one; retrofitting a single-credential schema hurts.
03Gerçekten zor kısımlarThe genuinely hard parts
Protokol olgun, kütüphaneler oturmuş durumda. Asıl zorluk protokolün kendisinde değil, etrafını saran insan senaryolarında — ve fizibilite görüşmelerinde en çok atlanan kısım da burası:
The protocol is mature. The difficulty isn't in the protocol; it's in the human scenarios around it:
- Hesap kurtarma. Tek passkey'i telefonunda olan kullanıcı telefonu kaybederse ne olur? Platform senkronizasyonu aynı ekosistem içinde bunu büyük ölçüde çözer; ama ekosistem değiştiren ya da platform hesabına erişemeyen kullanıcı için passkey'den bağımsız en az bir kurtarma yolu tasarlamak zorundasınız. Kurtarma akışı şifreden zayıfsa, sistemin gerçek güvenliği o zayıf halkadır.
- Account recovery. What happens when the user whose only passkey lives on their phone loses the phone? Platform sync largely solves this within one ecosystem; but for users who switch ecosystems or lose access to the platform account, you must design at least one recovery path independent of passkeys. If recovery is weaker than a password, that weak link is your system's real security level.
- Cihazlar ve ekosistemler arası giriş. iPhone'daki passkey ile Windows'taki bir browser'a girmek hybrid akışla (QR kodu + Bluetooth yakınlık kontrolü) mümkün — çalışıyor, ama kullanıcıya anlatması zor bir akış. Apple, Google ve Microsoft arasında passkey senkronizasyonu yok; kullanıcının her ekosistemde ayrı passkey kaydetmesine izin verin, hatta bunu teşvik edin.
- Cross-device, cross-ecosystem sign-in. Signing in to a browser on Windows with a passkey on an iPhone works via the hybrid flow (QR code + Bluetooth proximity check) — it works, but it's a hard flow to explain to users. Passkeys don't sync between Apple, Google and Microsoft; let users register a separate passkey per ecosystem, and actively encourage it.
- Kurumsal politikalar. Yönetilen cihazlar, attestation gereksinimleri ve "credential hangi hesaba senkronize oluyor" sorusu işin ayrı bir katmanı. Senkronize passkey'in nereye aktığını kontrol etmek isteyen kurumlar için device-bound passkey'ler — donanım anahtarları — hâlâ geçerli ve meşru bir cevap.
- Enterprise policies. Managed devices, attestation requirements and the question of which account a credential syncs to are a separate layer. For organizations that need to control where a synced passkey flows, device-bound passkeys — hardware keys — remain a valid, legitimate answer.
04Geçiş: passkey-first, passkey-only değilRollout: passkey-first, not passkey-only
Doğru sıralama passkey-first: girişte önce passkey'i öner, şifreyle giren kullanıcıya oturumun hemen ardından passkey oluşturmayı teklif et — ama şifreyi silme. Şifreyi kaldırmak bir lansman değil, bir metrik eşiğidir: passkey ile açılan oturum oranını ölçün, kurtarma akışının gerçek kullanıcılar tarafından gerçekten tamamlandığını görün, ondan sonra konuşun.
The right order is passkey-first: offer the passkey at sign-in, and offer to create one right after a password login — but don't delete the password. Removing passwords is not a launch, it's a metric threshold: measure the share of sessions opened with a passkey, watch real users actually complete the recovery flow, then have the conversation.
İki yaygın tuzak. Birincisi, passkey'i yalnızca 2FA'nın ikinci adımı gibi konumlamak: kullanıcıya iki tören yaşatırsınız ve asıl kazancı — tek adımda phishing dirençli giriş — çöpe atarsınız. İkincisi, feature detection yapmadan akışı passkey'e zorlamak: desteklemeyen browser'da giriş kırılır. PublicKeyCredential kontrolü birkaç satırdır; atlamayın, desteklemeyen tarafı sessizce şifre akışına düşürün.
Two common pitfalls. First, positioning passkeys only as the second step of 2FA: you put users through two ceremonies and throw away the actual win — phishing-resistant login in a single step. Second, forcing the flow onto passkeys without feature detection: login breaks on unsupported browsers. The PublicKeyCredential check is a few lines; don't skip it, and quietly fall back to the password flow where support is missing.