“E-posta kimlik doğrulamadır” kalıbı

• Bazı kullanıcılar parolalarını hatırlamak veya yönetmek yerine her seferinde “Parolamı unuttum” sürecini bir giriş yöntemi gibi kullanıyor
• Gerçek akış, giriş sayfasında kurtarma bağlantısını e-postayla almak, geçici parolayı girmek ve bir sonraki ziyarette de aynı süreci tekrarlamak şeklinde işliyor
• Bu alışkanlık, bilinçli bir güvenlik stratejisinden çok zamanla yerleşmiş öğrenilmiş bir davranışa daha yakın
• Parola yöneticileri ve iki adımlı/çok faktörlü kimlik doğrulama gibi iyileştirmeler de kullanıcıya güvenliği artırmaktan çok sürtünmeyi artıran şeyler gibi gelebilir
• Sistem tasarımının, kullanıcıların tekrarlayan davranışlarını varsayması ve onları daha iyi kullanım biçimlerine doğal şekilde taşımaya yönlendirmesi gerekir

---

Giriş gibi kullanılan parola kurtarma

• Bazı kullanıcılar çevrimiçi hesaplarına giriş yaparken parola girmek yerine her seferinde kurtarma sürecini tekrarlar
  • Giriş sayfasına gelir
  • “I forgot my password”a tıklar
  • E-postasına gider
  • Kurtarma bağlantısına tıklar
  • Hatırlamayacağı geçici parolayı girer
  • Sonrasında aynı süreci tekrarlar
• Neden böyle yaptıkları sorulduğunda yanıt veremezler ya da nedenini hiç düşünmediklerini söylerler
• Bu davranış, sabah belirlenmiş bir giriş stratejisi değil; zamanla yerleşmiş tekrarlanan bir prosedüre daha yakındır

Güvenlik iyileştirmelerinin kullanıcı için yarattığı sürtünme

• Bu yöntem, kullanıcının bir parola ifadesini hatırlamasını gerektirmeyen düşük çabalı bir çözüm olarak işler
• Parola yöneticileri, kimlik hırsızlığı, iki adımlı kimlik doğrulama ve çok faktörlü kimlik doğrulama, kullanıcı adı/parola yönteminin eskimesi zaten yaygın olarak tartışılan konulardır
• Daha iyi güvenlik prosedürleri çoğu zaman engelleri ve sürtünmeyi artırarak kullanıcıların bunları doğal şekilde benimsemesini zorlaştırabilir
• Tasarımcılar, kullanıcıların öğrenilmiş davranışlarını dikkate alıp zaman içinde daha iyi kullanım biçimlerine geçebilecekleri akışlar oluşturmalıdır

[GN⁺]

Hacker News yorumları

• E-posta hesabı, çevrimiçi kimlik doğrulamada en yaygın ortak payda. Cep telefonu da güçlü bir aday ama kaybedilebilir; telefon numaraları daha yaygın ve daha uzun ömürlü olsa da güvenlik düzeyi büyük e-posta sağlayıcılarının hesaplarından çok daha düşük.
  “İnternet için hayali bir kimlik doğrulama sistemi” tasarlayacaksanız önce hesap kurtarmaya bakmak gerekir. Harika kimlik doğrulayıcınızı kaybettiğinizde cevap “artık erişemezsin” ya da “meslektaşlardan oluşan bir kurul kimliğini kefil olur” ise, o sistemin çalışması için kullanıcılarının insan değil, hayali zeki yaşam formları olması gerekir.

  • Yıllardır blockchain/kripto paraya karşı olmamın en büyük nedeni buydu. “Anahtarını kaybedersen cüzdanını da kaybedersin” yaklaşımı gerçek kullanıcılarla temelden uyumsuz.
    İnsanların hatalardan geri dönebilmesi gerekir.
  • Devlet tarafından verilen dijital kimlik bu sorunun büyük kısmını çözebilir. Kendi sorunları olacaktır ama kişisel kimlik tespitini devlete bırakmak, Google gibi şirketlerin hesap kilitlemelerinden daha değerli ve daha az riskli görünüyor.
  • Ne yazık ki Google gibi büyük e-posta sağlayıcılarında bile “artık erişemezsin” yaygın bir kalıp. Telefonunu kaybeden ya da çaldıran ve ardından hesabına kalıcı olarak erişimi kesilen insanlar bunu iyi gösteriyor.
  • “Büyük sağlayıcıdaki e-posta hesabı” için de “hesap sebepsiz yere askıya alındı, itiraz yolu yok ve neden askıya alındığı da söylenmiyor” gibi bir dipnot var.
  • Meslektaşlardan oluşan bir kurulun bir kişinin kimliğine kefil olması ilginç bir tasarım problemi. Uygun şekilde dağıtılmış kimlik doğrulama sırlarını ilgili tarafların talimatıyla yeniden birleştirebilen ortak bir sistem varsa, bunu epey pürüzsüz hale getirmek mümkün olabilir.
    Sıradan insanlar için de çalışır hale getirilebilir mi? Bunu tasarlayacak kadar yaratıcılık olduğuna inanıyorum.

• Bizim hizmetimiz oldukça hafif nitelikte bir iş olduğu için kullanıcılar hesabı yalnızca kolaylık amacıyla kullanıyor. Oturttuğumuz yöntem şöyle: Kullanıcı e-postasını giriyor, e-postayla bir doğrulama kodu gönderiyoruz, kullanıcı kodu girince fiilen süresiz oturum açık kalmasını sağlayan çok uzun ömürlü bir çerez veriyoruz.
  Mevcut hesap olup olmadığı önemli değil; yeni bir e-postaysa yeni bir hesap oluşturuluyor. Bazen birden fazla e-postası olan kullanıcı yanlışlıkla yeni hesap açıyor ama kayıt ve giriş dönüşüm oranı ciddi şekilde iyileştiği için buna değer. Kodun geçerlilik süresi ve deneme sayısı için risk analizi gerekiyor; mümkünse kilitleme mekanizması kullanmak iyi olur. Hizmetiniz çok kritik değilse bu stratejiyi öneririm. iOS Mail de artık Messages’taki tek kullanımlık kod özelliği gibi bu yaklaşımı desteklediği için bazı kullanıcılar açısından oldukça rahat.

  • Gördüğüm verilere göre bu yöntem e-ticaret gelirini maksimize etmede açık ara en iyisi.
    Alıcıya hesap dayatmayın, sadece gerekli ayrıntıları isteyin. Zaten tarayıcı otomatik dolduruyor. Sonrasında sipariş durumu kontrol bağlantısını e-postayla gönderin, bir sonraki siparişte e-postasını tekrar sorun. Ek sürtünme, “kayıtlı kullanıcı” elde etmenin faydasından daha büyük gelir kaybı yaratıyor.
  • Küçük bir B2C uygulaması işletiyorum; kullanıcılar yalnızca e-posta adresiyle kaydoluyor ve parola alanı hiç yok. Hesap oluşturuluyor ve ilgili cihazda süresiz oturum açık kalıyor.
    Yalnızca başka bir cihazdan giriş yapmaları gerektiğinde yeni parola istenebiliyor. Bu, kayıt sürtünmesini ve zayıf parolaları azaltıyor. Çoğu kişi zaten başka bir cihazdan giriş yapma ihtiyacı duymuyor.
  • Bu giriş yöntemini birkaç kez uyguladım; “kullanıcı hesabı”nın ne olduğuna dair sayısız varsayımı bir kenara bırakmak zorunda kalma deneyiminden doğdu. Gerçekte funnel’ın iki tarafın da istediği gibi çalışması için böyle bir sadeleştirme gerekiyordu.
    Anonimliğin korunması gereken bir alan değilse bunu yapmakta sorun yok; daha sonra passkey entegre edilebilir. Dezavantajı, parola paylaşımı imkânsız hale geldiği için tek hesap altında birden çok kullanıcıyı yönetme konusunu daha erken düşünmeniz gerekmesi. Ama bilinçli ele alındığında funnel veya kullanıcı deneyimi sonunda iyileşiyor. Ayrıca güvenlik, kullanıcıların e-posta sağlayıcılarının ortalama güvenlik düzeyine bağlanıyor ama bu genelde gereken seviyeden daha iyi. Parola, daha sonra ihtiyaç duyulduğunda ikinci faktör olarak kullanılabilir ya da başka bir faktör eklenebilir; B2B ise doğrudan SAML veya OIDCye geçilebilir. B2B veya D2C’de hep iyi çalıştı; istisnai durumlar da kazanım faydası nedeniyle çözmeye değerdi.
  • Bu giriş yöntemini görmüştüm; e-postaya uygulamanın ana sayfasına götüren ve zaten giriş yapılmış halde açılan bir bağlantı gönderilemez mi?
    Kodu kopyalamak, giriş sayfasının açık olduğu sekmeyi bulmak ve yapıştırmak zahmetli.
  • Neredeyse tek formdan ibaret küçük bir CRUD uygulamasında bu yöntemi kullandım; kampanya süresince destek talepleri neredeyse sıfıra yakındı, bu yüzden kesinlikle değdi.

• Bu noktada e-posta adresine tek kullanımlık URL bağlantısı gönderip tek tıklamayla giriş yaptırmak yeterli olmaz mı? 10 dakika içinde süresi dolsun ve tek kullanımlık olarak geçersiz kılınsın.
  Elbette bağlantıya ilk sahip olan kişi hesaba giriş yapabilir ama zaten yalnızca e-postadan erişilebilir. E-posta hesabının ötesindeki tüm güvenlik hissi uçup gidiyor ama gerçeklik zaten bu noktaya gelmiş durumda. Telefon mesajıyla “giriş doğrulaması için tıkla: www.someurl.com?p=134234535” gibi bir kalıp kullanırsanız, aptalca kod girmeyi gerektirmeyen iki adımlı doğrulama olur.

  • Birçok web uygulaması bu yöntemi kullanıyor; kullanıcı için kafa karıştırıcı (“Neden zaten hesabım var? Hiç kaydolmadım ki!”), maliyetli (e-posta göndermek ücretsiz değil) ve yavaş.
    E-posta spama düşebiliyor, greylisting yüzünden saatlerce giriş yapılamayabiliyor ya da gelmesi 1 dakika sürüyor ve o bile fazla uzun hissedilebiliyor. Tavsiye eder miyim emin değilim.
  • Yalnızca bu yöntemi sunan bir site 30 saniye içinde e-postayı gönderemezse gerçekten nefret ediyorum.
    Telefona gönderilen “giriş doğrulaması için tıkla” mesajı hem kodu hem bağlantıyı vermeli. Her zaman giriş yapılan cihaz telefon olmadığından “1234 gir veya tıkla” şeklinde olmalı.
  • Netdata gibi bazı siteler bunu yapıyor.
    Ama parola yöneticisinin kullanıcı adı/parola kombinasyonunu otomatik doldurmasından daha yavaş; çünkü e-postayı bekleyip bağlantıya basmanız gerekiyor.
  • Tam olarak bu giriş akışıyla bir web uygulaması geliştiriyorum ve mobilde sorun yaşadım. Gmail gibi uygulamalar bağlantıyı önizleme olmadan tarayıcıya kopyalamanıza izin vermiyor ve o önizleme bağlantıyı tüketiyor (next.js auth).
    Gmail’in uygulama içi tarayıcısında değil, normal tarayıcıda giriş yapmak istiyorum; oldukça sinir bozucu.
  • Bunu yapacaksanız en iyisi sonuna kadar single sign-ona gitmek. Kullanıcıların %95’i zaten Gmail, Outlook veya Apple’dan birini kullanacaktır.
    “E-postayla bağlantı gönder” yerine “Google ile giriş yap” düğmesi daha iyi; her iki durumda da izleme yapılabilir.

• İnsanların her önemsiz hizmet için bir parola oluşturup bunu hatırlayacağı fikri gerçekçi değil. Bir parola tabanlı kimlik doğrulama sistemi daha kurmak, bir tür rol yapma oyununa yakın.
  Parolalar genelde iki yoldan biriyle kullanılır: tek bir gerçek parolayla korunan bir parola yöneticisi ya da her hizmette tekrarlanan aynı parola. Neredeyse tüm hizmetler e-posta ile kurtarma sunduğu için gerçekte e-posta kimlik doğrulama aracıdır. Kişisel e-posta kolay kolay değiştirilmez, paylaşılmaz ve yeniden kullanılmaz. Muhtemelen kişisel e-postanızı telefon numaranızdan daha uzun süredir kullanıyorsunuzdur. Mevcut e-posta adresimi kullandığım süre içinde telefon numaram en az beş kez değişti ve o numaraları artık başka insanlar kullanıyor

  • Türetilmiş parolalar da var; bunlar bir tür hibrit. Kişinin hatırladığı bir kalıp da olabilir, alan adına göre hesaplayan bir yönetim aracı da olabilir.
    Ayrıca parola sıfırlama özelliği en azından tüm denemeleri adres sahibine bildirir. Parola tabanlı girişler ise yeni bir konumdan her giriş yapıldığında her zaman e-posta göndermez
  • Apple, “sadece 1Password/Keychain parolasını girmek yerine e-postayla uğraştırma” sürecini çok daha iyi hale getirdi. En azından e-posta veya SMS'i algılayıp kodu sizin yerinize girdiğinde böyle

• Cevap basit. Genellikle hizmet sağlayıcının kullanıcılar için bilerek oluşturduğu rahatsızlıkla ilgilidir. Bu durumda açık görünüyor: e-posta sağlayıcı oturumları genelde fiilen hiç bitmez ve tarayıcı önbelleği temizlenmediği sürece oturum açık kalır.
  Kendi hizmetinizin kimlik doğrulama token'ını da Gmail ile aynı ömre sahip yapıp, alternatif olarak her seferinde tek kullanımlık parola ile girişe izin vermek yeterli. Ama 12 saatlik kimlik doğrulama token'ı gibi kutsala saygısız uygulamalardan vazgeçilmeli. Böyle olursa kullanıcı bir daha parola kurtarma ile giriş yapmaz

  • Asıl sebep, bu web sitelerinin basitçe düzgün çalışmaması da olabilir.
    Eskiden Epic ve Spotify hesaplarımda sorun yaşamıştım. Hesabı oluşturup bir hafta kullanınca oturum süresi doluyor ve Spotify beni hesaptan atıyordu. Giriş yapmaya çalışınca parolanın yanlış olduğunu söylüyordu; oysa parola yöneticisinde kayıtlı olduğu için bu imkânsızdı. Sonunda e-postayla sıfırlamaktan başka çare kalmıyordu. İlk birkaç sefer e-postayı alıp sıfırlasam da aynı kalıp tekrarlandı; 3-4 kez sonra e-posta bile gelmemeye başladı ve yeni hesap açmak zorunda kaldım. Şimdi Spotify'a Google hesabımla giriş yapıp kullanıyorum ve henüz sorun yok. Ama normal e-posta ile kullanınca onların kimlik doğrulama sistemi basitçe çalışmıyor
  • Bence gerçeğe daha yakın ipucu bu. Gmail ve Cloudflare dahil birçok “yüksek güvenlikli kuruluş”ta kimlik doğrulama oturumları çok uzundur. Bunun nedeni, bu sistemleri kullanan kişinin PC'sine birinin erişmiş ve kullanıcının çıkış yapmamış olma olasılığının gerçekte çok düşük olmasıdır. Saldırıların çoğu uzaktan zayıf parolaları hedefler.
    Sorun, riski ölçmek ve “Bu sitede gerçekten iki aşamalı doğrulama gerekiyor mu?”, “30 dakikalık oturum süresi makul mü?” diye değerlendirmek için tutarlı bir dilimizin olmaması. Güncel bir antivirüs varsa çoğu kişi oturumunun açık kalmasını ister. Hiç bir site sorununu düzeltmek için tüm çerezleri silmeniz istendi mi? Benim cevabım her zaman hayır. “Hesap sizin; oturumu açık tutup hack'lenme riskini almak istiyorsanız bu hizmet işletmecisinin değil sizin riskiniz” sözünü duymuştum ve giderek daha fazla katılıyorum. Dizüstü bilgisayarınız oturum açıkken birisi tüm EC2 instance'larını sildiyse, bu AWS'nin sizi daha erken çıkış yaptırmamasının değil sizin suçunuzdur. AWS bunu yapabilir, ama neden yapsın? Dikkatsiz 1 kişiyi korumak için 1 milyon kişiyi sinirlendirmenin anlamı yok
  • Doğru söz. Platformların oturum sınırlamaları ve zorunlu iki aşamalı doğrulamayla dadı gibi davranmasından bıktım. Ayarlara bir toggle koymaları yeterli

• Parola sıfırlama adımını kaldıran ya da parolanın kendisini kaldıran siteler gördüm. Kimlik doğrulama e-postadır.
  E-posta adresini giriyorsunuz, içinde kod olan bir e-posta alıyorsunuz, kodu girip oturum açıyorsunuz. Neden böyle yaptıklarını anlıyorum ama birden fazla e-posta kullanan biri olarak pek hoşlanmıyorum. Hangi e-postayı kullanmam gerektiğini hatırlamak için parola yöneticisine e-posta ve not koymak zorunda kaldım; parolası olmayan bir kayıt gibi duruyor

  • Magic link kullanmanın yarattığı sürtünme o kadar fazlaydı ki, böyle web sitelerine para harcamayıp alternatif aradığım oldu.
    Düzgün bir giriş sistemi bile yapamıyorlarsa vaat ettikleri özellikleri sunacak beceriden de yoksun olma olasılıkları yüksek diye düşünüyorum. Magic link artık can sıkıcılığın ötesine geçip bir filtre haline geldi
  • B2B SaaS'ta bu yöntemi kullanıyoruz. Bireysel kullanıcılar belki 6 ayda bir ya da iki kez giriş yaptığı için parolasız giriş avantajlı.
    Sık kullanılmayan bir hizmetin parolasını hatırlama yükü yok ve şirket içi onboarding de kolaylaşıyor. Şirket kullanıcı CSV'si yüklediğinde, kullanıcılar parola oluşturup onaylama ve kurallara uyma süreci olmadan doğrudan çalışmaya başlayabiliyor. E-posta linklerini tercih etmiyoruz; çünkü telefon uygulamalarının önizlemesi veya kurumsal virüs tarayıcıları gibi şeyler linki “tıklayabiliyor”
  • Teknik olmayan tüketicilerin önemli bir kısmı parola yöneticisi kullanmayacak. Yalnızca parolayla kayıt sunup magic link veya kod sunmazsanız, tüketicilerin çoğu için hayatı zorlaştırmış olursunuz.
    İkisini de sunsanız bile, parola isteyip bir de e-posta doğrulaması yaptırırsanız kayıt akışında daha fazla kişinin vazgeçeceğini düşünüyorum. Üstelik parola ve birden çok e-posta giriş akışını yönetmek zorunda kalmadığınız için kod da çok daha basit olur
  • Kupon bozduran bir “misafir girişi” sitesinde bu yöntemi sunmuşlardı; hesap oluşturmak istemeyebilecek kişiler için geçerli bir kullanım durumu olduğunu düşünüyorum.
    Kuponun e-postayla ilişkilendirilmesi gerektiğinden, ileride kupon kaybı nedeniyle destek sorunu çıkmasına karşı linke tıklayarak sahipliği doğrulamak gerekiyordu. Daha sonra hesap oluşturursanız önceden aldığınız kuponları da görebiliyorsunuz
  • Sitenin parolamı saklamadığı anlamına geldiği için endişelenecek şey azalıyor

• Bu yazıyı okuduktan sonra Best Buy’da tam olarak bu yöntemi kullandığımı fark ettim
  Bunu bilerek yapmıyorum. 1Password’de parolam kayıtlı olduğu için doğru olduğunu biliyorum ama bestbuy.com’da bir şey satın almaya çalıştığım her seferinde bir tür hesap ele geçirmeyi önleme mekanizması devreye giriyor ve parolanın yanlış olduğunu söyleyerek yalan söylüyor. Sorun benim tarafımda da olabilir, buna tamamen inanırım. Reklam engelleyici ya da yerel DNS engellemesi gibi bir şey olabilir. Ama birkaç kez tekrar edince hata ayıklama isteğim kalmıyor ve en az dirençli yolu izliyorum

  • Acaba maksimum uzunluk uyuşmazlığı olabilir mi? Parola değiştirme alanı ile giriş sayfasındaki maxlength değerinin farklı olması çok yaygın
    Örneğin parola değiştirirken 60 karakterlik bir parola girdiyseniz ama giriş sayfasındaki maksimum uzunluk 40 karakterse, giriş yaparken “parola yanlış” olur. Bu yüzden artık maksimum uzunluğu uygulama ayarlarında saklayıp tüm parola alanlarına yayılmasını sağlayan bir politika kullanıyorum. Kontrol edince gerçekten de uzunluk uyuşmazlığı olduğunu gördüm. Parola ayarlama formunda maxlength 54, giriş sayfasında ise maxlength yok. Dolayısıyla parola 54 karakteri aşıyorsa ve 1Password kayıtlı parolayı otomatik olarak 54 karakter veya altına kesmiyorsa giriş yapılamaz

• Çoğu insan için bilgisayarda iş yapmak, kabaca çalışana kadar körlemesine tekrar tekrar denemek demek. Yazılım, alttaki sistemleri ayrıntısıyla anlayan insanlar tarafından yapılıyor ama böyle bir anlayışı olmayan insanlar için üretiliyor
  Kullanıcı bir kez çalışan bir kalıp bulduğunda orada kalıyor. Artık birçok okul eğitimde tablet kullandığı için bu eğilim daha da artıyor. Bilgisayarın nasıl çalıştığına dair pek sezgi oluşmuyor. Çoğu kişi derinlemesine düşünmüyor. Zaten orada duruyor ve baştan bozuk şeylere alışıklar; birkaç kez daha tıklamak ne olacak ki

  • Yazılım geliştiriciler arasında yaptığı işi gerçekten derinlemesine anlayanların oranı muhtemelen %10 civarındadır. Hatta geliştiriciler ne yaptıklarını doğru düzgün anlamadıkları için sıradan insanlar berbat yazılımları tekrar tekrar deneyerek ancak kullanabiliyor

• Biraz abartarak söylersek giriş akışları aynı
  A) Web sitesine gidip parola yöneticisi üzerinden rastgele bir dizgeyi kopyalayıp yapıştırmak ve kimlik doğrulaması için e-postayla gelen TOTP isteğini almak. Ya da B) Web sitesine gidip parolamı unuttum’a basmak, giriş bağlantısını aldıktan sonra rastgele bir dizge girmek. Çoğu durumda B aslında daha hızlı ve neredeyse hiç daha yavaş değil. “Beni hatırla” onay kutusunun hiçbir etkisi yok

  • Parola yöneticisinden kim kopyalayıp yapıştırıyor ki?
    Benim akışım ikisinden de daha iyi bence. Siteye gidince Safari otomatik doldurmayı öneriyor, TouchID/FaceID kullanıyorum ve 2 adımlı kod isteniyor. SMS ya da e-postayla gelirse Safari otomatik doldurmayı öneriyor. TOTP yöntemi olsa da Safari otomatik dolduruyor. Çok kolay. Passkey’ler ikinci adım ve SMS/e-posta bekleme olmadığı için daha da kolay
  • TOTP, e-postayla gönderilen türden bir şey değildir. TOTP’nin özü, mevcut zaman ve önceden paylaşılan gizli değerle doğrulama kodunu doğrudan üretebilmenizde yatar
  • Greylisting varsa B akışı yaklaşık 10 dakika sürebilir
  • B yöntemi, e-postaya erişebildiğiniz her yerden mümkündür ve uygulamanın ya da telefonun elinizde olup olmamasına bağlı değildir
  • Tarayıcı parolayı hatırlamıyor mu?

• Motivasyon hemen anlaşılıyor. “Parolamı unuttum”u kullanırsanız parolayı hatırlamanıza gerek kalmaz. Üstelik hesap güvenliği de daha zayıf hale gelmez. Çünkü o yol zaten saldırganlara da açıktı
  Bazı web siteleri bunu varsayılan akış haline getiriyor ve birine e-postayla giriş düğmesi gönderebiliyorlarsa parolanın kendisinin anlamsız olduğunu örtük olarak savunuyor. Kişisel olarak sevmiyorum. E-postaya güvenmiyorum ve düzinelerce hesabın tek hata noktası haline gelmesini de istemiyorum. Yalnızca ikinci faktörle giriş yapılabiliyorsa bu 2 adımlı kimlik doğrulama değildir. Sıfırlama seçeneği olmadan parolayla giriş yapmak istiyorum ama gerçeklik böyle değil

  • E-postayı 2 adımlı kimlik doğrulama ile korursanız bu tekrar 2 adımlı kimlik doğrulama olur