Passkey ile şifre arasındaki temel fark, kullanıcının giriş sırasında ne bildiğinden çok sistemin hangi kimlik bilgisini doğruladığıdır. Şifre modelinde kullanıcı ve hizmet arasında paylaşılan bir sır vardır. Passkey modelinde ise hesaba özel bir kriptografik anahtar çifti kullanılır; özel anahtar kullanıcı tarafındaki doğrulayıcıda korunurken sunucu yalnızca açık anahtarı saklar.
Bu ayrım yalnızca giriş ekranındaki alanları değiştirmez. Veri tabanında tutulacak bilgiyi, phishing saldırısının işe yarayıp yaramayacağını, parola sıfırlama süreçlerini, cihaz kaybı senaryosunu ve destek ekibinin üstleneceği operasyonu da değiştirir. Bu nedenle doğru soru “hangisi daha yeni?” değil, “hangi risk modelinde ve kullanıcı yolculuğunda hangisi daha doğru?” olmalıdır.
Passkey ve şifre aynı şeyi nasıl farklı biçimde doğrular?
Şifre, kullanıcının bildiği ve giriş sırasında hizmete gönderdiği bir sırdır. Sunucu güvenli bir uygulamada şifrenin kendisini değil; benzersiz salt ile güçlü, yavaş bir parola türetme algoritması kullanılarak oluşturulmuş hash değerini saklar. OWASP, parolaların düz metin tutulmamasını; Argon2id, bcrypt veya PBKDF2 gibi parola saklamaya uygun yöntemlerin kullanılmasını önerir OWASP Password Storage Cheat Sheet.
Passkey ise WebAuthn tabanlı bir açık anahtarlı kimlik bilgisidir. Kayıt sırasında kullanıcı cihazındaki doğrulayıcı, ilgili siteye özgü bir anahtar çifti oluşturur. Açık anahtar hizmete kaydedilir; özel anahtar doğrulayıcıdan dışarı çıkarılmaz. Giriş sırasında sunucu tek kullanımlık bir challenge üretir, doğrulayıcı bunu özel anahtarla imzalar ve sunucu imzayı açık anahtarla kontrol eder. W3C WebAuthn standardı, kimlik bilgilerinin ilgili relying party ve origin kapsamına bağlı biçimde oluşturulmasını tanımlar W3C WebAuthn Level 3.
Şifre modelinde sunucu, kullanıcının sunduğu sırrın doğru olup olmadığını kontrol eder. Passkey modelinde sunucu, kullanıcının ilgili hesaba ve domaine bağlı özel anahtara sahip olduğunu kriptografik imza üzerinden doğrular.
| Karşılaştırma noktası | Şifre | Passkey |
|---|---|---|
| Temel kimlik bilgisi | Kullanıcının bildiği paylaşılan sır | Hesaba ve hizmete bağlı açık/özel anahtar çifti |
| Sunucuda saklanan ana veri | Salt ve parola hash'i | Credential ID, açık anahtar ve doğrulama için gerekli metadata |
| Giriş sırasında kullanıcı eylemi | Şifre yazma veya parola yöneticisinden doldurma | Cihaz kilidi, PIN, parmak izi ya da yüz doğrulamasıyla işlemi onaylama |
| Phishing sayfasında yeniden kullanım | Kullanıcı şifreyi sahte siteye verebilir | Kimlik bilgisi ilgili domaine bağlı olduğundan sahte origin geçerli imza alamaz |
| Credential stuffing riski | Tekrar kullanılan veya ele geçirilen şifrelerle mümkündür | Hizmetler arasında tekrar kullanılan ortak bir sır bulunmaz |
| Sunucu veri ihlali | Hash'ler çevrimdışı tahmin saldırısına hedef olabilir | Açık anahtarın ele geçirilmesi tek başına giriş için yeterli değildir |
| Unutma problemi | Şifre unutulabilir | Hatırlanacak metin yoktur; erişim doğrulayıcı ve kurtarma modeline bağlıdır |
Kullanıcı deneyiminde fark nerede hissedilir?
Şifreli giriş kullanıcıdan genellikle kullanıcı adı, şifre ve kimi zaman ikinci faktör ister. Güçlü ve benzersiz şifre politikası güvenliği artırsa da şifre üretme, saklama, doldurma ve sıfırlama adımlarını çoğaltır. Parola yöneticisi bu yükün önemli bölümünü azaltabilir; ancak kullanıcı yine de hangi kasada hangi hesabın bulunduğunu ve kurtarma yöntemini yönetmek zorundadır.
Passkey akışında kullanıcı çoğu zaman cihazında zaten kullandığı ekran kilidiyle giriş işlemini onaylar. Biyometrik veri siteye gönderilmez; parmak izi veya yüz doğrulaması, cihazın özel anahtarı kullanmasına yerel olarak izin verir. Google’ın passkey geliştirici dokümanı, kullanıcının biyometrik sensör, PIN veya desenle giriş yapabildiğini ve şifre hatırlama ihtiyacının ortadan kalktığını açıklar Google Passkeys. MDN de özel anahtarın doğrulayıcı tarafından korunduğunu, açık anahtarın ise relying party tarafında hesapla ilişkilendirildiğini belirtir MDN Passkeys.
Yine de “tek dokunuşla her yerde giriş” sonucu otomatik değildir. İyi deneyim için kullanıcıya hangi cihaz veya hesap sağlayıcısındaki passkey’in kullanılacağı anlaşılır biçimde gösterilmeli, farklı cihazdan giriş akışı desteklenmeli ve passkey bulunamadığında çıkmaz sokak yaratılmamalıdır. Özellikle kurumsal uygulamalarda yönetilen cihazlar, paylaşılan terminaller ve güvenlik anahtarları ayrı kullanım senaryoları olarak ele alınmalıdır.
Genel bir giriş akışı örneği
- Kullanıcı giriş sayfasında hesabını seçer veya passkey ile giriş seçeneğini başlatır.
- Sunucu, yalnızca bu oturum için geçerli rastgele bir challenge üretir.
- Tarayıcı ya da işletim sistemi, ilgili domaine ait uygun passkey’i bulur.
- Kullanıcı cihaz kilidi, PIN veya biyometrik yöntemle işlemi onaylar.
- Doğrulayıcı challenge’ı özel anahtarla imzalar; özel anahtar cihazdan çıkmaz.
- Sunucu açık anahtarla imzayı, challenge’ı, origin ve relying party bilgilerini doğrular.
- Kontroller başarılıysa normal web oturumu oluşturulur.
Bu örnek belirli bir ürünün arayüzünü taklit etmez; WebAuthn tabanlı passkey girişinin genel mantığını gösterir. Uygulama ayrıntıları, kullanılan kimlik sağlayıcıya ve hesap kurtarma politikasına göre değişebilir.
Saldırı yüzeyi açısından passkey neden farklıdır?
Şifrelerin en büyük yapısal sorunu taşınabilir bir sır olmalarıdır. Kullanıcı aynı veya benzer şifreyi birden fazla hizmette kullanabilir; saldırgan da bir veri sızıntısından elde edilen kimlik bilgilerini başka sistemlerde deneyebilir. Bu saldırı credential stuffing olarak bilinir. Şifre yöneticisiyle üretilen benzersiz parolalar bu riski azaltır, ancak phishing sayfası kullanıcıyı gerçek hizmeti taklit ederek şifreyi veya tek kullanımlık kodu vermeye ikna edebilir.
Passkey, ilgili relying party alan adına kriptografik olarak bağlıdır. Doğrulayıcı, farklı bir domaine ait sahte sayfanın gerçek hizmet için geçerli imza üretme isteğini karşılamaz. FIDO Alliance, passkey’leri phishing’e dayanıklı ve credential stuffing gibi uzaktan saldırıları azaltacak şekilde tasarlanmış kimlik bilgileri olarak tanımlar FIDO Alliance Passkeys. NIST de doğru yapılandırılmış senkronize doğrulayıcıların domain kapsamlı anahtar kullanımı ve her işlemde rastgele nonce/challenge sayesinde phishing ve replay saldırılarına direnç sağlayabildiğini açıklar NIST Syncable Authenticators.
Bu avantaj, sistemin geri kalanını otomatik olarak güvenli yapmaz. Saldırgan aktif bir oturum çerezini ele geçirirse, hesap kurtarma kanalını devralırsa veya kullanıcı hesabına yeni bir doğrulayıcı ekleme sürecini aşarsa passkey tek başına yeterli koruma sunmaz. Oturum güvenliği, cihaz ve hesap bildirimleri, hassas işlemlerde yeniden doğrulama, yeni passkey eklerken güçlü kontrol ve kurtarma kayıtlarının izlenmesi ayrıca tasarlanmalıdır.
Sunucu veri tabanında ne değişir?
Şifre kullanan bir sistemde güvenli saklama için her hesapta güçlü algoritmayla üretilmiş bir parola hash’i ve salt bulunur. Sunucu, girişte gönderilen şifreyi aynı yöntemle işler ve sonucu kayıtlı değerle karşılaştırır. Veri tabanı sızdığında saldırgan düz metin şifreyi doğrudan görmemelidir; ancak hash’ler üzerinde çevrimdışı tahmin çalıştırabilir. Bu nedenle algoritma seçimi, maliyet parametreleri ve kullanıcıların benzersiz şifre kullanması kritik kalır.
Passkey kullanan sistemde hesap kaydı genellikle credential ID, açık anahtar, kullanıcıya ve relying party’ye ilişkin ilişkilendirme bilgileri ile doğrulama sırasında gereken sayaç veya taşıma bilgilerini içerir. Özel anahtar sunucu veri tabanına konmaz. Bu nedenle yalnızca relying party veri tabanındaki açık anahtarı ele geçirmek, saldırgana kullanıcı gibi imza atma yetkisi vermez.
Temsili veri modeli karşılaştırması
| Hesap yöntemi | Sunucuda bulunabilecek alanlar | Sunucuda bulunmaması gereken veri |
|---|---|---|
| Şifre | Kullanıcı kimliği, password_hash, salt veya algoritma parametreleri, son değiştirme zamanı | Düz metin şifre ve geri çözülebilir şifre kopyası |
| Passkey | Kullanıcı kimliği, credential_id, public_key, transport bilgisi, kayıt zamanı ve yönetim metadata’sı | Özel anahtar ve kullanıcının biyometrik şablonu |
Tablodaki alanlar genel mimariyi anlatır; gerçek şema kullanılan WebAuthn kütüphanesine ve risk modeline göre farklılaşabilir. WebAuthn uygulamasında challenge doğrulaması, origin ve RP ID kontrolü, imza doğrulaması ve credential yaşam döngüsü hazır ve güncel kütüphanelerle yönetilmelidir. Kimlik altyapısını sıfırdan kriptografi yazarak kurmak yerine, yazılım geliştirme sürecinde standart uyumlu bileşenler ve güvenlik incelemesi tercih edilmelidir.
Cihaz kaybı ve hesap kurtarmada hangisi daha kolaydır?
Şifreli hesapta kullanıcı şifreyi hatırlıyorsa yeni cihazdan giriş yapabilir; hatırlamıyorsa e-posta, SMS, destek doğrulaması veya yedek kod gibi bir kurtarma kanalına ihtiyaç duyar. Buradaki zayıf halka çoğu zaman şifrenin kendisi değil, hesabı sıfırlamaya izin veren kanaldır. E-posta hesabı ele geçirilmişse veya destek süreci sosyal mühendisliğe açıksa güçlü parola yeterli olmayabilir.
Passkey tarafında deneyim, passkey’in senkronize mi yoksa tek cihaza bağlı mı olduğuna göre değişir. Senkronize passkey, kullanıcının platform hesabı üzerinden diğer cihazlarına erişebilir. Cihaza bağlı passkey veya fiziksel güvenlik anahtarı ise başka cihaza otomatik taşınmayabilir. Bu nedenle birden fazla passkey kaydetme, yedek doğrulayıcı sunma, kayıp cihazı hesaptan kaldırma ve kurtarma olaylarında kullanıcıyı bilgilendirme gereklidir.
Passkey’e geçiş yapılırken kurtarma kanalının şifreden daha zayıf bırakılması sık görülen bir tasarım hatasıdır. Örneğin phishing’e dayanıklı passkey ile korunan bir hesabın yalnızca kolay ele geçirilebilir e-posta bağlantısıyla sıfırlanabilmesi, güçlü giriş yönteminin etkisini azaltır. Kurtarma politikası; hesabın değeri, işlem riski, kullanıcı kitlesi ve destek kapasitesine göre ayrı tasarlanmalıdır.
Passkey mi, güçlü şifre ve MFA mı?
Yeni bir tüketici uygulamasında, desteklenen platformlarda passkey’i birincil seçenek yapmak kullanıcıdan parola üretme yükünü kaldırabilir ve phishing riskini belirgin biçimde azaltabilir. Ancak bütün kullanıcıların aynı cihaz ekosisteminde olduğu varsayılmamalıdır. İlk aşamada passkey ile şifre veya federated login yöntemlerinin birlikte sunulduğu kademeli model daha gerçekçi olabilir.
Mevcut bir kurumsal sistemde karar yalnızca güvenliğe bakılarak verilmez. Kullanıcıların yönetilen cihaz kullanıp kullanmadığı, dış kullanıcıların sisteme erişip erişmediği, paylaşılan çalışma istasyonları, donanım güvenlik anahtarı gereksinimi, yardım masası süreçleri ve kimlik sağlayıcının WebAuthn desteği değerlendirilmelidir. Kimlik akışının ürüne özel kurgulanması gerektiğinde özel web yazılım altyapısı içinde passkey, mevcut oturum yönetimi ve yetkilendirme sistemiyle birlikte planlanmalıdır.
| Durum | Önerilen yaklaşım | Neden |
|---|---|---|
| Yeni, modern tarayıcıları hedefleyen tüketici uygulaması | Passkey’i öne çıkar; gerekli durumda alternatif giriş bırak | Daha az şifre sürtünmesi ve phishing’e dayanıklı giriş |
| Eski cihaz ve tarayıcıların yoğun olduğu kullanıcı tabanı | Kademeli geçiş ve ölçümlü fallback | Erişim kaybını ve destek yükünü kontrol etmek |
| Yüksek riskli kurumsal erişim | Politikaya göre yönetilen passkey veya donanım doğrulayıcı | Cihaz, kullanıcı doğrulaması ve kurtarma üzerinde daha güçlü kontrol |
| Passkey entegrasyonu henüz mümkün değil | Benzersiz güçlü şifre, parola yöneticisi ve phishing’e dayanıklı MFA’ya geçiş planı | Zayıf ve tekrar kullanılan şifreleri azaltırken altyapıyı hazırlamak |
| Paylaşılan veya halka açık cihazlar | Passkey saklama ve oturum kalıcılığı için özel politika | Yanlış cihazda kalıcı kimlik bilgisi bırakma riskini azaltmak |
Geçiş kararı için kontrol listesi
- Kullanıcı tabanını ölçün: Desteklenen işletim sistemi, tarayıcı, mobil ve masaüstü dağılımını belirleyin.
- Hesap kurtarmayı tasarlayın: Kayıp cihaz, platform hesabına erişememe ve tüm passkey’lerin silinmesi senaryolarını ayrı ele alın.
- Birden fazla doğrulayıcıya izin verin: Kullanıcının ikinci cihaz veya güvenlik anahtarı ekleyebilmesini sağlayın.
- Yeni credential eklemeyi koruyun: Oturumu ele geçiren kişinin sessizce yeni passkey kaydetmesini engelleyecek yeniden doğrulama ve bildirim kullanın.
- Fallback’i sınırlayın: Alternatif giriş yöntemi passkey’den çok daha zayıfsa saldırgan her zaman en zayıf yolu seçer.
- Oturum güvenliğini ayrı yönetin: Passkey başarılı olduktan sonra oluşturulan cookie ve token’lar için Secure, HttpOnly, SameSite, süre ve iptal politikalarını uygulayın.
- Yaşam döngüsünü görünür yapın: Kullanıcının kayıtlı passkey’leri adlandırabilmesi, son kullanımını görebilmesi ve kaldırabilmesi gerekir.
- Kademeli yayın yapın: Önce gönüllü kayıt, sonra passkey-first giriş ve en son gerekliyse şifresiz hesap modeli gibi aşamalar belirleyin.
- Destek ekibini hazırlayın: “Biyometrim siteye mi gidiyor?”, “telefonumu kaybettim” ve “başka bilgisayardan nasıl girerim?” sorularına net yanıtlar oluşturun.
- Başarıyı doğru metriklerle izleyin: Giriş tamamlama, kurtarma başlatma, destek talebi ve fallback kullanımını izleyin; kaynaksız başarı yüzdeleri varsaymayın.
Sonuç: Passkey şifrenin yalnızca daha kolay hali değildir
Passkey ile şifre arasındaki fark, kullanıcı arayüzünde metin alanı yerine parmak izi göstermekten ibaret değildir. Şifre, hizmete sunulan ve güvenli biçimde hash’lenmesi gereken paylaşılan bir sırdır. Passkey ise domaine bağlı açık anahtarlı bir kimlik bilgisidir; sunucu doğrulama için açık anahtarı tutar ve her girişte imzalı challenge kontrol eder.
Bu mimari, phishing ve credential stuffing gibi şifre kaynaklı saldırılara karşı güçlü avantaj sağlar. Buna rağmen hesap kurtarma, doğrulayıcı ekleme, cihaz kaybı, fallback ve oturum yönetimi zayıfsa bütün sistem hâlâ saldırıya açık olabilir. En doğru geçiş; kullanıcıların cihaz gerçekliğini, uygulamanın risk seviyesini ve destek operasyonunu birlikte değerlendiren kademeli bir plandır.
Sıkça Sorulan Sorular
Passkey kullanınca şifre tamamen silinir mi?
Bu, hizmetin geçiş politikasına bağlıdır. Bazı sistemler passkey’i şifreye ek bir giriş yöntemi olarak sunar; bazıları passkey oluşturulduktan sonra şifresiz hesaba geçebilir. Kademeli geçişte şifre bir süre fallback olarak kalabilir. Ancak fallback yöntemi çok zayıfsa saldırgan passkey’i hedeflemek yerine şifre sıfırlama veya eski giriş kanalını kullanır. Bu nedenle şifrenin korunması, kaldırılması ve kurtarma süreci tek bir güvenlik politikası içinde planlanmalıdır.
Passkey için parmak izi kullanmak zorunlu mu?
Hayır. Passkey işlemini onaylamak için cihazın desteklediği kullanıcı doğrulama yöntemi kullanılır. Bu yöntem parmak izi veya yüz tanıma olabileceği gibi cihaz PIN’i, ekran kilidi deseni ya da fiziksel güvenlik anahtarının doğrulama mekanizması da olabilir. Biyometrik veri web sitesine gönderilmez; cihaz üzerinde özel anahtarın kullanılmasına izin vermek için yerel doğrulama yapılır.
Telefon kaybolursa passkey ile hesaba erişim kaybolur mu?
Passkey’in türüne ve kullanıcının yedeklerine göre değişir. Senkronize passkey başka bir güvenilir cihazda kullanılabilirken, tek cihaza bağlı passkey kayıp cihazla birlikte erişilemez hale gelebilir. Sağlıklı bir sistem birden fazla passkey kaydına, kayıp cihazı hesaptan kaldırmaya ve güçlü hesap kurtarma yöntemlerine izin verir. Yüksek riskli uygulamalarda ikinci doğrulayıcı veya fiziksel güvenlik anahtarı önceden kaydedilmelidir.
Passkey veri tabanı sızarsa hesaplar ele geçirilir mi?
Relying party veri tabanında normalde özel anahtar değil, açık anahtar ve credential bilgileri bulunur. Açık anahtarın ele geçirilmesi saldırgana geçerli giriş imzası üretme yetkisi vermez. Yine de veri ihlali önemsiz değildir; hesap metadata’sı, kişisel veriler, aktif oturumlar veya kurtarma kayıtları etkilenebilir. Ayrıca uygulama credential ekleme ve oturum yönetimi kontrollerinde zayıfsa farklı saldırı yolları oluşabilir.
Güçlü şifre ve iki aşamalı doğrulama passkey kadar güvenli midir?
Güçlü, benzersiz şifre ve iyi seçilmiş MFA, yalnızca şifre kullanımından çok daha güvenlidir. Ancak SMS kodu, e-posta kodu veya kullanıcı tarafından elle girilen tek kullanımlık kodlar gelişmiş phishing akışlarında ele geçirilebilir. WebAuthn tabanlı passkey, kimlik bilgisini ilgili domaine bağladığı için phishing’e dayanıklı doğrulama sağlar. Yine de nihai güvenlik; kurtarma, oturum, cihaz ve yetkilendirme kontrollerinin tamamına bağlıdır.
Bir web sitesine passkey eklemek için mevcut kullanıcılar yeniden kayıt olmalı mı?
Genellikle mevcut kullanıcı önce bilinen bir yöntemle hesabına giriş yapar ve ardından hesabına yeni bir passkey kaydeder. Bu işlem yeni bir kullanıcı hesabı açmak anlamına gelmez; mevcut hesaba yeni bir doğrulayıcı bağlanır. Geçiş akışında kullanıcıya neden passkey oluşturduğu, hangi cihazda saklanacağı, başka cihazdan nasıl giriş yapacağı ve passkey’i nasıl kaldıracağı açıkça anlatılmalıdır.
