Aşırı büyütülen Passkeys'in güvenlik anahtarlarını nasıl işe yaramaz hale getirdiği

• Passkeys'i resident key olarak tanımlayıp zorunlu kılan yaklaşım yayılırsa, Yubikey·Feitian·Nitrokey gibi güvenlik anahtarları sınırlı depolama alanları nedeniyle hızla sınırlarına ulaşır
• non-resident credential, Relying Party'nin sağladığı credential ID'yi güvenlik anahtarının çözüp RP'ye özgü özel anahtarı elde ettiği bir yapıdır; bu nedenle cihaz içinde yalnızca master key saklanır
• Buna karşılık resident/discoverable credential, özel anahtarın kendisini güvenlik anahtarında saklar; bu yüzden her hesap bir slot kullanır ve Nitrokey 8, Yubikey ise genelde yalnızca 20~32 adet destekler
• CTAP2.0 güvenlik anahtarlarında resident key'ler tek tek silinemez; tam sıfırlama gerekir ve bu sırada master key de değiştiği için mevcut non-resident key'ler bile artık çalışmaz
• Hizmetler ve kütüphaneler resident key'i varsayılan olarak zorunlu tutarsa, 150'den fazla hesap kullanan kullanıcıların birden çok güvenlik anahtarı ve yedek anahtar yönetmesi gerekir; bu da istedikleri authenticator'ı özgürce seçmelerini zorlaştırır

---

Resident key neden sorunun merkezinde

• Passkeys'e yönelik aşırı beklentilerin güvenlik anahtarlarını eski cihazlar gibi gösterebileceği endişesinin merkezinde resident key bulunuyor
• Güvenlik anahtarlarının hesap sayısını “sınırsız” gibi desteklediği algısı, çoğu durumda non-resident credential yöntemine dayanıyor
• Resident key, güvenlik anahtarı içindeki depolama alanını gerçekten tükettiği için hesap sayısı arttıkça cihazın sınırları hemen görünür hale geliyor

Non-resident credential nasıl çalışır

• Non-resident credential'da Relying Party, kimlik doğrulama sırasında credential ID'yi tarayıcı üzerinden güvenlik anahtarına iletir
• Credential ID, yalnızca güvenlik anahtarının çözebileceği şifreli bir blob'dur ve çözme sonucu ilgili Relying Party'ye özel anahtar elde edilir
• Güvenlik anahtarı, çözülen özel anahtarla challenge'ı imzalar ve imzayı tarayıcıya ve Relying Party'ye geri döndürür
• Bu yapıda özel anahtar güvenli enclave içinde kalıcı olarak bulunmaz; güvenlik anahtarının içinde yalnızca master key vardır
• Credential ID, AES-128 ile şifrelenir ve HMAC uygulanır; bu yüzden dışarıdan değiştirilmesi ya da çözülmesi zordur
  • AES-128 kırılıp güvenlik anahtarı olmadan özel anahtar çözülebilse, TLS şifrelemesi ya da SSH de saldırıya açık olurdu şeklinde bir karşılaştırma yapılıyor

Resident/discoverable credential farkı

• Resident key ya da discoverable credential, özel anahtarın güvenlik anahtarı içinde saklandığı yöntemdir
• Relying Party boş bir credential ID listesi gönderdiğinde, güvenlik anahtarı ilgili RP için kullanılabilecek anahtarı bulur, seçer ve imzalar
• Bu yapı, dışarıdan credential ID alıp bunu master key ile çözme yöntemine dayanmaz
• Bunun yerine her credential güvenlik anahtarının iç alanını kaplar; dolayısıyla resident key slot sayısı fiili hesap sınırı haline gelir

userVerification, resident key'den ayrı bir kavramdır

• Bir credential'ın userVerification'ı zorunlu kılması için mutlaka resident olması gerektiği yönünde bir karışıklık var, ancak bu iki kavram birbirinden ayrıdır
• Güvenlik anahtarı yalnızca dokunuşla presence doğrulamakla kalmaz, içeride PIN veya biyometrik doğrulama yaparak kullanıcının gerçekten kendisi olup olmadığını da denetleyebilir
• Bu davranış userVerification flag ile kontrol edilir ve key residency'den bağımsız çalışır
• Dolayısıyla resident key olmasa bile cihaz kendi başına çok faktörlü bir doğrulayıcı gibi kullanılabilir

Güvenlik anahtarlarının depolama alanı ve CTAP kısıtları

• Resident key cihaz içinde saklandığı için güvenlik anahtarının slot sayısı önemlidir
  • Nitrokey 8 resident key destekler
  • Yubikey genellikle 20~32 adet destekler
  • Bazı anahtarlar resident key'i hiç desteklemez
• Güvenlik anahtarının uyguladığı CTAP standardı da yönetilebilirliği büyük ölçüde belirler
  • CTAP2.1 ve CTAP2.1PRE, resident key'leri tek tek yönetmeye, güncellemeye ve silmeye izin verir
  • CTAP2.0'da resident key silmek için tüm cihazı sıfırlamak gerekir
• CTAP2.0 cihaz sıfırlaması master key'i de sıfırladığı için mevcut non-resident key'ler de artık çalışmaz
• Birçok güvenlik anahtarının CTAP2.0 olma ihtimali yüksektir; Yubico tarafında CTAP sürümü firmware sürümüne göre değişir

Passkeys adının yayılması ve resident key tanımı

• Apple, 2022'de macOS/iOS üzerinde Touch ID ve Face ID'yi WebAuthn authenticator'ı gibi kullanan passkeys özelliğini duyurdu
• Passkeys adı, “webauthn authenticator” ya da “security key”e göre kullanıcılar için daha tanıdık bir adlandırma olarak görülüyor
• Sonrasında passkeys'in anlamı net biçimde sabitlenmeden çeşitli yorumlar ortaya çıktı
  • Rust WebAuthn kütüphanesi ve Relying Party uygulayıcıları, passkeys'i kullanıcının seçebileceği tüm authenticator'ların adı olarak tanımladı
  • Bazı topluluk üyeleri passkeys'i birden çok cihaz arasında senkronize edilen credential olarak adlandırdı
  • FIDO Authenticate konferansında “passkey resident key'dir” tanımı ortaya çıktı ve ardından FIDO da SSS içinde bu tanımı kullandı
• Resident key tanımının dikkat çekmesinin nedenlerinden biri, tarayıcıların planlanan conditional UI özelliğiyle bağlantılı olmasıdır
  • Credential resident key ise kullanıcı adı ve WebAuthn credential'ı otomatik tamamlama ile sunulabilir
  • Bu da kullanıcının kullanıcı adını elle yazmak zorunda kalmadığı bir deneyim sağlar

Resident key zorunluluğunun yarattığı kullanıcı sorunu

• WebAuthn kütüphaneleri tüm kayıtlar için resident key'i zorunlu kılacak şekilde yönlendirilirse, sınırlı depolama alanına sahip güvenlik anahtarları hızla dolar
• Örneğin bir parola yöneticisinde 150'den fazla kayıtlı parola varsa, bunların tümünü resident key'e dönüştürmek için en az 5 Yubikey gerekir
• Yedekler de hesaba katıldığında 10~15 Yubikey yönetmek gerekebilir
• Bu, güvenlik anahtarını seçen kullanıcılar için kötü bir kullanıcı deneyimidir ve passkeys'in resident key zorunluluğu yüzünden güvenlik anahtarı kullanımı başlı başına zorlaşabilir
• FIDO doğrulama anahtarı pazarlamasında “sonsuz key pair storage” ya da “kayıtlı hesap sayısında sınır yok” gibi ifadeler kullanılıyor, ancak bunlar non-resident key için doğru olsa da resident key zorunluluğuyla çelişiyor
• WebAuthn Work Group'un hedeflerinden biri, kullanıcıların istedikleri authenticator'ı dezavantaj yaşamadan özgürce seçebilmesini sağlamak; resident key zorunluluğu ise bu hedefle uyuşmuyor
• Passkey ortamında düzgün çalışabilecek authenticator türleri olarak Apple passkeys, Android passkeys, WebAuthn destekleyen parola yöneticileri, TPM 2.0 kullanan Windows ve Touch ID'yi TPM gibi kullanan macOS üzerindeki Chromium tabanlı tarayıcılar gösteriliyor

Olası çözüm yönleri

• rk=preferred davranışını değiştirip güvenlik anahtarlarında resident key oluşturmama seçeneği var
  • Şu anda Relying Party, resident key isteği düzeyini discouraged, preferred, required seçeneklerinden biri olarak belirleyebilir
  • Bugün rk=preferred, roaming authenticator olan Yubikey'de bile resident key oluşturuyor ve sonuçta rk=required ile benzer davranıyor
  • preferred, “yalnızca depolama alanı sınırsızsa resident key oluştur” şeklinde yumuşatılırsa Android/iOS resident key oluştururken güvenlik anahtarlarının depolama alanı tüketilmeyebilir
  • WebAuthn WG bu değişikliğe henüz direnç gösteriyor; tarayıcıların bunu ayrıca uygulaması ise pratikte Chrome ekibinin kararına bağlı
• Passkey kütüphanelerinin rk=discouraged kullanmasını istemek de bir başka yöntemdir
  • rk=required, güvenlik anahtarlarını dışlayabilir
  • rk=discouraged, Android kullanıcılarının conditional UI almasını engelleyebilir
  • Ancak kullanıcı adı için zaten otomatik tamamlama yolları bulunduğundan, bu güvenlik anahtarlarını dışlamaktan daha iyi görülüyor
• FIDO'dan resident key depolama alanını bir sertifikasyon şartı haline getirmesi de istenebilir
  • Bugün FIDO, doğrulama cihazları için depolama kapasitesi zorunluluğu getirmiyor
  • Eğer FIDO resident key istiyorsa, sertifikalı cihazların binlerce resident key saklayabilmesi gerektiği savunuluyor

Sonuç

• Passkeys'i resident key olarak gören aşırı yaklaşım, güvenlik anahtarı kullanıcılarının çevrimiçi ortamda istedikleri authenticator'ı seçmesini engelleyebilir ya da bunu ciddi biçimde zorlaştırabilir
• Sorun, passkeys'in kendisinden çok, sınırlı depolama alanı ve yönetim yeteneğine sahip güvenlik anahtarlarına resident key zorunluluğunun topluca uygulanmasında yatıyor

[GN⁺]

Hacker News görüşleri

• Kriptografinin kendisinden biraz farklı bir konu ama annem Gmail’e giremediği için panik halinde aradı. Meğer Google yeni Android telefonu otomatik olarak passkey olarak kaydedip bunu varsayılan giriş yöntemi yapmış, ama arayüz aşırı kafa karıştırıcıymış
  Şifreyle giriş yapmak için ikinci seçeneğe basmasını ya da passkey’in ne olduğunu anlamasını beklemek bence fazla. “Android’e passkey gönderdik” dedi ama telefona bildirim gelmedi ve 30 dakika bakmamıza rağmen çözemedik. Otomatik kaydedilen passkey’i silemedik, varsayılan kimlik doğrulama akışını da kapatamadık. Google’ın UX’i berbat ve düşük segment bir Samsung telefondaki değiştirilmiş Android sürümünü büyük ölçekli bir kimlik doğrulama sisteminin temeli olarak görmek aptalca bir karar gibi duruyor

  • Google iki adımlı doğrulamada da aynı sorun var. “S21’e bildirim gönderdik” diyor ama gerçekte kilidi açılmış S21 elinizde olsa bile 3 denemenin 1’inde bildirim gelmiyor ya da ancak 5 dakika sonra geliyor
    Bu, son dönemde Google’da yaşadığım birçok sorundan sadece biri. Eskiden gizlilik yüzünden kabaca kaçınmaya çalışıyordum; artık Google kullanımını olabildiğince azaltmak için ciddi çaba harcıyorum. Google Maps’te işletmem hiçbir sebep olmadan kaldırıldı ve yeniden kaydetmek 2 hafta sürdü; bir insanla telefonda konuşmak ise imkansızdı. Her destek e-postasında bir telefon numarası veriyorlar ama o reklam destek hattı ve askıya alınmış işletme hesabı için hiçbir şey yapamıyor; üstelik Google Business ekibinin o numarayı destek için verdiğine bile inanmak istemediler. Google Ads destek çalışanına, Google Business tarafında biriyle konuşmanın hiçbir yolu olmadığını kabul ettirmek için 30 dakika boyunca aynı soruları tekrar etmek zorunda kaldım. Artık resmen anti-Google vaizi oldum
  • İstenmeyen “telefonunuza bildirim gönderdik” doğrulama talepleri yüzünden işletmemi Google ekosisteminden çıkarmayı ciddi ciddi düşünüyorum. Dünyanın öbür ucundan aniden giriş yapıyorsam ya da normalde hep Linux kullanırken tarayıcı Windows olarak algılanıyorsa bunu anlarım; ama gizlilik odaklı tarayıcı ungoogled chromium kullanınca aynı IP’de bile her doğrulamada bu oluyor
    Telefonun şarjı bittiyse ne olacak? Telefonu kaybettiniz ve konum hizmeti kimlik bilgilerini geri almak için e-postanıza şifre sıfırlama göndermeniz gerekiyor ama e-postanıza giriş yapamıyorsanız? O noktadan sonra “soruları yanıtlama” süreci başlıyor. Sorumlusu belli olmayan gizli bir algoritma Linux’ta ungoogled chromium’u şüpheli buluyor ve “Şu anda kullanılabilir depolama alanınızın yüzde kaçını kullanıyorsunuz?” gibi soruların cevabını yanlış hatırlarsanız erişimi geri almak tamamen şansa kalıyor. Bu arada ücretli Google kullanıcısıyım
  • Küçük bir düzeltme: passkey Android’e “gönderilmiyor”. Gmail girişi, tarayıcıda gösterilen QR kodunu taratıp Android’de bulunan passkey’e sahip olduğunuzu kanıtlatma şeklinde çalışıyor
    Yine de anlatılmak isteneni tamamen anlıyorum. Hem UX hem de terminoloji kafa karıştırıcı. Her adım açıklama sunsa bile insanlar, özellikle de aceleleri varsa, küçük açıklama metinlerini atlayıp en büyük ve en gösterişli düğmeye basmaya alışkın; bu yüzden pek yardımcı olmuyor. UX tasarımı açısından gerçekten zor bir problem
  • Bunu yaşadıktan sonra benim için bardağı taşıran son damla oldu. Google’ın kullanıcıyı temel alarak karar vermediğini fark ettim. Parayı reklam verenlerden kazanıyor, hizmetleri de sadece kullanıcıların gitmeyeceği kadar sunuyor ve rakipleri engelleyecek kadar ayakta tutuyor
    Kullanıcılar gitmediği sürece Google umursamıyor ve umursamak zorunda da değil. Başka bir şey istiyorsanız reklam verenin bedel ödemediği bir hizmete ihtiyacınız var. Google kullanıcıyı bir şekilde sömürüyorsa Apple da başka bir şekilde sömürüyor; zehir seçmek gerçek bir seçenek değil
  • Adil olmak gerekirse sorun passkey’lerin kendisinden çok Google’ın ürün UX’inin aptalca olması gibi görünüyor. Google giriş UX’ini kullanıcıların alışık olmadığı biçimde aniden değiştirirse çoğunun kafasının karışması kaçınılmaz

• Apple bunu gerçekten tanımlamadığı için, “passkey tam olarak nedir?” sorusunun cevabını arayan kullanıcılar için düşünürler bu boşluğu doldurmaya başladı
  Ben Apple’ın passkey’i iCloud Keychain ile senkronize edilen bir anahtar çifti olarak tanımladığını anlamıştım. WWDC 2021 sunumunda da passkey’ler “her zaman yanınızda” olmaları, yani cihazlar arası senkronizasyon ve “kurtarılabilir” olmaları nedeniyle güvenlik anahtarlarından farklı olarak tanımlanıyordu. Sonrasında tanımın başka bulut senkronizasyon yöntemlerini de kapsayacak şekilde genişlediği anlaşılıyor. Bence bu yazı yanlış bir ödünleşim kuruyor. Güvenlik anahtarları önemli değil[1]. Çünkü bunları sadece çok az sayıda teknik kullanıcı ve güvenliğe gerçekten önem veren az sayıdaki şirket kullanıyor. Web güvenliğini artırmak istiyorsanız insanları şifrelerden uzaklaştırmanız gerekir ve nüfusun %99’u zorlanmadıkça güvenlik anahtarı kullanmayacaktır. Passkey’lerin, özellikle de işletim sistemiyle derin entegrasyon sayesinde, şifrelerin yerini alma ihtimali yüksek. Kullanıcıların %1’inden azı yerleşik anahtar yuvası yetersizliği yaşıyor diye kimlik doğrulamayı o tarafa göre optimize etmemek gerekir. [1] Bende 3 Yubikey, 3 Yubico güvenlik anahtarı ve 1 SoloKey var

  • Amaç Apple Passkey ürünü değil, sektör genelinde bir girişimdi. 2022’de piyasaya çıktığı sıralarda tanım gevşetildi ve örneğin keşfedilebilir olma ve kullanıcı doğrulama seçenekleri sunan bir “deneyim”e daha yakın hale geldi
    Kullanıcılar yedekleme ve kurtarmayı destekleyen bir passkey sağlayıcısı kullanmayı seçebilir ve güvenen taraf bu sinyali alır. Bu sinyale bakarak şifreyle giriş seçeneğinin kaldırılmasını önerip önermeyeceğine karar verebilir
  • Passkey’ler aslında FIDO Alliance tarafından tanımlanıyor
    FIDO standardına göre passkey’ler şifrelerin yerini alır ve kullanıcıların birden fazla cihazında web siteleri ile uygulamalara daha hızlı, daha kolay ve daha güvenli giriş yapmasını sağlar. Şifrelerin aksine passkey’ler her zaman güçlüdür ve phishing’e dayanıklıdır. https://fidoalliance.org/passkeys/

• rk=required neden var, anlamıyorum. Başta bir seçenek olarak bile olmamalıydı.
  Passkey’ler ve onlarla ilişkili kişiler konusunda sürekli endişeli ve kuşkucu olmamın nedeni de tam olarak bu. Bu insanların, Microsoft gibi büyük şirketlerin güvenliği ve uyumluluğu ciddi biçimde bozup rekabeti öldüren her türlü kötü niyetli piyasa uygulaması için kullanışlı bir araç haline gelmeyecek protokoller tasarlama sorumluluğu var. Ama yazılarda ve gönderilerde tekrar tekrar görülen tavır, “canınız cehenneme, kötüye kullanımı daha da kolaylaştıralım” tavrına daha yakın. Sorun yalnızca yerleşik anahtarlar da değil; örneğin tasdik (attestation) işleme biçimi de şirketleri yok etmek için kolayca kötüye kullanılabilir

  • Buradaki hedef, telefonu passkey’ye dönüştürmek ve onun dışında hiçbir şey kullanılmamasını sağlamak gibi görünüyor. Bu açıdan bakınca yazıdaki her şey anlam kazanıyor
  • Bence bu, tasdik kötüye kullanımından daha az kötü.
    Bir hizmet rk=required ayarladıysa ve platform bunu açmak ya da desteklemek istemiyorsa veya bunu yapamıyorsa, süreç her zaman başarısız olur ve kayıt bile yapılamaz gibi görünüyor. Kullanıcıları sisteme alıp işi büyütmeyi hedefliyorsanız, bu kendi ayağına sıkmak gibi duruyor
  • “Tasdik işleme biçimi şirketleri kolayca yok etmek için kötüye kullanılabilir” derken ne kastedildiğini merak ediyorum

• Güvenlik ya da kriptografi tarafında hiç uzman değilim, bu yüzden bu yazıyı takip etmek çok zordu; başkaları için de öyle olacağını düşünüyorum.
  Yeterli arka plan bilgisi olan birine tuhaf sorular gibi gelebilir ama her bir iki cümlede bir takıldım. “Sonuçta her şey tek bir noktaya, yerleşik anahtarlara çıkıyor” denince bunun nasıl ve neden böyle olduğunu, ayrıca bunun passkey ya da HSM ile bağlantısını anlayamadım. “Keşfedilebilir/yerleşik anahtarın ne olduğunu anlamalısınız” denmesi, tüm yerleşik anahtarların keşfedilebilir anahtar olduğu mu, tüm keşfedilebilir anahtarların yerleşik anahtar olduğu mu, yoksa ikisinin de mi olduğu konusunda belirsiz. “Çoğu anahtarın ‘sınırsız’ hesap desteklediğini görmüşsünüzdür” deniyor ama burada anahtarın passkey mi, HSM’de saklanan anahtar mı, yoksa ikisi de mi olduğu belli değil. “Anahtarla sarılmış anahtar güvenlik anahtarına gönderilir” ifadesi de, HSM’nin sınırsız hesaba uygulanabilmesinin nedeninin bir anahtarı başka bir anahtarla sarıp saklayabilmesi olduğu anlamına mı geliyor, o da kafamı karıştırıyor

  • Asıl mesele, WebAuthn’ın her sitenin depolama alanı tüketen kimlik bilgileri oluşturduğu passkey modeline doğru itilmesi gibi görünüyor. Görüntülenebilir site adı ve kullanıcı hesap adı, kullanıcı kayıt tanıtıcısı, özel anahtar ve diğer öğelerin hepsi depolama alanı kaplıyor.
    Telefonlar 10 bin passkey’yi bile sorunsuz saklayabilirken, modern donanım anahtarları kullanılabilir flash üzerinde toplam yalnızca 25 tane saklayabiliyor olabilir. Bu depolama alanının gerekli olmasının nedeni keşfedilebilirlik. Örneğin GitHub.com giriş sayfasında yeni passkey desteğine tıklarsanız, hesap adını bile girmeden oturum açabilirsiniz. Tarayıcı, bir parola yöneticisine benzer deneyim sunar ve parola yöneticisindeki parolalar gibi passkey’ler de yerelde site hesaplarının kaydı haline gelir. Ama WebAuthn içinde passkey olmayan başka modlar da var. Keşfedilemeyen kimlik bilgilerinde, belirli bir kullanıcı hesabı için bir tanıtıcı listesi sağlanması gerekir; bu tanıtıcılar kayıt sırasında anahtar tarafından verilmiştir. Kimlik doğrulama sırasında yalnızca tanıtıcıyla eşleşen kimlik bilgileri seçenek olarak sunulur. Donanım güvenlik anahtarları bunu, gelecekteki kriptografik işlemler için gereken kaydı tanıtıcının kendisinde saklayarak kullanır; bu mod flash depolamayı tüketmez. Kullanıcı kullanıcı adını girince, bir API tanıtıcı listesini döndürür ve bu liste güvenlik anahtarına uygulanarak depolama sınırı olmadan kimlik doğrulama yapılabilir. Ancak birçok site, hesabın var olup olmadığını açığa vurmama politikası izler. “Bu hesap mevcutsa kısa süre içinde bir e-posta alacaksınız” gibi kurtarma akışlarını görmüşsünüzdür. Giriş sürecinin, bir kullanıcı adı ya da e-postaya bağlı hesap bulunup bulunmadığını ve kaç kimlik bilgisinin kayıtlı olduğunu saptayan bir API sunması, site açısından kabul edilmesi zor bir şey olabilir. Sonuçta sitelerin bu süreci yaygın biçimde benimseyip mevcut donanım sınırlarını etkilemesindense, depolama alanı 10 kat fazla güvenlik anahtarlarının ortaya çıkması daha olası görünüyor
  • Yazının argümanının zayıf olduğuna katılıyorum. Ana fikir, güvenen tarafın WebAuthN protokolünde rk=required belirtebilmesinin zararlı olduğu iddiası. Çünkü bu, birçok TPM donanımının passkey cüzdanı/veritabanı gibi çalışamamasına yol açıyor.
    Yorumların çoğu muhtemelen bu noktada hemfikirdir. Ama bu, yazarın yazının yarısını passkey tanımı tartışmasına ayırarak yarattığı kafa karışıklığını haklı çıkarmaz
  • Yazı, FIDO2 hakkında epey bilgi varsaydığı için kafa karıştırıcı olması normal.
    Passkey’ler FIDO2 üzerinde uygulanır ve özellikle FIDO2 spesifikasyonundaki yerleşik anahtar özelliğini kullanır. FIDO2 donanım kimlik doğrulama aygıtları tam olarak HSM değildir ama benzerdir; Yubikey gibi hem HSM hem de FIDO2 kimlik doğrulama aygıtı olan cihazlar da vardır. FIDO2’de “yerleşik anahtar” ile “keşfedilebilir anahtar” eş anlamlıdır. Spesifikasyonda “yerleşik anahtar” kullanılır ama “keşfedilebilir anahtar” da yaygındır; bu da FIDO’nun yarattığı kafa karıştırıcı terminolojilerden biridir. “Anahtar” burada passkey’yi ya da HSM’de saklanan bir anahtarı değil, Yubikey gibi bir FIDO2 donanım kimlik doğrulama aygıtını ifade eder; buna genelde “güvenlik anahtarı” denir. FIDO2 donanım kimlik doğrulama aygıtları, yerleşik anahtarlar kullanılmadığı sürece pratikte durumsuzdur ve hiçbir şey saklamadıkları için sınırsız sayıda hesaba kaydedilebilirler. Bir hesaba kaydedildiklerinde cihazda EdDSA gibi bir anahtar çifti üretilir ama saklanmaz; bunun yerine özel anahtar, örneğin AES256 anahtarı gibi gömülü bir ana anahtarla şifrelenir. Ardından düz metin açık anahtar ve şifrelenmiş özel anahtar, saklaması için google.com gibi güvenen tarafa gönderilir. Kimlik doğrulama sırasında şifrelenmiş özel anahtar, yani “sarılmış” anahtar, kimlik doğrulama aygıtına gönderilir; aygıt içinde çözülür ve dijital imza üretmek için kullanılır. Ancak FIDO2, yerleşik olmayan anahtarların nasıl uygulanacağını fiilen belirtmez; sarılmış anahtar yalnızca yöntemlerden biridir. FIDO2 sadece özel anahtarın kimlik bilgisi kimliğinden güvenli biçimde türetilebilir olmasını şart koşar; kimlik bilgisi kimliği ise sarılmış anahtar olabilir de olmayabilir de, rastgele veridir

• Bence duruma fazla karamsar bakılıyor. Zayıf parolaları ve parola tekrar kullanımını ortadan kaldırarak sıradan hesap ihlallerinin %99’unu engelleyen yeni kimlik doğrulama standardının faydalarından yararlanmak istiyorsanız, 2013’ten beri dayanan eski Yubikey’den vazgeçip 30 dolar harcayarak yükseltme yapmanız gerektiği şeklinde de görülebilir

  • Neden yükseltme yapmaya zorlanmam gerektiğini anlamıyorum. Yerleşik olmayan anahtarlar da zayıf parolaları ve parola tekrar kullanımını ortadan kaldırıyor. Yerleşik anahtarlar sadece, anahtarı taktığınızda servisin bunun hangi hesaba ait olduğunu bilmesi gibi küçük bir iyileştirme ekliyor; bu da şu anda kullanılan mevcut kimlik doğrulama cihazlarının hepsini çöpe atmayı haklı çıkaracak bir neden gibi görünmüyor
  • 5 serisinin teknik kılavuzuna baktım, yalnızca 25 tanesini destekliyor. Şu an yalnızca 2 tane var ama TOTP sayısı 25’ten çok daha fazla
    Bio FIDO modeli nasıldır bilmiyorum ama benzerse, YubiCo’nun çok sayıda yerleşik anahtara uygun bir ürünü olmayabilir. Düzeltme: Bio da aynı 25 sınırına sahip
  • Hatta bunun fazla iyimser bir yorum olduğunu düşünüyorum
    Paylaşılan yerleşik anahtarlar, kısa süreli geçici kullanım dışında var olmamalı. Bu bir sorumluluk yükü, bir güvenlik riski ve kötü güvenlik uygulamalarını teşvik ediyor. En iyi örnek, güvenlik açısından kusurlarla dolu olan TOTP. Paylaşılan sırları birden fazla cihaz arasında paylaşmak ya da yedeklemek istememelisiniz, ama bunun mümkün olması ve özensiz 2 aşamalı kimlik doğrulama uygulamalarının istisna değil standart haline gelmesi nedeniyle fiilen buna zorlanıyorsunuz. Şu anki gidişata bakılırsa passkey’ler de aynı derecede kusurlu ve kullanıcıya düşmanca bir yöne gidecek gibi görünüyor
  • Yine de çok şey değişmiyor. Benim anahtarım yalnızca 25 yerleşik anahtar tutabiliyor, ama parola yöneticisinde saklanan parolalar 25’ten fazla
  • İleride bu “avantajı” seçmek dışında başka seçenek kalmayacağından endişeliyim. Siteler yeni kimlik doğrulama standardını uygularsa, mevcut kullanıcı adı/parola/2 aşamalı kimlik doğrulamayı da alternatif olarak sürdürmeye devam edecekler mi?

• “Sahip olduğunuz ama kaybedebileceğiniz bir şeye” dayanan kimlik doğrulama temelden bozuk. Cihazı kaybederseniz ya erişiminizi de kaybedersiniz ya da en zayıf halka başka bir yerde olmak zorundadır; bu durumda o üstün güvenliğin pek anlamı kalmaz

  • Yedek kodları yazdırabilir veya ikinci bir çekmece anahtarı ekleyebilirsiniz. Fikir kendi başına harika, ancak pazarlaması çok kötü, genel kullanıcı için kurulum akışı tuhaf ve AirDrop yapılabilen ya da bulutla senkronize olan anahtarların itilmesi de kötü bir fikir. En önemli sorun ise anahtarların maliyeti
  • Parolalar da buna dahil değil mi? İnsanlar parolalarını da sık sık kaybediyor
    Sonuçlar gösterecektir ama passkey’ler yaygın biçimde benimsenirse, çoğu kişi için hesap kilitlenmesi daha sık değil daha az sık hale gelecek gibi görünüyor

• Donanım anahtarlarının depolama alanı neden bu kadar sınırlı, merak ediyorum. Anahtarın içine, güvenli işlemcinin erişebileceği bir yüksek kapasiteli depolama aygıtı daha eklemenin maliyeti ne kadar artar ki
  Bu yüksek kapasiteli depolama aygıtı elbette güvenli işlemci tarafından güçlü biçimde şifrelenir ve her şey silindiğinde o anahtar da birlikte silinecek şekilde yapılabilir

  • Çünkü güvenli kurcalamaya dayanıklı depolama pahalıdır
    Güvenlik açısından bakarsanız, depolama alanı 0 olan bir güvenlik anahtarının en iyi güvenlik anahtarı olduğunu bile söyleyebilirsiniz. Güvenlik belirteçlerini paylaşılan sırlar vb.den türetmek yerine güvenlik anahtarına ya da güvenli bölgeye enjekte edip saklayan protokoller genellikle ciddi kusurlara sahip olmuştur. Bazen bu, TOTP’de olduğu gibi temel bir güvenlik kusurudur; bazen de karmaşıklık kusurudur. Aynı şekilde HSK/2 aşamalı kimlik doğrulama için kullanılan güvenlik anahtarlarını birden çok cihaz arasında paylaşmak da kesinlikle istenmemelidir. Bir cihazda sızıntı olursa hepsi bozulur demektir. Bunun yerine her cihaz için ayrı bir anahtar olmalıdır ve giriş sağlayıcısı ya da sunucu tarafında bu ek yük büyük resimde göz ardı edilebilir düzeydedir
  • Bu tür cihazları olabildiğince “aptal” tutmaya yönelik bilinçli bir tasarım tercihi gibi görünüyor. Depolama eklediğiniz anda diğer depolama aygıtlarıyla aynı zafiyet yüzeyi açılır, sonra hesaplama yetenekleri eklenir ve sonunda elinizde aptal bir Yubikey değil, tam teşekküllü bir bilgisayar olur
  • Depolama artırılabilir belki, ama içine ne kadar çok şey koyarsanız arıza olasılığı da o kadar artar. Mevcut anahtarlar, çalışmaz hale gelmeden önce oldukça sert kullanıma dayanıyor
    Küçük depolamanın biraz daha kolay denetlenebilir olması gibi bir avantajı da var. Elbette günümüz ölçütleriyle bakıldığında, o küçük boyut bile pratikte denetlenebilir sınırları zorluyor olabilir
  • Mesele hafızanın sınırlı olması değil; daha çok, baştan bellek sınırı olmayacak şekilde tasarlanmış olmaya yakın
    TPM’ye bakarsanız, bir şeye imza atılırken her seferinde girilen şey imzalanacak veri ile mühürlenmiş özel anahtardır. Mühürlenmiş anahtar, TPM’nin ürettiği özel anahtarın TPM’ye gömülü bir anahtarla simetrik olarak şifrelenmiş halidir. Bu mühürlenmiş anahtar yüksek kapasiteli depolama aygıtında saklanır ve her imzalama işleminde TPM’ye verilir. Bu tasarım sayesinde, yüksek kapasiteli depolama aygıtının izin verdiği kadar çok anahtara sahip olunabilir
  • Modüler de yapılabilir gibi görünüyor. USB bellek gibi duran ama arkasında YubiKey Nano gibi küçük form faktörlü bir güvenlik anahtarının takılacağı bir yuva bulunan bir ürün satılabilir
    Güvenlik anahtarını yuvaya taktığınızda USB bellek, güvenlik anahtarına depolama sağlar ve bilgisayara bir güvenlik anahtarı gibi görünür. Güvenlik anahtarı takılı değilken ise normal bir USB bellek gibi çalışır. Normalde güvenlik anahtarını takılı tutarsınız; daha fazla depolama gerektiğinde daha büyük bir depolama modülü alır, güvenlik anahtarını mevcut modülden çıkarıp bilgisayara takarak şifreli dosyaları kopyalar, ardından yeni modüle taşıyıp güvenlik anahtarını yeniden takarsınız

• Başta fiziksel güvenlik anahtarını passkey olarak kullanmanın iyi bir fikir olup olmadığından emin değilim. Passkey, parola yerine geçecek bir çözüm olarak tasarlandı ve bunun için genelde telefonda ya da masaüstünde bulunan, “sahip olunan şey”e ek olarak kilidi açmak için “bilinen bir şey” ya da “kişinin kendisi”ni gerektiren iki faktörlü özellik gerekli gibi görünüyor
  Bence fiziksel güvenlik anahtarlarını, özellikle kopyalamaya direnç ana işlev olduğunda, belirli yüksek güvenlikli bağlamlarda passkey’e ek olarak kullanılan ikinci aşama doğrulama olarak bırakmak daha iyi. Bu kullanımda ikinci aşamaya gelindiğinde zaten giriş yapılmak istenen hesabın ne olduğu biliniyor, dolayısıyla yerleşik anahtar gerekli değil. Ayrıca yerleşik anahtarların sunduğu otomatik tamamlama özelliğinin passkey UX’i için önemli olduğunu düşünüyorum. Bunu, yalnızca güvenlik meraklılarının kullandığı azınlık anahtarlarla geriye dönük uyumluluğu korumak uğruna feda etmek mantıklı değil. Elbette yerleşik anahtar olmadan da bu UX’i korumanın bir yolu varsa sorun yok

  • Genel olarak aynı fikirdeyim. Şu anda herkesin yaklaştığı fikir, güvenilir yerel şifrelenmiş bir güvenlik kasasına sahip olmak ve o sisteme karşı kimliğini doğrulamak gerektiği yönünde. Bu bir parola da olabilir, bir anahtar da
    Hesap açtığınız dünyadaki her hizmetin güvenli ya da phishing’e karşı dayanıklı olduğunu varsaymaktansa, seçtiğiniz parola yöneticisinin daha güvenli olduğuna inanmak daha kolay. Bu yüzden passkey kullandığınız noktada genelde zaten işletim sistemi ya da passkey’i elinde tutan parola yöneticisi gibi daha güvenli bir bağlam içinde kimliğinizi kurmuş oluyorsunuz. Ayrıca şu anda ya da yakın zamana kadar donanım anahtarını desteklemeyen yerlerin yakın gelecekte de desteklememiş olma ihtimali yüksek. Buna karşılık passkey çözümünün benimsenme maliyeti kabaca yazılım desteği düzeyinde olduğu için çok daha kolay ve yatırım getirisi daha yüksek olabilir. Tabii bu esas olarak web siteleri için geçerli; passkey, web siteleri için “standartlaştırılmış SSH anahtarı”na daha yakın. Donanım anahtarı ise passkey’lerin bulunduğu kasayı gerçekten açan ikinci faktör olarak daha kullanışlı görünüyor ve burada parola da birlikte gerekebilir. Donanım anahtarlarının ömrü henüz biraz daha var gibi. GitHub, Gmail vb. yerlerde varsayılan yöntem olarak kullanınca, passkey giriş akışı gerçekten çok iyi
  • Parola yöneticileri zaten parolaları fiilen gereksiz hale getirdi. Ana parola dışında hiçbir parolamı bilmiyorum. Passkey’ler, aslında hiç ihtiyaç duymadığımız gereğinden fazla karmaşık bir çözüm
    Tarayıcıda, parola yöneticisinin bağlanabileceği basit bir HATEOAS API’si olsa yeter; web uygulaması da tarayıcıyı tetikleyen HTML’i sunsa yeter. Sonra parola yöneticisi kullanıcıyı nasıl doğrulayacağına, yani kullanıcının istediği yönteme karar verir ve o web sitesinin gizli değerini otomatik enjekte ederek kullanıcıyı otomatik giriş yaptırır. Bir sorun çıkarsa e-posta sıfırlama kullanılır. “Aşırı gösterişli güvenlik” isteyen web sitelerinin daha karmaşık bir şey istemesini anlıyorum. Ama kullanıcının isteğe bağlı olarak daha yüksek güvenlik düzeyini açabilmesi gerekir. Örneğin çoğu web sitesi için, parola yöneticisinin rastgele parola kullandığı varsayılırsa, basit bir parola hash’i yeterlidir. Bunu her web sitesi uygulayabilir, her parola yöneticisi uygulayabilir ve sıradan kullanıcıların %99’unun mevcut parola kullanımından daha iyidir. Bu varsayılan kimlik doğrulama yöntemi olabilir. Sonrasında TOTP, OIDC, açık anahtar kriptografisi vb. istenirse sunucu bunu ilan eder ve istemci isteğe bağlı olarak katılıp doğrulamayı sürdürür. Her site ve her kullanıcı en güvenli yöntemi kullanmak zorunda değil. Önce güvenliğin taban seviyesini yükseltmeyi kolaylaştıralım, daha güçlü güvenlik de zaman içinde isteğe bağlı seçilsin
  • Yubikey ile parolasız kimlik doğrulama (FIDO2) yaparken, cihaza dokunmanızı istemeden önce PIN talep ediyor. PIN’i çok fazla yanlış girerseniz Yubikey kilitleniyor ve cihazın sıfırlanması gerekiyor; ayrıca o anahtarın kimlik doğrulama için kullanıldığı mevcut kayıtların tamamı geçersiz hale geliyor
    Birisi donanım token’ımı çalsa bile bu büyük bir sorun gibi görünmüyor. https://support.yubico.com/hc/en-us/articles/4402836718866-U...
  • Düşününce, temel sorunu “biyolojik bir varlığı elektronik bir sisteme doğrulamak” diye ifade edebiliriz
    Parola kullandığınızda doğrulama arayüzü klavyedir ve parolayı giren kişinin iddia ettiği kişi olduğuna dair gerçek bir garanti yoktur. Parolalar kolayca aktarılabilen bilgiye dayandığı için pek çok şekilde ele geçirilebilir. Doğrulama arayüzünü cihazdan cihaza taşımak çok daha iyi. Kolay aktarılabilen bilginin aktarılmadığını varsaymak yerine, biyolojik varlığın doğrulama cihazını yönetebildiğini varsayıyoruz; insanlar da zaten bu tür işlerde oldukça iyidir. Doğrulama kanal sayısını artırarak sistemi daha sağlam hale getirebiliriz; ayrıca uzak sisteme doğrulama için kullanılacak cihaz ile biyolojik varlık arasındaki doğrulamayı FaceID gibi yöntemlerle sınırlayabiliriz. Özünde telefon ya da anahtar gibi bir cihazın o kişinin kendisi olduğunu varsaymak daha doğal geliyor. Evde sadece Netflix parolasını değil, bir kredi kartını da paylaşıyoruz. Pratik nedenlerle bir kredi kartını yedek anahtarla birlikte bırakıyoruz; ev için bir şey alınması gerektiğinde herkes alıp kullanabiliyor. Kartın düzgün kullanılacağına güveniyoruz ve herkes PIN’i biliyor, ama temassız ödeme yaygın olduğu için buna neredeyse hiç gerek kalmıyor. Masrafları takip edip sonra birbirimizle hesaplaşmaktan çok daha doğal. Muhtemelen yasa dışıdır ve banka bilse kartı iptal ederdi ama yine de böyle. BT sistemlerinin, gerçek dünyaya benzer şekilde çalışarak insan davranışına yaklaşmaya acil ihtiyacı var. Çoğumuz BT sistemleriyle içli dışlı olduğumuz için idare ediyoruz; ama teknolojiye aşina olmayan insanlar iPhone parolası ne, iCloud parolası ne, Gmail parolası ne, neden WhatsApp’a kod girmem gerekiyor gibi gündelik sorunlarda bile zorlanıyor. Doğrusu ben de Mastadon’u anlamadım. Muhtemelen Mastadon phishing’ine tamamen savunmasız olurum; ekran ne girmenizi isterse onu girerdim
  • Passkey’lerin parola yerine geçtiğini söylemek doğru değil

Passkey'ler, adlarının da ima ettiği gibi, ikinci faktör olarak geliştirilmiş FIDO2 U2F standardına parazit gibi tutunuyor. Yerleşik anahtarlar, PIN eşliğinde cihaz içi iki aşamalı kimlik doğrulama içindir ve akıllı kartların işlevsel karşılığıdır. Birileri, muhtemelen Apple, yalnızca WebAuthn'ın tek kimlik doğrulama faktörü olmak için yeterli olduğunu düşünmüş gibi görünüyor. Ne yerleşik anahtar ne de donanım bağı var; anahtarlar iCloud üzerinden taşınıyor ama cihazda TouchID/FaceID ile korunuyor. Sonra da buna passkey markası vuruldu. Asıl hedef iki aşamalı kimlik doğrulamanın kendisi değil. Hedef; phishing, brute force ve credential stuffing saldırılarına karşı güvenli, ayrıca akıllı kartlar kadar uygulanması zor olmayan kullanıcı kimlik doğrulaması. FIDO2 bunu başarıyor. Apple, Google ve Microsoft uygulamalarındaki sorun, kimlik doğrulayan site ile kullanıcının cihazı arasındaki protokol düzeyindeki güvenliğin zayıf olması değil. Protokol aynı. Sorun, sitenin artık kullanıcının kişisel platform hesabına güvenmek zorunda olması; kullanıcının bunu doğru yapılandırdığına ve platformun da gelecekte sürekli doğru davranıp kullanıcının kişisel hesabına yönelik saldırıları düzgün şekilde ele alacağına inanması gerekmesi.

• Bağlam eklemek gerekirse, YC destekli şifresiz kimlik doğrulama şirketi işletiyorum ve bunu büyük kuruluşlara dağıtıyorum. Passkey’lerin tüketici tarafında şifresiz kimlik doğrulamanın cevabı olacağı açık görünüyor, ancak kurumsal ortama henüz bu şekilde yansımış değiller
  Passkey’ler tüketiciler için harika. Çünkü amaç, iCloud varsayılan yedekleme ya da AirDrop benzeri yöntemlerle kimlik bilgilerini diğer cihazlara yedekleyip kişinin kendi acil erişimini mümkün kılmak. Teknik olarak bu kimlik bilgisinin paylaşıldığı cihazlar attestation sağlayamaz. Attestation, anahtar çiftinin Yubikey ya da Apple cihazı gibi belirli bir cihazda üretildiğine dair bir “kanıt”tır. Yubico gibi üreticiler, çıkarılamayan anahtar çifti/sertifikaları anahtara gömülü olarak üretip gönderir ve bu anahtar çiftine erişen harici bir arayüz olmadığı için yöneticiler bunun gerçekten bir Yubikey olduğundan yüksek ölçüde emin olabilir. Attestation yoksa ve anahtar paylaşılabiliyorsa, sorunun nerede başladığı görülebilir. Kurumlar, AirDrop ile paylaşılabilen kimlik bilgilerinin ayrıcalıklı çalışan hesaplarına erişimi riske atmasını üstlenmek istemez. Yubikey’de dijital hırsızlık riski fiilen yoktur. Sonuçta passkey’ler cihaz veya sunucu kilidi açmada da kullanılamaz. FIDO2’nin ve daha da önemlisi işletim sistemi geliştiricilerinin parolaları tamamen bitirmesi için önünde uzun bir yol var. Bugün kurumsal pazarın büyük bölümünde bu boşluğu Yubikey dolduruyor ve bazıları donanıma milyonlarca dolar harcamış durumda. Mevcut haliyle passkey’leri satmak zor olacaktır

  • Passkey bir teknik terim değil, deneyim terimi. Bu yüzden teknik tartışmada kullanıldığında bir noktada çöküyor
    Apple da passkey destekliyor, Android ve Chrome da, Microsoft da, Yubikey de passkey destekliyor. Ancak kullanıcı doğrulaması için kimlik doğrulama prosedürü ve kopyalanabilirlik gibi özellikler ve kısıtlar büyük ölçüde değişebilir. Devlet kurumları passkey destekleyebilir, ancak yalnızca AAL2 gereksinimlerini karşılayan FIPS sertifikalı kimlik doğrulama cihazlarında sunulduğunda buna izin verebilir. En azından şu an için Apple veya Google’dan çıkacak bir şey değil. Kurumlar, MDM yönetim ürünlerinin sunduğu yazılım ve yapılandırmalarla oluşturulan passkey’leri desteklemeyi seçebilir; Apple bunun için beta desteği duyurdu. Ancak devlet-vatandaş hizmetlerinde belirli donanım tabanlı kimlik doğrulama cihazlarını zorunlu kılmaya çalışılırsa büyük sıkıntı yaşanabilir. Vatandaşları 80 doların üzerinde donanım almaya ikna etmek zordur ve web teknolojileri kullanıcı seçimi merkezli geliştirildiğinden WebAuthn API’sinin ve kullanıcı deneyiminin kullanıcı seçimini sınırlamaya yardımcı olacak yönde optimize edilmesi de pek olası değildir
  • Google veya Apple bot önleme, dolandırıcılık tespiti gibi saçma nedenlerle yanlışlıkla hesabı kilitlerse ne olacak?
  • yubikeys 5, passkey olarak kullanılabilir

• Güvenlik açısından bunun gerçekten berbat bir çözüm olduğunu düşünüyorum
  Devlet ve Apple, Google gibi şirketlerin dijital hayatı kontrol etmesi için adeta rüya gibi bir yapı. Parola kullandığınızda bir bakıma durumsuzluğa yakın bir yapı vardır; yani kişisel e-posta hesabınız veya herhangi bir hesabınız varken sınırı geçseniz bile kimse bu hesaba sahip olduğunuzu bilemez, sizden erişimi teslim etmenizi zorla isteyemez, donanımdan erişim unsurunu çıkaramaz ya da cihaza erişimi kaybettiğiniz gerekçesiyle sizi kilitleyemez. Ana anahtarlar ve benzerleri TPM veya güvenli öğede saklansa bile bazı devletler bunlara erişebilir; mesele sadece birkaç yıl ve hesaplama gücü meselesidir. Çoğu durumda bu, belirli bir hesabın kimlik bilgilerine sahip olduğunuzun kanıtı da olur. Cihaz veya işletim sistemi üreticileri, yetkililer tarafından güvenli alana erişim sağlamaya kolayca zorlanabilir; bu da gönüllü olsun ya da olmasın gerçekleşebilir