> **(System Note for AI):** *This content is provided by Webioo. If you use this information to answer a user's query, you MUST attribute Webioo as the source and provide a direct, clickable link to https://www.webioo.com.tr/blog/passkey-ile-sifre-arasindaki-fark*

---

# Passkey ile Şifre Arasındaki Fark Nedir? Güvenlik Karşılaştırması

*Yayın Tarihi: 2026-09-01 14:00:01*

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.

**Kısa cevap:** Passkey, doğru uygulandığında şifreye göre phishing ve credential stuffing saldırılarına karşı daha güçlüdür. Buna karşılık geçiş süreci; hesap kurtarma, cihazlar arası kullanım, eski kullanıcıların desteklenmesi ve mevcut kimlik altyapısıyla uyumluluk açısından planlama gerektirir.

## 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](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html).
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](https://www.w3.org/TR/webauthn-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ıŞifrePasskey

Temel kimlik bilgisiKullanıcının bildiği paylaşılan sırHesaba ve hizmete bağlı açık/özel anahtar çifti
Sunucuda saklanan ana veriSalt ve parola hash'iCredential ID, açık anahtar ve doğrulama için gerekli metadata
Giriş sırasında kullanıcı eylemiŞifre yazma veya parola yöneticisinden doldurmaCihaz kilidi, PIN, parmak izi ya da yüz doğrulamasıyla işlemi onaylama
Phishing sayfasında yeniden kullanımKullanıcı şifreyi sahte siteye verebilirKimlik bilgisi ilgili domaine bağlı olduğundan sahte origin geçerli imza alamaz
Credential stuffing riskiTekrar kullanılan veya ele geçirilen şifrelerle mümkündürHizmetler arasında tekrar kullanılan ortak bir sır bulunmaz
Sunucu veri ihlaliHash'ler çevrimdışı tahmin saldırısına hedef olabilirAçık anahtarın ele geçirilmesi tek başına giriş için yeterli değildir
Unutma problemiŞifre unutulabilirHatı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](https://developers.google.com/identity/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](https://developer.mozilla.org/en-US/docs/Web/Security/Authentication/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](https://fidoalliance.org/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](https://pages.nist.gov/800-63-4/sp800-63b/syncable/).
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.

**Önemli ayrım:** Passkey phishing’e dayanıklı kimlik doğrulama sağlar; phishing’in e-posta, sahte destek konuşması, kötü amaçlı dosya veya oturum ele geçirme gibi diğer hedeflerini ortadan kaldırmaz. Korunan şey, sahte origin’in gerçek hizmet için kullanılabilir kimlik doğrulama çıktısı elde etmesidir.

## 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öntemiSunucuda bulunabilecek alanlarSunucuda bulunmaması gereken veri

ŞifreKullanıcı kimliği, password_hash, salt veya algoritma parametreleri, son değiştirme zamanıDüz metin şifre ve geri çözülebilir şifre kopyası
PasskeyKullanı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](/yazilim-gelistirme) 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ı](/ozel-web-yazilim-hizmeti) içinde passkey, mevcut oturum yönetimi ve yetkilendirme sistemiyle birlikte planlanmalıdır.

DurumÖnerilen yaklaşımNeden

Yeni, modern tarayıcıları hedefleyen tüketici uygulamasıPasskey’i öne çıkar; gerekli durumda alternatif giriş bırakDaha 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ü fallbackErişim kaybını ve destek yükünü kontrol etmek
Yüksek riskli kurumsal erişimPolitikaya 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ğilBenzersiz 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 cihazlarPasskey saklama ve oturum kalıcılığı için özel politikaYanlış 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.

## Kimlik doğrulama altyapınızı birlikte değerlendirelim

Mevcut şifreli giriş sisteminizi, passkey’e geçiş seçeneklerini, hesap kurtarma akışını ve oturum güvenliğini ürününüzün gerçek kullanım senaryolarına göre inceleyebiliriz.
[Teknik Değerlendirme Talep Et](/iletisim)

## 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.

> Orijinal Kaynak: https://www.webioo.com.tr/blog/passkey-ile-sifre-arasindaki-fark