Passkey Nedir? Şifresiz Giriş Nasıl Çalışır?

Passkey, parolanızı bir sunucuya göndermeden giriş yapmanızı sağlayan açık anahtar tabanlı bir kimlik doğrulama yöntemidir. Cihazınız PIN, parmak izi veya yüz tanıma ile kilidi açar; site ise yalnızca geçerli bir imzayı doğrular. Bu nedenle passkey, özellikle kimlik avı ve parola tekrar kullanımı riskini azaltır.

Passkey nedir ve hangi sorunu çözer?

Passkey, parola yazmadan kimlik doğrulamak için kullanılan ve FIDO2 ile WebAuthn standartlarına dayanan bir giriş bilgisidir. Hesap oluşturulurken cihazda bir özel anahtar, sunucuda ise buna karşılık gelen açık anahtar tutulur. Giriş sırasında cihazınız PIN, parmak izi, yüz tanıma veya başka bir cihaz kilidiyle açılır; sunucuya parola gönderilmez.

Bu yapı, parola hırsızlığını ve kimlik avını zorlaştırır. Doğrulama kayıtlı web sitesiyle ilişkilendirildiği için saldırgan, elde ettiği bir parolayı başka bir sitede kullanamaz. Passkey akışında kopyalanabilir bir parola bulunmaz.

Passkey kavramı, FIDO Alliance tarafından kullanıcıların aşina olduğu şifresiz giriş deneyimini anlatmak için kullanılır. Teknik tarafta tarayıcı ile sunucu arasındaki işlem, W3C Web Authentication API ve FIDO2 protokol ailesiyle yürütülür.

Ne yapılmalı – Passkey desteği sunan hesaplarda önce kurtarma seçeneklerini kontrol edin, ardından ana cihazınızda passkey oluşturun.

Passkey nasıl çalışır?

İlk kayıt sırasında cihazınız asimetrik bir kriptografi anahtar çifti üretir. Özel anahtar cihazda veya işletim sisteminin güvenli kimlik bilgisi deposunda kalır; açık anahtar hizmet sağlayıcının sunucusuna gönderilir. Sunucu özel anahtarı görmez ve saklamaz.

Giriş isteği geldiğinde sunucu rastgele bir challenge üretir. Tarayıcı bu değeri, kayıt sırasında belirlenen alan adı ve işlem bilgileriyle birlikte cihazdaki kimlik doğrulayıcıya iletir. Kullanıcı yerel doğrulamayı tamamladığında özel anahtarla imzalanmış yanıt tarayıcı üzerinden sunucuya döner.

Sunucu, daha önce kaydettiği açık anahtarla imzayı doğrular. İmza geçerliyse, challenge doğruysa ve istek beklenen origin üzerinden geldiyse oturum açılır. Challenge tek kullanımlık ve kısa ömürlü tasarlanır; böylece eski bir doğrulama yanıtının tekrar gönderilmesi, yani replay saldırısı, işe yaramaz.

Özel anahtar nerede tutulur?

Özel anahtar çoğu cihazda işletim sisteminin güvenli alanında, TPM çipinde, Secure Enclave benzeri donanım destekli bir bölümde veya güvenlik anahtarında tutulur. Web sitesi bu anahtarı dışarı aktaramaz. Cihazdaki biyometrik veri de siteye gönderilmez; parmak izi veya yüz tanıma yalnızca cihazın yerel kilidini açar.

Bir passkey oluşturmak, siteye parmak izinizi vermek anlamına gelmez. Sunucu, cihazınızın hangi doğrulama yöntemini kullandığını değil, geçerli bir kriptografik imza üretebildiğinizi görür.

Passkey ile giriş adımları nelerdir?

1. Hesap ayarlarında “Passkey ekle” veya benzer bir seçeneği açın.
2. Cihazın oluşturduğu kayıt isteğini onaylayın.
3. PIN, parmak izi, yüz tanıma veya cihaz kilidiyle yerel doğrulama yapın.
4. Sunucunun passkey kaydını tamamlamasını bekleyin.
5. Sonraki girişte e-posta ve parola yerine kayıtlı passkey’i seçin.

Bilgisayarda giriş yaparken telefondaki passkey’i kullanmanız da mümkün olabilir. Tarayıcı ekranda QR kod gösterir; telefon QR kodu tarar ve iki cihaz arasındaki işlem Bluetooth yakınlık kontrolüyle desteklenebilir. Bu senaryoda telefon özel anahtarı bilgisayara göndermez, yalnızca doğrulama işlemini tamamlar.

Tarayıcı ve işletim sistemi desteği önemlidir. WebAuthn API güvenli bağlam gerektirir; pratikte bu genellikle HTTPS demektir. Geliştirme ortamlarında localhost için istisnalar bulunabilir, ancak üretimde HTTP üzerinden passkey kullanmayı planlamak doğru değildir.

Ne yapılmalı – Passkey testlerini üretim alan adına geçmeden önce HTTPS, doğru origin ve yedek cihaz senaryosuyla birlikte deneyin.

Passkey parola ve iki faktörlü doğrulamadan nasıl farklıdır?

Parola ve TOTP kodları kullanıcı tarafından sahte bir giriş sayfasına yazılabilir. Passkey işlemi ise kayıtlı relying party kimliğiyle, yani hesabın bağlı olduğu hizmet kimliğiyle ilişkilidir. Tarayıcı, doğru alan adıyla eşleşmeyen bir sayfaya gerçek site için oluşturulmuş passkey’i kullandırmaz.

NIST’in dijital kimlik kılavuzlarında kimlik doğrulama faktörleri ve kimlik avına dayanıklı yöntemler ayrı değerlendirilir. Passkey’in güvenlik seviyesi yalnızca biyometri kullanmasından gelmez; asıl koruma, alan adına bağlı açık anahtar kriptografisi ve cihazdaki özel anahtarın dışarı çıkarılamamasıdır.

Passkey, ikinci faktörün yerini her durumda otomatik olarak alır mı? Bu, hizmetin kayıt politikasına bağlıdır. Cihaz kilidiyle korunan bir passkey çoğu senaryoda sahiplik ve yerel kullanıcı doğrulamasını birlikte sağlayabilir. Kurumsal sistemler yine de donanım anahtarı, cihaz yönetimi veya ek politika isteyebilir.

Passkey güvenli mi?

Passkey’lerin güçlü tarafı, sunucu sızıntısında saldırgana doğrudan kullanılabilir bir parola vermemesidir. Sunucu veritabanında açık anahtar bulunur; açık anahtardan özel anahtarın çıkarılması, kullanılan kriptografik algoritmanın güvenlik varsayımlarını kırmayı gerektirir.

Kimlik avına karşı koruma da mimarinin parçasıdır. WebAuthn doğrulaması origin, challenge ve relying party bilgilerini kontrol eder. Kullanıcı sahte bir alan adına yönlendirilirse tarayıcı, gerçek site için oluşturulmuş passkey’i o sahte alan adına kullandırmaz.

Passkey sihirli bir kalkan değildir. Cihazınızın ekran kilidi zayıfsa, kötü amaçlı yazılım yerel oturumu ele geçirirse veya hesabın kurtarma e-postası saldırgana geçerse risk devam eder. Hesap kurtarma süreci çoğu zaman en zayıf halka olur.

Bir başka konu senkronizasyondur. Bazı ekosistemler passkey’leri uçtan uca şifrelenmiş hesap senkronizasyonuyla cihazlar arasında taşır. Bu kolaylığı artırır; ana hesabın güçlü bir parola, çok faktörlü koruma ve güvenilir kurtarma seçenekleriyle korunması gerekir.

Ne yapılmalı – Passkey’i güçlü ekran kilidi, güncel işletim sistemi ve güvenli hesap kurtarma yöntemiyle birlikte kullanın.

Passkey kaybolursa ne olur?

Telefonunuzu veya bilgisayarınızı kaybettiğinizde passkey’in akıbeti, onun nerede saklandığına bağlıdır. Senkronize edilen passkey’ler yeni bir cihazda aynı üretici hesabıyla geri alınabilir. Yalnızca cihazda bulunan passkey’ler ise cihazla birlikte erişilemez hale gelebilir.

Hizmetin hesap ayarlarında kayıtlı cihazları ve passkey’leri ayrı ayrı görebilmeniz gerekir. Kullanmadığınız cihazları kaldırın. Yeni cihaz eklerken eski cihazı hemen silmek yerine yeni cihazla giriş yaptığınızı test edin; aksi halde tek kurtarma yolunu erken kapatabilirsiniz.

Güvenlik anahtarı kullanılıyorsa en az iki kayıtlı anahtar bulundurmak mantıklıdır. Biri günlük kullanımda, diğeri güvenli bir yerde yedek olarak tutulabilir. Bu yaklaşım özellikle yöneticiler, alan adı hesapları, hosting panelleri ve ödeme servislerinde değerlidir.

Bir VPS veya hosting hesabının yönetici erişimini passkey ile korurken acil durum hesabını ve kurtarma kodlarını da belgelendirin. Bu bilgiler düz metin dosyasında veya sunucunun içine bırakılmamalı; erişimi sınırlı bir parola yöneticisinde tutulmalıdır.

Ne yapılmalı – Yeni passkey’i doğrulamadan eski cihazı silmeyin ve kurtarma yöntemini yılda en az bir kez test edin.

Web sitesi ve VPS yöneticileri passkey desteğini nasıl planlamalı?

Bir web uygulamasına passkey desteği eklemek, giriş formuna bir düğme koymaktan ibaret değildir. Uygulama WebAuthn kayıt ve doğrulama akışlarını, kullanıcı başına birden fazla credential kaydını, credential ID değerlerini, imza sayacını ve hesap kurtarma politikasını yönetmelidir.

Sunucu tarafında şu bilgiler genellikle gereklidir:

• Credential ID
• Kullanıcı hesabıyla ilişkilendirilmiş açık anahtar
• Relying party ID
• Kullanıcının tercih ettiği kullanıcı adı veya görünen ad
• Son doğrulama zamanı ve gerekiyorsa imza sayacı

Relying party ID ile origin aynı kavram değildir. Origin; şema, alan adı ve port birleşimidir. Örneğin https://panel.example.com ile https://example.com farklı origin’lerdir. Relying party ID uygun alan adı kapsamını tanımlar; yanlış seçilirse alt alan adlarında beklenmeyen davranışlar görülebilir.

Reverse proxy kullanılan sistemlerde dışarıdan görülen HTTPS şeması uygulamaya doğru aktarılmalıdır. Host, Origin ve güvenilir proxy başlıkları rastgele kabul edilmemeli; yalnızca bilinen proxy adreslerinden gelen başlıklar işlenmelidir. Web uygulamasının yönetici hesabını korumak için Admin Ne Demek? Admin Ne Anlama Gelir? yazısındaki rol ayrımı yaklaşımı da yararlı bir başlangıçtır.

Sunucu işletim sisteminin yönetimi için passkey desteği doğrudan SSH’a eklenmek yerine çoğu zaman bir kimlik sağlayıcı, VPN, SSO katmanı veya web tabanlı yönetim paneli üzerinden verilir. Windows Server Core gibi GUI’siz ortamlarda yönetim yüzeyini daraltmak ve ayrıcalıklı hesapları sınırlamak hâlâ gereklidir; passkey, yanlış yapılandırılmış firewall kuralını veya gereksiz açık portu düzeltmez.

WordPress gibi uygulamalarda passkey eklentisi seçerken güncelleme geçmişi, WebAuthn standardına uyum, rol bazlı politika ve hesap kurtarma seçenekleri incelenmelidir. VPS’te WordPress Kurulumu: Adım Adım Rehber başlığındaki temel sunucu güvenliği adımları uygulanmadan yalnızca giriş yöntemini değiştirmek yeterli koruma sağlamaz.

Ne yapılmalı – WebAuthn uygulamasında origin, relying party ID, proxy başlıkları ve hesap kurtarma akışını ayrı test senaryolarıyla doğrulayın.

Passkey kullanmaya geçerken hangi hatalardan kaçınılmalı?

İlk hata, passkey’i parola yöneticisindeki rastgele bir parolanın yerine koyup kurtarma sürecini kontrol etmemektir. Kullanıcı cihazını kaybettiğinde destek ekibi eski kimlik doğrulama yöntemini kolayca devreye alabiliyorsa saldırganlar sosyal mühendislikle bu yolu hedefleyebilir.

İkinci hata, bütün yöneticilerin tek bir cihazdaki passkey’e bağlanmasıdır. Kişisel cihaz kaybı, işten ayrılma veya cihaz politikası değişikliği durumunda erişim kesilebilir. Yönetici hesaplarında ayrı cihaz kaydı, yedek güvenlik anahtarı ve kayıtların periyodik gözden geçirilmesi gerekir.

Üçüncü hata, senkronizasyonu yedekleme sanmaktır. Senkronizasyon hesabın erişilebilirliğini artırır; fakat sağlayıcı hesabı, cihaz kilidi ve kurtarma zinciri de güvenlik kapsamına girer. Kurum politikası gerektiriyorsa senkronize olmayan donanım güvenlik anahtarları tercih edilebilir.

Bir diğer hata, tarayıcı konsolundaki hatayı anlamadan WebAuthn kodunu değiştirmektir. NotAllowedError, kullanıcı iptali, zaman aşımı veya origin uyuşmazlığı gibi farklı nedenlerle görülebilir. Hatanın yanında tarayıcı sürümü, alan adı, HTTPS durumu ve cihaz platformu kaydedilmelidir.

Parola tamamen kaldırılmadan önce geçiş dönemi tanımlayın. Yeni yöntemi test kullanıcılarıyla deneyin, iki farklı cihazdan giriş yapın, passkey silme ve hesap kurtarma akışını uygulayın. Başarısız bir test, üretimde yaşanacak bir kesintiden daha ucuzdur.

Passkey Kurmadan Önce Şunları Kontrol Edin

• Hesapta güncel bir kurtarma e-postası veya ikinci doğrulama yöntemi tanımlayın.
• Cihazınızda güçlü bir PIN ya da ekran kilidi kullanın.
• İlk passkey'i ana cihazınıza kaydedin ve giriş yapabildiğinizi doğrulayın.
• İkinci bir cihaz veya güvenlik anahtarı ekleyin.
• Kayıtlı passkey'lerin hangi cihazlara ait olduğunu adlandırın.
• Eski cihazı silmeden önce yeni cihazdaki giriş ve kurtarma akışını test edin.
• Yönetici hesaplarında origin, proxy ve hesap kurtarma senaryolarını ayrı ayrı sınayın.

Passkey, kimlik avına ve parola hırsızlığına karşı güçlü bir katman sunsa da otomatik giriş denemelerini azaltmak için ek önlemler gerekir. Bu noktada CAPTCHA nedir ve bot koruması nasıl çalışır? başlıklı rehberimde, CAPTCHA’nın riskli istekleri nasıl ayırt ettiğini ve sunucu tarafında nasıl doğrulanması gerektiğini anlattım.

Sık Sorulan Sorular

Kaynaklar

• W3C – Web Authentication: An API for accessing Public Key Credentials — w3.org
• MDN – Web Authentication API — developer.mozilla.org
• NIST – Digital Identity Guidelines: Authentication and Lifecycle Management — pages.nist.gov