Copenhagen Book: Web Uygulaması Kimlik Doğrulaması Uygulama Kılavuzu
(thecopenhagenbook.com)- Web uygulamalarında kimlik doğrulama uygulamasını tasarlarken başvurulabilecek temel bir kılavuz olup, çevrimiçi kimlik doğrulama kaynaklarındaki boşlukları doldurmayı hedefler
- Ücretsiz ve açık kaynak bir kaynaktır; topluluk tarafından bakımının yapıldığı bir modelle sunulur
- Bazı içerikler görüş içerebilir veya eksik olabilir; bu yüzden tek başına ölçüt olarak kullanmak yerine yardımcı kaynak olarak değerlendirmek daha uygundur
- Kimlik doğrulama güvenliği için başvuru kaynağı olan OWASP Cheat Sheet Series ile birlikte kullanılması önerilir
- Öneriler veya endişeler yeni bir issue açılarak iletilebilir; böylece belgenin iyileştirilmesine katkıda bulunulabilir
Belgenin amacı ve niteliği
- The Copenhagen Book, web uygulamalarında kimlik doğrulama (auth) uygulanırken başvurulabilecek genel yönergeler sunar
- İşleyiş biçimi şöyledir
- Ücretsiz sunulur
- Açık kaynaktır
- Topluluk tarafından bakımı yapılır
- İçerik zaman zaman görüş içerebilir veya tam olmayabilir
Birlikte başvurulacak kaynaklar ve katılım yolu
- Kimlik doğrulama uygularken OWASP Cheat Sheet Series ile birlikte başvurulması önerilir
- Öneriler veya endişeler varsa yeni bir issue açılabilir
1 yorum
Hacker News yorumları
Yanılmıyorsam bu yazı, TypeScript için popüler kimlik doğrulama kütüphanesi Lucia’nın yazarı tarafından yazılmış gibi görünüyor
Yakın zamanda Lucia kütüphanesinin artık kimlik doğrulama uygulamak için ergonomik bir yol olmadığını düşündüğünü, kütüphaneyi kullanımdan kaldırıp yazılı bir rehber serisiyle değiştireceğini duyurdu
İlk rehber önizlemesini okumak keyifliydi ve The Copenhagen Book ile de iyi örtüşüyordu
https://github.com/lucia-auth/lucia
https://github.com/lucia-auth/lucia/discussions/1707
https://lucia-next.pages.dev/
Karmaşıklığın patlama belirtilerini görüp, kütüphanenin kendisi için de artık yararlı olmadığını kabul ettikten sonra, yaygın kütüphane şişmesinin standart yolundan alçakgönüllülükle çıkması nadir görülen bir şey
Aslında insanların %99’unun yalnızca giriş/çıkış yapmaya ihtiyacı var ve bu bir kütüphane olarak sunulduğunda son derece faydalı oluyor
Web 8.0 passkey’lerini WASM eliptik eğri soketleriyle sunmanız gerekiyorsa kendiniz yapabilir ya da Auth0 kullanabilirsiniz; ama CRUD yemek tarifi uygulaması yapan birine OAuth spesifikasyonunu ve tuzaklar listesini verip kimlik doğrulamayı kendisinin yapmasını söylemek tuhaf
O kişi tesisatı yeniden icat etmek yerine asıl fikrine odaklanmalı; ayrıca birçok kişi sonunda bunu yanlış uygulayıp fiilen kimlik doğrulaması olmayan bir duruma düşebilir
Şu kısım yanlış: “E-posta adresleri büyük/küçük harfe duyarlı değildir”
https://thecopenhagenbook.com/email-verification
E-posta standardına göre e-posta adresleri büyük/küçük harfe duyarlıdır
Gönderim sürecinde e-postayı küçük harfe çevirirseniz posta yanlış kişiye gidebilir; kimlik doğrulamada bu risklidir
Birçok büyük e-posta sağlayıcısı büyük/küçük harfi ayırt etmemeyi seçiyor, ancak genel kimlik doğrulama ile ilgilenen bir site genel durumu önermeli
https://stackoverflow.com/questions/9807909/are-email-addres...
Ek olarak, bir karakterin karşıt büyük/küçük harfinin ne olduğu her zaman açık değildir ve zamanla değişebilir. Örneğin Almanca büyük ß harfi Unicode’a 2008’de eklendi; bu yüzden genel programlamada mümkün olduğunca büyük/küçük harf duyarlılığından kaçınmak daha iyidir
Standart bir şey söylüyor ama uygulamalar farklı davranıyor; bu durumda yalnızca standart metnine uymak gerçek dünyada sorun çıkarır
Böylece e-posta ilk girilen büyük/küçük harfli adrese gönderiliyor, giriş ise büyük/küçük harften bağımsız olarak mümkün oluyor
Dezavantajı, yalnızca büyük/küçük harfi farklı olan e-postalara sahip iki kullanıcıyı ayrı tutamamanız; ama bunun kabul edilebilir olduğunu düşünüyorum
E-posta büyük/küçük harfe duyarlı değildi ama e-postadan oluşturulan kullanıcı adı büyük/küçük harfe duyarlıydı; bu yüzden içinde büyük harf olan bir e-postayla hesap oluşturursanız giriş yapmak için aynı büyük/küçük harf biçimiyle yazmanız gerekiyordu ve büyük/küçük harfi yok sayan e-posta ile giriş yapılamıyordu
Sonra dil ve kültür farklarını da kaldırırsak milyarlarca satır kod yok olacak; depoların şimdiden küçüldüğünü duyar gibiyim
Örneğin bir kullanıcı kaydında JohnDoe@example.com, başka bir kayıtta johndoe@example.com yer alıyor ve bunların açıkça aynı kişi olduğu durumlar
Üstelik değerler farklı sistemlerden geldiği için daha da baş ağrıtıcıydı
Büyük/küçük harfe duyarsız e-postaların risk matrisi, büyük/küçük harfe duyarlı e-postalardan çok daha iyi bence. Yani tüm e-postaları küçük harfe çevirmek doğru yaklaşım; The Copenhagen Book da bu noktada haklı
Çok iyi. Güvenlik kaynaklarının %90’ının, güvenlik uzmanı değilseniz asla anlayamayacağınız şekilde hazırlanmış gibi görünmesinden hep rahatsız olmuşumdur. Özellikle kriptografi kaynakları böyle
Ama buradaki neredeyse tüm sayfalar net, kısa, öz ve hemen uygulanabilir olduğu için hoşuma gitti
Yalnız eliptik eğri sayfası diğer kriptografi kaynakları kadar anlaşılması zordu
Çalışma mantığının kendisi matematik olduğu için doğası gereği opak olduğunu düşünüyorum
Sonlu cisimleri, eliptik eğrileri ve aslında tamsayı gruplarını anlayınca kriptografinin büyük kısmını kavrayabildim; çoğu da bir şekilde ayrık logaritma probleminin bir biçimiydi
Benzer konularda alternatif belgeler de olsa iyi olurdu. Örneğin OWASP Cheatsheet gibi ama daha pratik bakış açısına sahip bir belge
Saygı duyuyorum ama bu belgeye biraz şüpheyle yaklaşıyorum
Adı epey iddialı. Belgeye sanki Copenhagen’daki üniversite araştırmacıları yazmış gibi bir ad vermek harika bir pazarlama numarası
Lucia’nın görece popüler bir kütüphane olduğu doğru, ama bu onun en iyi uygulamaları tanıttığı ya da yazarının bu önemli alanda otorite olarak görülmesi gerektiği anlamına gelmez
Lucia tasarımında hoşuma gitmeyen kısımlar da var. Kullanıcı token’ı neredeyse süresi dolmak üzereyken yeni bir güvenli token oluşturmak yerine mevcut token’ın ömrünü uzatmayı öneriyor
Token fiilen sonsuza kadar yaşayıp kötüye kullanılmaya devam edebileceği için bu çok güvensiz bir davranış gibi görünüyor ve sınırlı token ömrü şeklindeki güvenlik en iyi uygulamasını ihlal ediyor
Hem Lucia hem de “Copenhagen Book” bu yöntemi öneriyor: https://thecopenhagenbook.com/sessions#session-lifetime
Bu yaygın bir yöntemdir ve genelde rolling session olarak adlandırılır
Token’ın kendisi zaten baştan değişmez olmalıdır; bu yüzden ömrü değiştirilememelidir. Dolayısıyla token yenileme, asıl token’ı değiştirmek değil yeni bir token vermek şeklinde yapılır
İlk durumda saldırgan token’ı çalıp sonsuza kadar kullanır. İkinci durumda da saldırgan token’ı çaldıktan sonra süresi dolmadan hemen önce yeni bir token alırsa kullanıcıyı taklit etmeye devam edebilir
Kullanıcı sistemden atılırsa bir şeyleri fark edebilir ama bu düşük bir olasılık; iyi bir kullanıcı deneyimi için zaten bir ek süre gerekir. Aksi halde paralel isteklerde normal kullanıcılar da sorun yaşar
İkinci bir token, yani refresh token kullanabilirsiniz ama bu yalnızca riski o token’a taşır. Bu kez refresh token’ın çalınıp sonsuza kadar kötüye kullanılmasından endişe etmeniz gerekir
Refresh token, her istekte veritabanına gitmek zorunda kalmamak açısından kullanışlıdır. Genelde kısa ömürlü oturum token’ları, imzalı JWT gibi veritabanı olmadan doğrulanabilir
Ancak çalındığında geçersiz kılınamaz ve süresi dolana kadar geçerli kalır; bu yüzden zararı azaltmak için son kullanma süresini kısa tutmak gerekir
Buna karşılık refresh token veritabanını sorgular. Güvenliği artıran şey ikinci token’ın kendisi değil, veritabanı sorgusudur. Çünkü veritabanından silinerek geçersiz kılınabilir
Lucia, en azından örneklere göre, her zaman veritabanını sorgular; bu nedenle token’ı istediğiniz zaman geçersiz kılabilirsiniz
Riski azaltmak için kullanıcıların aktif oturumlarını görüp sonlandırabilmesini sağlamalısınız. Mümkünse zaman, konum ve cihaz bilgilerini de birlikte göstermek iyi olur. Örn: “Dün 12:00’de Copenhagen’daki iPhone’dan giriş yapıldı”
Yeni bir konumdan veya cihazdan giriş yapılırsa kullanıcıyı bilgilendirmek de mümkün
Sonuçta uzun süreli oturumları tamamen güvenli biçimde uygulamanın bir yolu yok
İyi bir nokta olduğunu düşünüyorum ama kendime uzman diyemem
OAuth’ta herkesin gözden kaçırdığı iki şey var ve bunlar pek görünür değil
Bunlardan birini birinin dile getirmesine sevindim. Token kullanırken transaction’ı mutlaka distributed lock mekanizması olarak kullanmak gerekir
Refresh token’larda bunun önemi ikiye, dörde katlanır. Aynı token’ı iki kez veya daha fazla kullanırsanız o kullanıcı logout olur
Sistemin tek makinede ya da N makinede çalışması fark etmez. Refresh token içeren birden fazla istek aynı anda ilerliyorsa —ki bu çok sık olur— kullanıcıyı logout eder ve çoğu zaman 500 ile biter
Refresh token tek kullanımlıktır
Geliştiricilerin ve kimlik doğrulama framework’lerinin gözden kaçırdığı diğer şey “state” parametresidir
Günümüzde kimlik doğrulamanın genel olarak ilerlediği yöne bakınca, belirsizlik yoluyla güvenlikten çok belirsizlikten kaynaklanan kararsızlığa yaklaşıyor gibi görünüyor
Uygulama durumu da işin içine girince, uygulama mantığını kimlik doğrulamaya göre ayarlamak gerekiyor ve birinin refresh token’ı çalıp çalmadığını uygulamanın kontrol etmesi gerekiyor
Sadece transaction ile çözülmez. Örneğin iki sekmeyi hızlıca açarsanız, orijinal refresh token ile sunucuya iki kez vurursunuz
O belgede refresh token rotation tercih edilir ama cluster ortamındaki bariz zorluklar da ele alınır: https://datatracker.ietf.org/doc/html/rfc6819#section-5.2.2....
Birden fazla istek her zaman aynı anda gerçekleşir. Örneğin tarayıcının birden çok sekmeyle başlaması ya da akıllı telefon uygulamasının açılırken birden çok isteği topluca göndermesi yaygındır
Daha fazla web sitesinin “oturumu kapatana kadar oturumum sona ermesin, riski anlıyorum” seçeneği sunmasını isterdim.
Bugünlerde “remember me” düğmesinin hiçbir etkisi yok.
Oturum sürelerinin dolması yüzünden günüm sürekli bölünüyor. GitHub’dan özellikle hoşlanmıyorum; haftada yaklaşık bir kez kullandığım için oturumum hep sona ermiş oluyor ve iki aşamalı doğrulamayı da zorunlu kıldığı için her seferinde telefonumu çıkarıp sayıları girmem gerekiyor.
Kullanıcı deneyimi de berbat ama kanıtım olmasa da, insanları sürekli yeniden giriş yapmaya zorlamanın kullanıcıları yorduğunu ve daha az dikkatli hale getirdiğini düşünüyorum.
Bir siteye her hafta birkaç kez giriş yaparsanız, 60. giriş civarında bir phishing sitesinin araya karışması kolaylaşır. Tersine, neredeyse hiç giriş yapmanız gerekmeyen bir hesap aniden parola isterse bu garip gelir ve tetikte olursunuz.
Sonuçta şirketler, herkesin risk alma eğiliminin ve güvenlik duruşunun farklı olduğunu öğrenip seçenek sunmalı.
Ayrıca GitHub’ın sık oturum süresi dolması ve iki aşamalı doğrulaması o kadar sinir bozucuydu ki Gitea’ya geçip süre dolmayı kapattım. Taşınma nedenimin %90’ı buydu.
Yalnızca kendi ağımdan erişilebildiği için güvenliğin aksine daha iyi olduğunu hissediyorum. Esnek olmayan bir güvenlik modeli yüzünden bir şirketin müşteri kaybetmesi gayet mümkün.
Kabaca, 30 gün içinde kullanıldıysa oturumun 30 gün daha devam etmesini sağlayan bir yöntem.
https://thecopenhagenbook.com/sessions#session-lifetime
Daha da kötüsü, oturum bir haftadan 1-2 dakika kadar daha uzun sürüyor gibi görünüyor; bu yüzden bu hafta, geçen haftaki çalışmaya başladıktan hemen sonra dışarı atılıyorum.
Birkaç hafta önce yinelenen bir toplantıdan hemen önce not almak için giriş yaptım; birkaç hafta üst üste o toplantının ortasında giriş yapmaya zorlandım.
Böyle “remember me” düğmelerini etkisiz hale getirebilecek çok sayıda ayar var.
Kişisel olarak GitHub dahil web sitelerinde oturumun açık kalmasıyla ilgili sorun yaşamadım.
Yakın zamanda SRP protokolünü öğrendim; daha yaygın kullanılmamasına ya da daha sık anılmamasına şaşırdım.
Nispeten basit bir protokolle sıfır bilgi kanıtı yapabiliyor ve sunucu ile istemci arasında oturum token’ını da tek seferde oluşturabiliyorsunuz.
https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
Bu kaynağı sevdim. Pek çok güvenlik tavsiyesi anlaşılması güç ve bazen saçma geliyor. Sanki hiçbir şey yapmamanızı öğütleyen bir avukat gibi.
Bu rehberin ferahlatıcı derecede kısa, takip etmesi kolay, anlaşılır ve doğrudan tavsiyeler içermesi hoşuma gitti.
Karşı görüşler ya da dikkat edilmesi gereken noktalar var mı diye yorumları izlemeye devam edeceğim, ama muhtemelen kendi kimlik doğrulama projemle karşılaştırarak gözden geçireceğim.
Tek isteğim bir JWT bölümü olması. Yazarın görüşü “kullanmayın” ise bunu söylemesi bile yeter.
Güvenlik ekipleriyle ilgili sık eleştirdiğim noktalardan biri, insanların yapmak istediklerini verimli biçimde yapabilecekleri araçları veya yöntemleri proaktif olarak sunmaktansa, ne yapmamaları gerektiğini söylemeye çok zaman harcamaları.
E-posta daha güvenli bir sistem olarak görülebilir; bu yüzden anında ya da her yerden erişilebilir olmayabilir.
Buradaki “auth” ile kimlik doğrulamanın (authn) mı, yoksa yetkilendirmenin (authz) mi kastedildiğini merak ediyorum.
Görünüşe göre kimlik doğrulama kastediliyor, ama netleştirilirse iyi olur.
Biraz ilgili kısa bir şikâyet: gömülü tarayıcılar web’i mahvediyor.
Gömülü tarayıcılar sosyal OAuth kullanımını imkânsız hale getiriyor. Bazı durumlarda kelimenin tam anlamıyla imkânsız, bazı durumlarda ise fiilen imkânsız.
Instagram’da bir bağlantıya dokunduğunuzda varsayılan olarak Instagram tarayıcısında açılıyor; o bağlantıda “Sign in with Google” varsa Google, Instagram gibi “güvenli olmayan tarayıcıları” engellediği için çalışmıyor.
“Sign in with Facebook” bile sorun çıkarıyor; üstelik Meta hem Instagram’ın hem Facebook’un sahibi. Facebook gömülü tarayıcısında da benzer sorunlar var.
Slack gibi bir yerde bağlantıya tıkladıktan sonra bir mesaja yanıt verip tekrar tarayıcıya döndüğünüzde sayfanın hâlâ orada olmasını beklersiniz; ama Slack onu kendi tarayıcısının içine yutmuş olur ve hiçbir yerde bulamazsınız; bu neredeyse her zaman işe yaramaz.
Neyse ki az önce kontrol ettim, Slack’te gömülü tarayıcıyı kapatmanın bir yolu var.