Passkeys ve çoklu hesap yönetimi: anahtarların izolasyonu 2026

1 Eylül 2026'dan itibaren Microsoft, Entra ID'de varsayılan giriş yöntemi olarak passkey'leri dahil etmeye başladı ve 1 Şubat 2027'den itibaren SMS ve sesli kodların kendi teslimatını devre dışı bırakıyor. Google, kişisel hesaplar için erişim anahtarlarını Ekim 2023'te ana giriş seçeneği haline getirdi. Tek bir kişi için bir hesapla bu oldukça kullanışlı. Ancak, anti-detect'te onlarca hesabı olanlar için passkey, izole profilleri birbirine bağlayan görünmez bir iplik haline gelebiliyor. Aşağıda bunun nasıl gerçekleştiğini ve anahtarların hesaplar arasında nasıl "sızmadığını" inceleyeceğiz.

Neden bu soru şimdi gündeme geldi

Passkey'ler 2022 yılından beri var, ancak 2026'da "aktif hale getirilebilir" durumundan "sizden istenecektir" durumuna dönüştü. Üç belirgin neden:

Microsoft Entra ID. Eylül 2026'dan itibaren SMS veya telefonla giriş onaylayan kullanıcılara otomatik olarak passkey'ler etkinleştirilecek: bir sonraki MFA kontrolünde anahtar kaydetme teklifi çıkacak. 31 Ocak 2027'ye kadar bunu ertelemek mümkün, 1 Şubat 2027'den itibaren bunu atlamak mümkün olmayacak. Microsoft, kendi verisini gerekçe gösteriyor: yapay zeka ile yapılan kimlik avı kampanyaları %54 tıklama alırken, normal kampanyalar %12 tıklama alıyor.
Google. Ekim 2023'ten itibaren kişisel hesaplarda varsayılan olarak "Mümkün olduğunda şifre girmeyi atla" seçeneği etkin. Anahtar oluşturulduğunda, Google bununla giriş yapmayı öneriyor.
Anahtarların yöneticiler arasında taşınması. FIDO Alliance, Credential Exchange standardını (CXF ve CXP formatları) yayınladı. iOS 26 ve macOS 26'da, Apple Passwords, 1Password, Bitwarden, Dashlane ve diğer uygulamalar arasında passkey'leri şifreli bir şekilde, dosya çıkarmadan aktarmak mümkün. Anahtar artık tek bir depoya sıkı bir şekilde bağlı değil. Çoklu hesap yönetimi için bu hem bir fırsat hem de bir risk.

Passkey nasıl çalışır ve neden profillerin izolasyonunu kırar

Passkey, bir çift kriptografik anahtardır. Kamu anahtarı site tarafından saklanırken, özel anahtar "kimlik doğrulayıcı" tarafından saklanır. Anahtar, bir alan adına (spesifikasyonda bu rpId) bağlıdır, bu nedenle kimlik avı sitesi onu alamaz. Çoklu hesap yönetimi için en önemli soru, özel anahtarın fiziksel olarak nerede bulunduğudur. Anti-detect, çerezleri, localStorage'ı, IndexedDB'yi ve parmak izini izole eder. Anahtarların depolandığı yer genellikle tarayıcı profili dışında bulunur:

Windows Hello, anahtarları Windows hesabı düzeyinde saklar. Bu hesap altında herhangi bir tarayıcı ve profil aynı depoya erişir.
macOS'taki iCloud anahtarları, Apple ID'ye aittir. Chrome ve Safari aynı Mac'te aynı anahtar setini görür.
Google Şifre Yöneticisi, tarayıcı veya telefonun giriş yaptığı Google hesabına bağlıdır. Bir iş Google hesabı yirmi profil için tek bir ortak kasa gibidir.
Uzantı yöneticileri (Bitwarden, 1Password ve diğerleri) anahtarları kendi hesaplarının deposunda saklar. Tüm profiller için tek bir depo, her şeyi görebilen tek bir nokta olarak çalışır.

Bundan tipik bir hata ortaya çıkar. Hesap numarası 7'de "Erişim anahtarı ile giriş yap" butonuna tıkladığınızda, sistem aynı sitedeki hesap numarası 3 ve 12'nin anahtarlarını gösterir. Site bu listeyi görmez: yalnızca seçilen anahtarı alır. Ancak bir yanlış tıklama — ve hesap numarası 3, profil, IP ve hesap numarası 7'nin parmak izi ile giriş yapar. Bu bağlantıyı artık iptal etmek mümkün değildir.

Site, passkey ile giriş yapıldığında gerçekten neyi bilir

Passkey, risk puanlamasını ortadan kaldırmaz, sadece şifreyi değiştirir. Giriş yapıldığında, platform hala IP'yi, tarayıcı parmak izini ve oturum geçmişini görür. Ayrıca birkaç kendi WebAuthn sinyalini alır:

Anahtar kimliği (credential ID). "Hesap — kimlik doğrulayıcı" çifti için benzersizdir.
AAGUID — kimlik doğrulayıcı modelinin kimliği. Google gibi siteler, hesap ayarlarında anahtarı bu şekilde imzalar: "iCloud Anahtar Zincirinde oluşturuldu", "Google Şifre Yöneticisinde" gibi. Bu, cihazınızın benzersiz numarası değildir, ancak profilin efsanesiyle eşleşmesi gereken başka bir özelliktir.
BE ve BS bayrakları (yedekleme uygunluğu ve yedekleme durumu), bu anahtarın senkronize olup olmadığını veya cihaza bağlı olup olmadığını gösterir.

Sonuç: "mobil" profil, Windows Hello'dan anahtar ile giriş yaptığında, Brezilya'nın saat diliminde ve Almanya'dan IP ile bir iPhone gibi mantıksız görünür. Anahtar, proxy ve parmak izi ile aynı efsaneye uymalıdır.

Aşamalı şema: bir hesap — bir profil — bir depo — bir IP

Envanterinizi çıkarın. Hesaplarınızın zaten passkey'leri olduğu veya oluşturma teklifinin geldiği platformları yazın: Google, Microsoft, büyük pazar yerleri ve sosyal medya. Her hesabın güvenlik ayarlarında, kaç anahtarın kaydedildiğini ve nerede oluşturulduğunu görebilirsiniz. "Windows Hello" ve "iCloud Anahtar Zinciri" gibi beklenmedik kayıtlar silinmek için adaydır.
Çalışma profilleri için sistem anahtar depolamasını devre dışı bırakın. Profillerin çalıştığı tarayıcıda, yerleşik yöneticide şifreleri ve erişim anahtarlarını kaydetmeyi kapatın. Çalışma bilgisayarında Windows Hello veya iCloud bağlantısında anahtar oluşturmayın. Anahtar oluşturma penceresi "bu bilgisayar" seçeneğini sunuyorsa, başka bir yöntem seçin.
Her hesap için bir depo seçin. Kural basit: depo, profillerle aynı şekilde ayrılmalıdır. Seçenekler:
- her hesap veya bir müşterinin bir grup hesabı için ayrı şifre yöneticisi deposu;
- en değerli hesaplar için bir donanım anahtarı (FIDO2);
- otomasyon için — programlı kimlik doğrulayıcı, bunun hakkında 6. adımda.
Tüm hesaplar için tek bir depo, hesapları birbirine bağlamanın en yaygın yoludur.
Anahtarı yalnızca "doğal" profilden kaydedin. Aynı profil, aynı parmak izi, aynı proxy ile sabit oturum, aynı coğrafya, normal hesap çalışması sırasında. Anahtar kaydetme, hassas bir eylemdir ve platformlar buna dikkat eder. Prosedür sırasında IP değişikliği genellikle ek bir kontrol ile sonuçlanır. Bir profil için tek bir adresi nasıl koruyacağımızı, sticky oturum veya profil için proxy rotasyonu makalesinde ayrıntılı olarak ele aldık.
Yedek bir giriş bırakın. Kaybolan bir depo, kaybolan bir hesabı ifade eder. Her hesap için ikinci bir giriş yöntemi gereklidir: başka bir depoda ikinci bir passkey, TOTP ile şifre veya anahtardan ayrı saklanan kurtarma kodları. Microsoft, Entra'da kullanıcıları 2027 Şubat'a kadar kimlik avına dayanıklı yöntemlere geçirmeyi açıkça talep ediyor. Kayıt penceresinin kapanmasını beklemeyin.
Otomasyonda sanal kimlik doğrulayıcı kullanın. Chrome DevTools Protokolü'nde WebAuthn alanı vardır. addVirtualAuthenticator yöntemi, ctap2 protokolü ve internal (platform) veya usb/hybrid taşıma ile bir programlı kimlik doğrulayıcı oluşturur. hasResidentKey ve hasUserVerification parametreleri, anahtarın kimlik doğrulayıcıda saklanmasını ve kullanıcının doğrulanmasını sağlar. getCredentials kayıttan sonra anahtarı tamamen döndürür: credentialId, rpId, userHandle, signCount ve PKCS#8 formatında özel anahtar. addCredential bir sonraki başlatmada onu geri koyar. Sonuç olarak, yalnızca sizin gizli deponuzda yaşayan ve belirli bir hesabın oturumuna bağlanan bir anahtar elde edilir. İki uyarı: alan deneysel olarak işaretlenmiştir ve WebAuthn'ı test etmek için oluşturulmuştur, ayrıca dışarı aktarılan özel anahtar, bir şifre seviyesinde bir sırdır ve buna göre saklanmalıdır.
Anahtarları manuel olarak değil, Credential Exchange ile taşıyın. Yöneticinizi değiştiriyorsanız veya hesapları farklı depolara dağıtıyorsanız, FIDO standardına göre yerleşik dışa aktarma yöntemini kullanın: Apple Passwords, 1Password, Bitwarden, Dashlane, DuckDuckGo, Devolutions'da desteklenmektedir. MacOS'ta bazı uygulamaların bu mekanizmayı henüz uygulamadığını unutmayın.

Tehlikeler

Varsayılan senkronizasyon. "Bu cihazda" oluşturulan bir anahtar, hemen iCloud veya Google bulutuna gidebilir ve bu hesabın tüm cihazlarında, kişisel telefonunuzda dahil olmak üzere görünebilir.
QR ile çapraz cihaz girişi. "Telefonla QR'yi tarayın" senaryosu (hybrid taşıma) gerçek telefonunuzu kendi anahtarlarıyla profil oturumuna bağlar. Çalışma profilleri için bu gereksiz bir bağlantıdır.
Tüm çiftlikte aynı AAGUID olması normaldir. Milyonlarca insan aynı yöneticiyi kullanıyor. Tehlikeli olan, aynı sağlayıcı değil, ortak anahtar veya ortak depodur.
Passkey "kirli" girişi düzeltmez. Eğer bir hesap, zaten komşu hesaplarda görünmüş bir IP ile veya platformun sevmediği bir veri merkezinden giriş yapıyorsa, güçlü kriptografi yardımcı olmaz. Risk, sinyallerin toplamına göre değerlendirilir.
İkinci faktörü de izole etmek gerekir. Eğer yedek giriş TOTP ise, sırlar da hesaplara dağıtılır ve kişisel telefonunuzda tek bir uygulamada saklanmaz. 2FA ve proxy'yi nasıl bağlayacağımızı, proxy üzerinden iki faktörlü kimlik doğrulama makalesinde ele aldık.

Hangi proxy gerekli ve neden

Passkey ile giriş yaparken en önemli şey sürekliliktir: hesap anahtarı kaydetmeli ve ardından aynı ağdan, aynı coğrafyadan giriş yapmalıdır. Bu nedenle:

Anti-detect'teki web profilleri — yerleşik proxy'ler ile hesap ülkesinde sabit oturum. Bunlar ev sağlayıcılarının adresleridir ve "normal kullanıcı evde" efsanesiyle örtüşmektedir.
Mobil platformlar ve mobil efsaneye sahip hesaplar — mobil proxy'ler. Ev ağında anahtar kaydeden bir mobil profil, kendi geçmişinden sapar.
Her istekte döngü parsing için uygundur, ancak hesaplara giriş için değildir. Tüm çalışma oturumu için yeterli bir aralık belirleyin.

Sonuç

Passkey'ler, girişleri kimlik avına karşı dayanıklı hale getirir, ancak hesaplar arasındaki bağlantı noktasını çerezlerden ve şifrelerden anahtar depolama alanına taşır. Bu nokta genellikle anti-detect profilinin dışında bulunur: Windows Hello, iCloud, Google hesabı veya yöneticinin ortak deposunda. Çalışma şeması şöyle görünür: her hesabın kendi profili, kendi anahtar deposu, kendi sabit IP'si ve yedek giriş yöntemi vardır. Otomasyon için CDP'de sanal kimlik doğrulayıcı vardır. Bunu 2027 Şubat'ından önce halledin, Microsoft kayıt ertelemesini durdurduğunda, sonrasında aceleyle ve canlı hesaplar üzerinde çözüm bulmak zorunda kalacaksınız.