Geçiş Anahtarı Geri Dönüşü ve Kurtarılması: Önce Tanımlayıcı Yaklaşımı

1. Giriş#

Geçiş anahtarları, geçiş anahtarına hazır cihazların yaklaşık %95'i oluşturmasıyla, geleneksel kimlik doğrulama yöntemlerine gerçek bir alternatif haline gelmiştir. Ancak, en gelişmiş sistemler bile geçiş anahtarlarına erişilemediği (Geri Dönüş - Fallback) veya kaybedildiği (Kurtarma - Recovery) senaryoları ele almak için etkili geri dönüş ve kurtarma stratejilerine ihtiyaç duyar. Bu kılavuz, geri dönüşlerin ve kurtarmaların gerekli olduğu çeşitli senaryoları keşfetmeyi ve olası çözümlerin nasıl göründüğünü tartışmayı amaçlamaktadır.

Geri dönüş ve kurtarma yöntemlerini düşünürken, bunların gücünün birincil kimlik doğrulama yönteminin gücüyle eşleşmesi önemlidir. Bu kılavuz, geri dönüş ve kurtarma yöntemlerini uygun şekilde uyarlamak için geçiş anahtarlarının farklı kullanımlarını, özellikle de geçiş anahtarının bağımsız MFA olarak kullanıldığı bağlamlara odaklanarak ayırt edecektir.

Temel Sorular:

• Hangi Geri Dönüş Senaryoları Mevcuttur? Geçiş anahtarı sistemlerinde ortaya çıkabilecek potansiyel geri dönüş senaryoları nelerdir ve güvenliği sağlamak için bunlar nasıl ele alınmalıdır?
• Kurtarma Nasıl Yönetilmelidir? Özellikle MFA kullanan ortamlarda, geçiş anahtarlarının kullanım modellerine bağlı olarak, güvenli olduklarından emin olmak için kurtarma süreçleri nasıl tasarlanmalıdır?

Bu soruların incelenmesi yoluyla, bu kılavuz, ürün yöneticilerine ve geliştiricilere, güvenliğin kullanıcı deneyimi pahasına olmamasını sağlayarak geçiş anahtarı sistemlerini etkili bir şekilde tasarlamak, uygulamak ve yönetmek için gerekli içgörüleri sağlayacaktır.

2. Tanımlar: Tanımlayıcı, Güvenlik Seviyesi, Geri Dönüş ve Kurtarma#

Geri dönüş ve kurtarma stratejilerine dalmadan önce, kullanacağımız bazı temel terimleri net bir şekilde anlamak önemlidir.

2.1 Tanımlayıcı: E-posta, Telefon Numarası ve Kullanıcı Adı#

Çoğu işletme ve tüketici sisteminde kimlik doğrulama, üç temel tanımlayıcıya dayanır: e-posta, telefon numarası ve kullanıcı adı.

Sistemlerin büyük çoğunluğu, özellikle web tabanlı uygulamalarda, birincil tanımlayıcı olarak e-postayı kullanır. Ancak, önce mobil (mobile-first) veya önce uygulama (app-first) platformları, otomatik olarak eklenebilen SMS tabanlı bir OTP'nin (Tek Kullanımlık Parola) önceden doldurulmasının kolaylığı nedeniyle genellikle tanımlayıcı olarak telefon numarasını kullanmayı tercih eder. Bazı durumlarda kullanıcıların, öncelikle benzersiz bir görünen ad (display name) gerektiren platformlar için, bu tanımlayıcılara ek olarak bir kullanıcı adı belirlemeleri gerekebilir. Ayrıca, özellikle büyük platformlarda, daha fazla esneklik sağlamak amacıyla hem e-posta hem de telefon numarasının kullanılmasına izin veren büyüyen bir eğilim vardır.

İlk kayıt sırasında bu tanımlayıcılar, genellikle onay bağlantısı / OTP (e-posta için) veya bir OTP (telefon numarası için) aracılığıyla doğrulanarak, tanımlayıcının doğru kişiye ait olduğundan emin olunur. Erişimin kaybedilmesi durumunda, önceden doğrulanmış e-posta veya telefon numarası üzerindeki kontrolü kanıtlamak, genellikle hesap erişimini geri yüklemek için yeterlidir. Bu tanımlayıcılar, kullanıcılarla iletişimin en güvenilir yolları olduğundan, MFA (Çok Faktörlü Kimlik Doğrulama) amaçları için sık sık telefon numaraları toplanır ve SMS genellikle kullanılan bir ikinci faktör olarak tercih edilir.

Kullanıcı adları, sosyal medya, forumlar veya bazı profesyonel platformlar gibi dışa dönük (public-facing) tanımlayıcıların gerekli olduğu sistemlerde kullanıcının kimliğine ek bir katman sağlamak için sıklıkla kullanılır. Kimlik doğrulamada e-posta veya telefon numaraları ile aynı işlevsel rolü oynamasalar da, kullanıcı adları, kullanıcılara genel veya eşler arası bağlamlarda tanınabilir bir kimlik sunar. Bununla birlikte, kullanıcıların onları genellikle unutabilmesi nedeniyle ek bir karmaşıklık getirirler ve çoğu durumda, kullanıcı adının yanında başka bir tanımlayıcı gerekir. Bu nedenle, bu makalede kullanıcı adlarına odaklanmayacağız.

Kimlik doğrulayıcı uygulamalar (authenticator apps - TOTP kodları oluşturan) gibi diğer 2FA seçenekleri bir tanımlayıcıya dayanmaz, ancak ortalama bir kullanıcı için kurulması genellikle daha karmaşıktır. Geçiş anahtarları, kripto alanında giderek daha popüler hale gelen bir özellik olan, tanımlayıcı olmadan (usernameless - kullanıcı adsız) kimlik doğrulama olasılığını da ortaya koymuştur. Ancak hem tüketici hem de ticari çözümler için, geri dönüş veya kurtarma amaçlarıyla (genellikle e-posta yoluyla) kullanıcılarla iletişim kurma ihtiyacı, kullanıcı adsız sistemleri daha az pratik hale getirir.

2.2 Güvenlik Seviyesi: Tek Faktörlü Kimlik Doğrulama (SFA) ve Çok Faktörlü Kimlik Doğrulama (MFA)#

Tek Faktörlü Kimlik Doğrulama (SFA) sistemleri, kullanıcının kimliğini doğrulamak için tek bir kimlik doğrulama biçimine dayanan sistemlerdir. Genellikle bu tek faktör bir paroladır, ancak aynı zamanda sosyal giriş (social login), e-posta OTP'si veya sadece bir tür kanıt gerektiren herhangi bir yöntem olabilir. Bugün web'deki çoğu sistem SFA sistemleridir. Ancak güvenlik açısından iyi bilinen bir denge (trade-off) söz konusudur. Geçiş anahtarları entegre edildiğinde, bunlar genellikle sistemin kullanım kolaylığını artırarak geleneksel parolalara bir eklenti veya alternatif olarak hizmet eder. Bu tür sistemlerde e-posta OTP'leri veya sosyal girişler gibi geri dönüş seçeneklerine hala izin verilmesi yaygındır; bu da parolaları azaltarak kullanıcı deneyimini iyileştirir, ancak sistemin güvenliğini SFA'nın ötesine yükseltmez.

Çok Faktörlü Kimlik Doğrulama (MFA), kullanıcının kimliğini doğrulamak için iki veya daha fazla bağımsız faktörü içerir; SFA'dan daha güvenli olmasını sağlayan da budur. Bu faktörler, kullanıcının bildiği bir şey (parola veya PIN), sahip olduğu bir şey (bir güvenlik belirteci - token - veya bir cep telefonu uygulaması) ve olduğu bir şey (parmak izleri veya yüz tanıma gibi biyometrik doğrulama) olabilir. MFA sistemleri, SFA sistemlerinin savunamayacağı kimlik avı (phishing) saldırıları veya parola ihlalleri gibi belirli güvenlik açıklarına karşı koruma sağlamak için tasarlanmıştır. Geçiş anahtarları bir MFA sisteminde kullanıldığında, genellikle bağımsız (self-contained) bir MFA seçeneği olarak kullanılırlar. Bu durumlarda, herhangi bir geri dönüş veya kurtarma yönteminin geçiş anahtarlarıyla aynı güvenlik seviyesini sürdürmesi çok önemlidir.

2.3 Geri Dönüş ve Kurtarma#

Geri Dönüşler (Fallbacks), birden fazla kimlik doğrulama yönteminin bir arada bulunduğu tüm sistemlerde kullanılır. Birincil yöntemler kullanılamadığında kullanılırlar – genellikle kullanıcı başlangıçta nasıl kaydolacağına (örneğin sosyal giriş vs. parola) dair bir seçeneğe sahiptir. Bir geri dönüş, e-posta yoluyla OTP'ler, parolalar, eşleşen e-postalara sahip sosyal girişler, yerel uygulama bildirimleri (native app pushes), QR kodları veya güvenlik anahtarları gibi alternatif kimlik doğrulama stratejilerini içerebilir. Bu geri dönüş yöntemlerinin her biri güvenlik kalitesi açısından farklılık gösterir ve kullanıcı rahatlığı ile güvenlik gereksinimleri arasındaki dengeyi sağlamada uygun geri dönüş seçeneğinin seçilmesi kritik öneme sahiptir.

Çok Faktörlü Kimlik Doğrulama (MFA) sisteminin bir parçası olarak geçiş anahtarlarını kullanan ortamlarda, geçiş anahtarlarıyla kıyaslanabilir çok faktörlü güvenlik sağladıklarından emin olmak için bu geri dönüş yöntemleri dikkatlice düşünülmelidir. Kurtarma (Recovery) süreçleri, kullanıcılar gerekli güvenlik standartlarını (SFA veya MFA) karşılayan yerleşik tüm kimlik doğrulama önlemlerine erişimi kaybettiğinde önemli hale gelir. E-posta OTP'si aracılığıyla parolanın sıfırlanması gibi birden fazla kurtarma seçeneğinin bulunabildiği tek faktörlü sistemlerde bu durum daha az kritiktir, çünkü kullanıcının ilişkili bir tanımlayıcı üzerindeki kontrolünü etkili bir şekilde doğrular. Ancak kurtarma, 2FA/MFA sistemlerinde özellikle zordur, çünkü bu sistemler doğası gereği doğrulama için birden fazla faktöre dayanır. Bir kullanıcının mobil işletim sistemini değiştirdiği (örneğin iPhone'dan Android telefona) ve ilişkili geçiş anahtarlarıyla birlikte telefon numarasını kaybettiği senaryolarda, kalan faktörler (örneğin sadece bir parola) 2FA gereksinimlerini karşılayamaz. Bu durumlardaki kurtarma, manuel destek talepleri veya daha sonra ele alacağımız daha yenilikçi çözümler içerebilen yeni kimlik kanıtları oluşturmayı gerektirebilir.

3. Geçiş Anahtarı Girişi Geri Dönüşü: Manuel Geçiş Anahtarı Girişi ve Otomatik Geçiş Anahtarı Girişi#

Bir geçiş anahtarı çözümü uygularken, verilmesi gereken ilk kararlardan biri geçiş anahtarı girişi için yaklaşımdır. Kullanım durumuna bağlı olarak, küçük platformlar için manuel giriş yeterli olabilir, ancak UX odaklı büyük şirketler için, birincil tanımlayıcı (büyük olasılıkla e-posta) girildikten sonra geçiş anahtarı girişi sunan Önce Tanımlayıcı Yaklaşımı önerilir.

3.1 Manuel Geçiş Anahtarı Girişi: Kullanıcı Tarafından Başlatılan Yaklaşım#

3.1.1 Kullanıcı Tarafından Başlatılan Yaklaşım Nedir?#

Daha küçük platformlarda veya yüksek geçiş anahtarı giriş oranına odaklanmayan platformlarda, kullanıcı tarafından başlatılan yaklaşım ayrı bir "Geçiş anahtarı ile giriş yap" düğmesini içerir. Bu yaklaşımda, geçiş anahtarlarını kullanma sorumluluğu tamamen kullanıcıya yüklenmiştir. Hesabına bir geçiş anahtarı ekledikten sonra, kullanıcının onu kullanarak giriş yapmak için "Geçiş anahtarı ile giriş yap"a tıklamayı hatırlaması gerekir.

Ekran görüntüsü, manuel geçiş anahtarı giriş yaklaşımını kullanan https://my.gov.au adresinin geçiş anahtarı uygulamasını göstermektedir. Bu yaklaşımın uygulanması daha kolaydır çünkü arka ucun bir geçiş anahtarı girişinin mümkün olup olmadığını belirlemesi gerekmez, ancak genellikle çok daha düşük geçiş anahtarı giriş oranlarına yol açar. Bunun nedeni büyük ölçüde kullanıcı inisiyatifine dayanmasıdır ve tüketiciler geçiş anahtarlarının hangi platformda veya bulut depolamasında bulunduğunu hatırlamayabilir veya emin olmayabilir. Bu yaklaşım kullanıcıyı düşündürür. Bir sonraki bölümde bu yaklaşımda hangi potansiyel geri dönüş fırsatlarının olduğuna bir göz atalım.

3.1.2 Geri Dönüşler (Fallbacks)#

Başarısız geçiş anahtarı erişimi olasılıklarının bulunduğu her sistemde geri dönüşler gereklidir. Manuel geçiş anahtarı giriş yaklaşımında, tüm giriş seçenekleri aynı anda görüntülendiğinden ve geçiş anahtarları kullanıcının takdirine bağlı olarak seçildiğinden, iletişim kutuları ve geri dönüşler ayrı ayrı yönetilemez. Bu, birkaç zorluğa yol açar:

• Sezgisel Olmayan Hatalar: Geçiş anahtarları bulunmadığında veya yanlış ayarlandığında kullanıcıların karşılaştığı hata mesajları genellikle belirsizdir ve kafa karışıklığına neden olabilir. Kullanıcılar, geçiş anahtarını neden kullanamadıklarını veya neyin yanlış gittiğini anlamayabilir ve bu da hayal kırıklığına yol açar.
• Çıkmaz Yollar: Kullanıcılar, devam edemedikleri çıkmaz yollarda kalabilirler. Geçiş anahtarları eksikse veya erişilemiyorsa, kullanıcılara nasıl devam edecekleri veya erişimi nasıl geri yükleyecekleri konusunda net bir rehberlik sağlanmayabilir ve bu da giriş sürecini terk etmelerine neden olur.
• Yönlendirmeme: Bu durumlarda sistem, kullanıcıları alternatif bir kimlik doğrulama yöntemine yönlendirmek için faydalı talimatlar sağlayamaz. Kullanıcılar sorunu nasıl çözeceklerini kendi başlarına bulmak zorunda kalır, bu da kullanıcı deneyimini düşürür.

Yukarıdaki örnek, platform kimlik doğrulayıcısında geçiş anahtarları bulunmadığında Windows 11 hata mesajlarının ne kadar kafa karıştırıcı olduğunu göstermektedir. Sistem, geçiş anahtarının bir güvenlik anahtarında (security key) veya başka bir cihazda bulunduğunu varsayabilir. Bu süreç, özellikle daha önce hiç güvenlik anahtarı kullanmamışlarsa veya hiç geçiş anahtarı oluşturmamışlarsa, bu tür kimlik doğrulama akışlarına aşina olmayan kullanıcılar için kafa karıştırıcı olabilir.

Platform kimlik doğrulayıcısında herhangi bir geçiş anahtarı bulunamazsa, işletim sistemi ve tarayıcı, bunların başka bir yerde bulunması gerektiğini varsayar ve kullanıcı henüz bir geçiş anahtarı oluşturmamışsa daha fazla kafa karışıklığına yol açar. Conditional UI (Koşullu Kullanıcı Arayüzü), mevcut geçiş anahtarlarını görüntüleyerek yardımcı olabilir, ancak bu yalnızca geçiş anahtarları gerçekten mevcutsa işe yarar. En iyi geçiş anahtarı deneyimi için arka uç, kullanıcı birincil tanımlayıcısını sağladıktan sonra bir geçiş anahtarı girişinin tetiklenip tetiklenmeyeceğine karar vermelidir.

3.2 Otomatik Geçiş Anahtarı Girişi: Önce Tanımlayıcı Yaklaşımı#

3.2.1 Önce Tanımlayıcı Yaklaşımı Nedir?#

Önce tanımlayıcı yaklaşımında (identifier-first approach), sistem bir geçiş anahtarı ile girişin mümkün olup olmadığını belirlemeden önce, kullanıcılardan e-posta veya telefon numarası gibi birincil tanımlayıcılarını girmeleri istenir. Tanımlayıcı doğrulandıktan sonra sistem, geçiş anahtarları da dahil olmak üzere, eğer mevcut ve erişilebilirlerse, otomatik olarak en uygun giriş yöntemini önerir. Bu yaklaşım daha kullanıcı dostudur çünkü kullanıcıların "Geçiş anahtarı ile giriş yap" seçeneğini seçmeyi hatırlama zorunluluğunu ortadan kaldırır ve süreci kolaylaştırarak benimsenme oranını artırır.

Google Önce Tanımlayıcı ile Giriş Yapma

Google Geçiş Anahtarı ile Giriş Yapma

Yukarıdaki ekran görüntüleri, bir macOS cihazında geçiş anahtarının ilişkili olduğu bir hesap için Google girişinin davranışını göstermektedir. Google ayrıca Önce Tanımlayıcı yaklaşımını izler ve geçiş anahtarı ile girişin büyük ihtimalle mümkün olacağını belirledi:

1. Geçiş anahtarı platform desteği: Temel platform bir platform kimlik doğrulayıcısını destekler, bu nedenle giriş yapılabilir.
2. Geçiş anahtarına erişilebilir: Geçiş anahtarı bu istemcide (macOS) büyük olasılıkla erişilebilir olacaktır, çünkü bir macOS sisteminde oluşturulmuştur.

Sonuç olarak, otomatik olarak bir geçiş anahtarı girişi başlatılır ve kullanıcıyı mümkün olan en iyi deneyime yönlendirir. Bu, "beni düşündürme" (don't make me think) stratejisini izler.

3.2.2 Geçiş Anahtarı Platform Desteği veya Geçiş Anahtarı Erişilebilirliğinin Eksik Olması#

Sistem, geçiş anahtarı ile girişin mümkün olup olmadığını belirler. Şu durumlarda:

• Geçiş anahtarı mevcut değildir: Kullanıcı hesabı için henüz bir geçiş anahtarı oluşturmamıştır.
• Geçiş anahtarlarına erişilemez: Kullanıcının oluşturduğu geçiş anahtarlarının bu İstemcide (Client) mevcut olmaması çok muhtemeldir (örneğin kullanıcı sadece bir MacOS Geçiş Anahtarına sahiptir ve şimdi Windows'tan giriş yapıyordur).
• Geçiş anahtarı kimlik doğrulaması desteklenmemektedir: Mevcut istemci platform kimlik doğrulayıcılarını desteklememektedir ve QR Kodu aracılığıyla Cihazlar Arası Kimlik Doğrulamayı (Cross-Device-Authentication) destekleme olasılığı da çok düşüktür.

Karar, başarılı bir geçiş anahtarı girişinin olası olmadığı yönünde olacak ve bu nedenle, geçiş anahtarı girişini tetiklemeden geri dönüş seçenekleri otomatik olarak sağlanacaktır. Bu yaklaşım çok daha kullanıcı dostudur, çünkü kullanıcıların "Geçiş anahtarı ile giriş yap" seçeneğini seçmeyi hatırlama ihtiyacını ortadan kaldırır, süreci hızlandırarak benimseme oranını artırır ve kafa karıştırıcı bir çıkmaz yolun kullanıcıya gösterildiği en kötü senaryodan kaçınır.

Yukarıdaki örnekte, oturum açma işlemi bir parolaya geri döner (fallback) ve ardından hesabın durumu ile güvenliğine bağlı olarak daha fazla kimlik doğrulama faktörü istemeye devam eder, çünkü istemci (client), macOS geçiş anahtarlarına erişiminin olması muhtemel olmayan bir Windows 11 cihazıdır. Kimlik doğrulama sisteminizin güvenlik gereksinimlerine bağlı olarak, böyle bir durumda hangi kimlik doğrulama yönteminin tetikleneceği üzerinde tam kontrole sahipsiniz (örneğin, geçiş anahtarı dışındaki son başarılı kimlik doğrulama seçeneği).

3.2.3 Geçiş Anahtarı Törenini (Ceremony) İptal Etme#

Bir kullanıcı bir web girişi sırasında bir kimlik doğrulama ekranıyla karşılaştığında, özellikle de geçiş anahtarı tabanlı kimlik doğrulamasını ilk kullandığı zamanlardan biriyse şaşırabilir veya bunalmış hissedebilir. Bu, bir hatadan dolayı değil, yalnızca ne olduğundan emin olmadıkları için kullanıcıların kimlik doğrulama sürecini iptal etmelerine yol açabilir. Bu davranışı planlamak ve ilk iptali bir hata yerine normal bir olay olarak ele almak çok önemlidir:

İlk iptal ekranı, olup biteni sakin ve güven verici bir şekilde açıkça açıklamalı ve kullanıcının süreci yeniden denemesini tavsiye etmelidir (yukarıdaki Google örneğine bakın). Bu ekran kaygıyı en aza indirecek şekilde tasarlanmalı ve iptal işlemini kullanıcı deneyiminin normal, beklenen bir parçası olarak ele almalıdır. Çoğu kullanıcı, yalnızca kimlik doğrulama ekranını tanımadığı veya sürece aşina olmadığı için iptal edebilir. Bu nedenle, varsayılan öneri yeniden denemek olmalıdır.

Ancak ikinci bir iptal meydana gelirse, durum farklı şekilde ele alınmalıdır. İkinci iptal, platform kimlik doğrulayıcı ile ilgili bir sorun, kullanıcının uygun bir geçiş anahtarı bulamaması veya WebAuthn töreninde teknik bir hata olsun, gerçekten bir şeylerin ters gittiğini gösterebilir. Bu noktada sistem, bir sorunun meydana geldiğini açıklayan farklı bir ekran sunmalı ve biraz daha fazla geri dönüş seçeneği önermelidir:

İkinci iptal ekranı, kullanıcıyı alternatif bir kimlik doğrulama yöntemine geçmeye teşvik etmelidir. Kullanıcının daha fazla hayal kırıklığına uğramadan yine de başarılı bir şekilde giriş yapabilmesini sağlamalıdır. Yukarıdaki ekranda görebildiğimiz gibi, Google hala "Tekrar dene"yi öneriyor, ancak aynı zamanda kullanıcıya büyük olasılıkla bir şeylerin ters gittiğini gösteriyor.

3.3 Geçiş Anahtarı Uygulama Yaklaşımlarının Karşılaştırması#

Aşağıdaki tablo, en önemli özellikleri özetleyerek farklı yaklaşımları karşılaştırmaya yardımcı olur:

Kendin yap (Do-it-yourself) yaklaşımları genellikle Manuel Geçiş Anahtarı Girişi yaklaşımını izler ve Conditional UI'a ve kullanıcının geçiş anahtarlarını seçmesine (opt-in) dayanır, bu da çok düşük geçiş anahtarı giriş oranları ve hüsrana uğramış kullanıcılarla sonuçlanır. Önce Tanımlayıcı (Identifier-First) yaklaşımı, Conditional UI'ın üstüne iyi düşünülmüş bir cihaz mantığı (device logic) kurmayı gerektirir ve bu noktada Corbado size yardımcı olabilir. Kendi cihaz mantığınızı ve geçiş anahtarı zekanızı (passkey intelligence) oluşturmanız tavsiye edilmez, çünkü bu kural seti yeni cihazlara, yeni WebAuthn'a ve bulut senkronizasyon işlevselliğine (ör. GPM geçiş anahtarları) sürekli ince ayar yapılmasını ve uyarlanmasını gerektirir.

4. Geçiş Anahtarı Kurtarma#

Geçiş anahtarı kurtarma, kullanıcılar geçiş anahtarlarına erişimi kaybettiğinde güvenliği ve kullanıcı deneyimini korumanın çok önemli bir yönüdür. Bu, özellikle MFA'ya dayanan sistemlerde önemlidir. MFA durumlarında, kurtarma süreçleri, kullanıcıların hesaplarına yeniden erişmesine izin verirken güvenliğin korunmasını sağlamalıdır. Kurtarma yaklaşımı, sistemde kullanılan kimlik doğrulama seviyesine göre uyarlanmalıdır.

4.1 Tek Faktörlü Kurtarma ve Çok Faktörlü Kurtarma#

SFA sistemlerinde güvenliği korumak için kurtarma, genellikle e-posta adresi veya cep telefonu numarası gibi bir tanımlayıcı üzerindeki kontrolün kanıtlanmasını içerir.

• E-posta OTP: Kullanıcının kayıtlı e-posta adresine bir OTP gönderilir. Doğrulandıktan sonra bu, kullanıcının erişimi yeniden kazanmasına ve yeni bir geçiş anahtarı oluşturmasına olanak tanır.
• SMS OTP: E-posta kurtarmaya benzer şekilde, kayıtlı cep telefonu numarasına bir OTP gönderilir. Kullanıcı bu OTP'yi hesabına yeniden erişim sağlamak için kullanabilir.

Bu yöntemler basit olsa da, kullanıcının iletişim bilgilerinin güncel tutulmasına dayanırlar. Bu nedenle, rutin girişler sırasında kullanıcılardan e-posta ve telefon numaralarını doğrulamalarını düzenli olarak istemek çok önemlidir.

Çok Faktörlü Kimlik Doğrulama sistemlerinde kurtarma daha karmaşık hale gelir. MFA birden çok bağımsız faktöre (ör. geçiş anahtarları, sosyal giriş ve OTP'ler) dayandığından, kullanıcılar yalnızca bir faktör (geçiş anahtarı gibi) mevcut olmadığı için erişimi kaybetmemelidir.

• Alternatif faktörler kullanma: Geçiş anahtarı kaybolursa, kullanıcı bir parola + SMS OTP veya bir kimlik doğrulayıcı uygulama gibi iki başka faktörü kullanarak kimlik doğrulaması yapabilir. Kimlik doğrulaması yapıldıktan sonra yeni bir geçiş anahtarı oluşturabilirler.
• Diğer geçiş anahtarlarını kullanma: Kullanıcının geçiş anahtarına sahip diğer cihazları varsa, bunları uygun ipuçlarıyla erişimi yeniden kazanmak için kullanabilirler (ör. bir iPhone'dan bir geçiş anahtarı kullanılmasını talep etmek).
• Yeni geçiş anahtarları oluşturma: Kurtarma yöntemiyle kimlik doğrulamasından sonra, MFA kurulumunun bozulmadan kalmasını sağlamak için kullanıcı yeni bir geçiş anahtarı oluşturmaya yönlendirilmelidir.

Hem SFA hem de MFA sistemleri için temel nokta, kullanıcı için pürüzleri en aza indirirken kurtarma süreçlerinin sağlam ve güvenli olmasını sağlamaktır.

4.2 Akıllı MFA Kurtarma: MFA Kurtarma Maliyetlerini Dijitalleştirin#

Hassas kişisel verileri işleyen sistemlerde, denetime tabi sektörlerde (regulated industries) veya devlet hizmetlerinde standart e-posta OTP'si ve cep telefonu numarası OTP'si kurtarma için her zaman yeterli veya kullanılabilir olmayabilir. Bu gibi durumlarda, akıllı MFA kurtarma mekanizmaları, kullanıcılara sorunsuz bir deneyim sunarken yüksek güvenlik standartlarını koruyan gelişmiş hesap kurtarma yöntemleri sunar.

En etkili yöntemlerden biri canlılık kontrolü ile selfie kimlik tespitidir (selfie identification with a liveness check). Bu işlem, kullanıcının kimliğinin fotoğraflarını çekmesini içerir. Ayrıca, bir selfie canlılık kontrolü, selfie'nin gerçek zamanlı olarak çekilmesini sağlayarak kullanıcının fiziksel olarak orada olduğunu ve fotoğraflanan kimlikle eşleştiğini doğrular; böylece statik resimler veya çalıntı kimlikler kullanan dolandırıcılığı önler. Kullanılan teknolojiye bağlı olarak, kameraya olan mesafenin değiştirildiği veya kafanın 180 derece döndürüldüğü (örneğin Apple Face ID) kısa bir video çekilerek canlılık kontrolü yapılır.

Bu yöntem, e-posta veya SMS OTP'leri gibi geleneksel kurtarma yöntemleri mevcut olmadığında veya güncelliğini yitirdiğinde özellikle yararlı olabilir. Örneğin, burada onfido'dan bir canlılık kontrolü tarafından takip edilen bir selfie çekme örneği yer almaktadır:

Örnek: onfido'dan canlılık kontrollü Selfie Ident

• Devlet sistemleri, denetime tabi sektörler veya büyük ticari hizmetler, kimlik üzerinde bulunan bilgileri doğrulamak için kullanılabilecek kişisel verilere sahiptir. Örneğin, doğum tarihi mevcut değilse, kimlik aracılığıyla toplanan bilgiler manuel kurtarma sürecinde bir faktör olarak kullanılabilir.

Ek olarak, diğer akıllı kurtarma yöntemleri şunları içerebilir:

• Cihazlar arası kurtarma (Cross-device recovery): Kullanıcının güvenilir bir ikincil cihazı varsa, bir QR kodunu tarayarak hesabını kurtarabilir.
• Bilinen ortamlar: Geçmişte başarıyla kullandıkları aynı cihaza hala erişimi olan kullanıcılar, bu cihazı kullanarak ek güvence sağlayan faktörler sunabilir ve böylece manuel kurtarma sürecine yardımcı olmak için aynı cihazdan, sağlayıcıdan ve konumdan hareket ettiklerini kanıtlayabilirler. Google'ın Gmail Hesap Kurtarma için kullandığı bir yaklaşım.
• Dijital Kimlik Bilgileri API'si (Digital Credentials API): Kimlik (ID) cüzdanlarının giderek daha fazla benimsenmesiyle, bu API üzerinden doğrudan doğrulamanın güvenli ve kullanıcı dostu hesap kurtarmada artan bir rol oynaması beklenmektedir.

Akıllı MFA kurtarma yöntemleri, özellikle son derece hassas veya düzenlenmiş (regulated) bilgilerle uğraşırken kullanıcılara hesaplarına yeniden erişim sağlamaları için güvenli, sezgisel yollar sunmayı amaçlamaktadır. Bu yaklaşımlar, e-posta veya telefonla kurtarma gibi geleneksel yöntemlerin bulunmadığı durumlarda bile kullanıcıların erişimlerini güvenli ve verimli bir şekilde geri yükleyebilmelerini sağlar. Akıllı kurtarma, MFA kurtarma maliyetlerini düşürmeye yardımcı olur.

4.3 MFA Kurtarma Sıklıkları: Telefon Numarası ile Geçiş Anahtarı Karşılaştırması#

Geçiş anahtarları bulutta senkronize edildiğinden, MFA kurtarma maliyetlerinin 36 aylık bir süre zarfında çok daha düşük olduğunu akılda tutmak önemlidir, çünkü cep telefonu numarasını değiştirmek, Apple'dan Android'e veya tam tersine geçmekten çok daha sıktır. Telefon veya telefon sözleşmesi değişikliği durumunda geçiş anahtarları geri yüklenecektir.

Bu nedenle, senkronize edilmiş geçiş anahtarlarına erişimi kaybetmek, cep telefonu numarasına erişimi kaybetmekten daha az sıklıkla gerçekleşecektir; bu, geleneksel tüketici odaklı MFA sistemleri için kurtarma sıkıntısının çoğuna neden olan bir durumdur.

Bununla birlikte, artan kullanıcı tabanıyla birlikte, bu tür durumlar hala önemli miktarda manuel destek maliyetlerine neden olmaktadır ve bir sonraki bölümde inceleyeceğimiz dijital bir çözümle ele alınmalıdır.

5. Ürün Yöneticileri ve Geliştiriciler İçin Öneriler#

Geçiş anahtarlarını kimlik doğrulama sisteminize entegre ederken, sorunsuz bir kullanıcı deneyimi sağlarken yüksek düzeyde güvenliği sürdürmek için hem geri dönüş seçeneklerini hem de kurtarma stratejilerini dikkatlice planlamak çok önemlidir. Geçiş anahtarı ile giriş oranını en üst düzeye çıkarmak için aşağıdaki önerileri göz önünde bulundurun:

• Önce Tanımlayıcı Yaklaşımını Tercih Edin: Bu yaklaşım daha kullanıcı dostudur ve giriş sürecindeki pürüzleri azaltır. Kullanıcılardan önce birincil tanımlayıcılarını (ör. e-posta veya telefon numarası) girmelerini isteyerek, sistem otomatik olarak bir geçiş anahtarı ile girişin mümkün olup olmadığını belirleyebilir. Bu, kullanıcının bir geçiş anahtarı seçeneğini manuel olarak seçmesine güvenmeden sorunsuz, sezgisel bir giriş deneyimi sağlar.
• Daha İyi Kullanıcı Deneyimi İçin Açıklayıcı İptal Ekranlarını (Exploratory Abort Screens) Kullanın: Güvenlik en yüksek öncelik olmalı, ancak kullanıcının geçiş anahtarlarını benimsemesine yardımcı olan bir süreç tasarlamak da önemlidir. İlk seferki tören iptallerinin (ceremony aborts) normal olarak ele alındığından emin olun ve yeniden deneme konusunda net bir yönlendirme sağlayın.
• Geri Dönüş ve Kurtarma Seçeneklerini Güvenli Tutun: Geri dönüş yöntemlerinin (e-posta OTP'si ve/veya SMS OTP'si gibi) birincil kimlik doğrulama yönteminin güvenlik seviyesiyle eşleştiğinden emin olun. Örneğin, geçiş anahtarları kullanan bir MFA sisteminde, geri dönüş de aynı güvenlik standardını korumak için birden fazla faktör gerektirmelidir.
• Düzenli Kurtarma İstemlerini (Recovery Prompts) Otomatikleştirin: Geçiş anahtarlarını kullandıklarında kurtarma seçeneklerinin güncel kalmasını sağlamak için giriş sırasında kullanıcılardan iletişim bilgilerini (e-posta adresi veya telefon numarası) doğrulamalarını düzenli olarak isteyin. Bu, kullanıcıların eski kurtarma yöntemleri nedeniyle hesaplarının kilitlenmesi olasılığını azaltır.
• Gelişmiş Güvenlik ve Azaltılmış Destek Kurtarma Maliyetleri İçin Akıllı Kurtarma Yöntemlerini Düşünün: Denetime tabi sektörler veya çevrimiçi kimlik tespiti yapmak için kişisel verilere erişimi olan sistemlerde, canlılık kontrollerine sahip selfie ile kimlik tespiti gibi gelişmiş kurtarma yöntemlerini değerlendirin. Bu yöntem, güvenlik gereksinimlerinize bağlı olarak kurtarma sürecini sezgisel ve kullanıcı dostu tutarken ek güvenlik katmanları sağlayabilir.

Geçiş anahtarı ile giriş oranını en üst düzeye çıkarmak, bu unsurları ne kadar iyi uyguladığınıza bağlıdır. Sorunsuz geri dönüş ve kurtarma seçeneklerinin sağlanması, kullanıcılara geçiş anahtarlarını birincil kimlik doğrulama yöntemi olarak kullanma konusunda güven verecektir.

6. Corbado Sizin İçin Neler Yapabilir: Kullanıcı Arayüzü Bileşenleri (UI Components) ve Geçiş Anahtarı Zekası (Passkey Intelligence)#

Corbado, tamamen yeni bir kimlik doğrulama sistemine ihtiyaç duyan yepyeni (greenfield) projeler ve mevcut bir kimlik doğrulama sistemine geçiş anahtarları eklemesi gereken mevcut projeler için önce tanımlayıcı yaklaşımını uygulamak için gereken her şeyi sağlar.

6.1 Farklı Kullanım Durumları İçin Kullanıcı Arayüzü Bileşenleri#

Her iki ürün de ihtiyaçlarınıza göre uyarlanabilen Kullanıcı Arayüzü bileşenleri sunar:

1. Corbado Complete: Projenize önce geçiş anahtarı (passkey-first) kimlik doğrulaması ile başlayın
   Bu, giriş sürecini kolaylaştırmak için sorunsuz bir önce tanımlayıcı yaklaşımını içeren tam kimlik doğrulama sistemimizdir. Corbado Complete, kullanıcı tanımlayıcısını sağladıktan sonra geçiş anahtarı ile girişin mümkün olup olmadığını otomatik olarak belirleyerek güvenli ve kullanıcı dostu bir deneyim sağlar. Bu, sürtünmeyi (friction) azaltır ve geçiş anahtarı benimsenmesini en üst düzeye çıkarmak için çok önemli olan sorunsuz bir giriş deneyimi sağlar.
2. Corbado Connect: Herhangi bir uygulamaya geçiş yapmadan (migration) geçiş anahtarları ekleyin
   Halihazırda yerleşik kimlik doğrulama süreçleri olan ve geçiş anahtarlarını bir geliştirme (enhancement) olarak eklemek isteyen işletmeler için Corbado Connect, Tek Faktörlü ve Çok Faktörlü Stratejiler için bir eklenti çözümü sunar. Bu yaklaşım, mevcut altyapınızı, kullanıcıların mevcut sisteminizi tamamen elden geçirmeden geçiş anahtarları aracılığıyla kimlik doğrulamasına olanak tanıyan güvenli ve kullanışlı bir seçenek olarak geçiş anahtarlarını sorunsuz bir şekilde entegre ederek tamamlar. Örneğin, Corbado Connect, Amazon Cognito'ya sorunsuz bir şekilde yerleştirilebilir (embedded).

Yöntemlerimizi Google gibi sektör liderleriyle ve özellikle tüketici odaklı şirketler için uyarlanmış, büyük teknoloji (big tech) alanındaki diğer önde gelen oyuncularla kesinlikle uyumlu hale getiriyoruz.

6.2 Geçiş Anahtarı Zekası Önce Tanımlayıcı Yaklaşımını Etkinleştirir#

Amacımız yalnızca geçiş anahtarı benimsenmesini (yani geçiş anahtarlarının oluşturulmasını) en üst düzeye çıkarmak değil, aynı zamanda bu geçiş anahtarlarının yüksek giriş oranlarını teşvik etmek için aktif olarak kullanılmasını sağlamaktır (ve dolayısıyla güvenliği artırıp SMS OTP maliyetlerini düşürmektir). Kullanıcı arayüzü bileşenlerimiz, Önce Tanımlayıcı yaklaşımı göz önünde bulundurularak oluşturulmuştur ve istemci ortamına ve mevcut geçiş anahtarlarına dayalı olarak geçiş anahtarı kullanılabilirliğine ve erişilebilirliğine karar veren Geçiş Anahtarı Zekamıza (Passkey Intelligence) doğrudan bağlıdır. Tartışılan tüm geri dönüş ve kurtarma işlevlerini desteklerler. Aşağıdaki ekranlar iptal etme (abort) ve yeniden deneme mantığımızı göstermektedir:

İlk Geçiş Anahtarı İptali (First Passkey Abort)

İkinci Geçiş Anahtarı İptali (Second Passkey Abort)

Hem geçiş anahtarı benimsenmesine hem de geçiş anahtarı kullanımına odaklanarak, kullanıcıların geçiş anahtarlarıyla sürtünmesiz bir şekilde etkileşim kurmaya devam etmesini sağlayarak güvenlik ve kullanıcı deneyimi arasında bir denge kurmanıza yardımcı oluyoruz.

7. Sonuç#

Bu kılavuzda, geçiş anahtarlarının bir kimlik doğrulama sistemine entegrasyonunun ardından çeşitli geri dönüş ve kurtarma stratejilerini inceledik. Giriş bölümünde sorulan temel sorulara makale boyunca yanıt verildi:

• Hangi geri dönüş senaryoları mevcuttur? Eksik geçiş anahtarı desteği veya geçiş anahtarlarına belirli bir cihazda erişilememesi gibi birkaç geri dönüş senaryosu meydana gelebilir. Güvenliği sürdürmek ve sorunsuz bir UX sağlamak için, geçiş anahtarı ile giriş mümkün olmadığında e-posta veya SMS OTP gibi geri dönüş seçenekleri mevcut olmalıdır.
• Kurtarma nasıl yönetilmelidir? Kurtarma süreçleri, kimlik doğrulama sisteminin güvenlik düzeyine uyacak şekilde tasarlanmalıdır. SFA sistemlerinde, e-posta veya SMS OTP yeterli olabilirken, MFA sistemlerinde erişimi yeniden kazanmak ve yeni bir geçiş anahtarı oluşturmak için alternatif faktörler kullanılmalıdır. Yüksek düzeyde düzenlenen veya hassas ortamlarda, canlılık kontrollerine sahip selfie ile kimlik tespiti gibi akıllı kurtarma yöntemleri ek güvenlik sağlar.

Bu kılavuzda özetlenen en iyi uygulamaları takip ederek, ürün yöneticileri ve geliştiriciler, kullanıcılara güvenli ancak sorunsuz bir giriş deneyimi sağlayan sağlam, geçiş anahtarı tabanlı kimlik doğrulama sistemleri tasarlayabilirler. Güvenlik, kullanıcı deneyimi pahasına olmak zorunda değildir - dikkatli tasarım ve planlama ile her ikisine de ulaşılabilir.

Corbado Hakkında

Corbado, büyük ölçekte tüketici kimlik doğrulaması yöneten CIAM ekipleri için Passkey Intelligence Platform'tur. IDP loglarının ve genel analytics araçlarının göremediğini görmenizi sağlarız: hangi cihazların, OS sürümlerinin, tarayıcıların ve credential manager'ların passkey desteklediğini; kayıtların neden girişe dönüşmediğini; WebAuthn akışının nerede başarısız olduğunu; bir OS ya da tarayıcı güncellemesinin girişi sessizce ne zaman bozduğunu — hem de Okta, Auth0, Ping, Cognito veya kendi IDP'nizi değiştirmeden. İki ürün: Corbado Observe, passkey'ler ve diğer tüm giriş yöntemleri için observability sağlar. Corbado Connect, analytics entegre managed passkey'ler sunar (IDP'nizin yanında). VicRoads, Corbado ile 5M+ kullanıcı için passkey çalıştırıyor (%80+ passkey aktivasyonu). Bir Passkey uzmanıyla görüşün →

Sıkça Sorulan Sorular#

Önce Tanımlayıcı Yaklaşımı, bir geçiş anahtarına mevcut cihazda erişilemediğinde geçiş anahtarı girişini nasıl yönetir?#

Bir geçiş anahtarına erişilememe ihtimali yüksek olduğunda (örneğin, bir Windows cihazından erişilen bir macOS geçiş anahtarı), sistem otomatik olarak geçiş anahtarı istemini atlar ve bunun yerine parola veya OTP gibi geri dönüş seçeneklerini sunar. Bu, 'beni düşündürme' (don't make me think) stratejisini izleyerek yalnızca başarı ihtimali yüksek olduğunda geçiş anahtarı girişini tetikler ve kafa karıştırıcı çıkmaz yollardan kaçınır.

Bir kullanıcı geçiş anahtarı kimlik doğrulama sürecini (ceremony) yarıda bıraktığında ne olmalıdır?#

Birçok kullanıcı kimlik doğrulama ekranına aşina olmadığı için iptal ettiğinden, ilk iptal normal bir olay olarak ele alınmalı ve kullanıcıyı yeniden denemeye teşvik eden sakin bir ekran sunulmalıdır. İkinci bir iptal meydana gelirse, sistem geri dönüş kimlik doğrulama seçeneklerini sunmalıdır, çünkü bu, platform kimlik doğrulayıcısı veya geçiş anahtarı kullanılabilirliği ile ilgili gerçek bir soruna işaret edebilir.

Bir kullanıcı geçiş anahtarına erişimini kaybettiğinde MFA sistemleri için hangi kurtarma seçenekleri mevcuttur?#

MFA sistemlerinde kullanıcılar, parola artı SMS OTP gibi iki alternatif faktörle kimlik doğrulaması yaparak veya güvenilir başka bir cihazdaki bir geçiş anahtarını kullanarak kurtarma yapabilir ve ardından yeni bir geçiş anahtarı oluşturabilir. Geleneksel kurtarma yöntemlerinin bulunmadığı denetime tabi sektörler için, canlılık kontrollerine sahip selfie ile kimlik tespiti gibi akıllı yöntemler ek bir güvenli kurtarma yolu sağlar.

Neden manuel 'Geçiş anahtarı ile giriş yap' düğmesi yaklaşımı, Önce Tanımlayıcı Yaklaşımına kıyasla daha düşük benimsenme oranıyla sonuçlanıyor?#

Manuel yaklaşım, geçiş anahtarı seçeneğini hatırlama ve seçme sorumluluğunu tamamen kullanıcılara yükler ve bu da genellikle çok daha düşük geçiş anahtarı giriş oranlarıyla sonuçlanır. Kullanıcılar ayrıca platform kimlik doğrulayıcısında geçiş anahtarları bulunmadığında net olmayan hata mesajlarıyla karşılaşabilir, bu da hayal kırıklığına ve yarım bırakılmış giriş denemelerine yol açar.