Stack Overflow'un sadece çok özel teknik sorular için değil, aynı zamanda yaygın sorunların varyasyonlarının nasıl çözüleceğine dair genel kılavuzlar için de bir kaynak olması gerektiğine inanıyoruz. "Web siteleri için form tabanlı kimlik doğrulama" böyle bir deneme için iyi bir konu olmalıdır.
Kimlik doğrulama için değerleri sunucu tarafındaki bir komut dosyasına POST eden bir giriş+şifre HTML formunun nasıl oluşturulacağını zaten bildiğinizi varsayacağız. Aşağıdaki bölümler, sağlam pratik kimlik doğrulama için kalıplar ve en yaygın güvenlik tuzaklarından nasıl kaçınılacağı ile ilgilenecektir. HTTPS'ye mi HTTPS'ye mi? Bağlantı zaten güvenli değilse (yani, SSL/TLS kullanılarak HTTPS üzerinden tünellenmemişse), oturum açma formu değerleriniz açık metin olarak gönderilecektir, bu da tarayıcı ile web sunucusu arasındaki hatta kulak misafiri olan herhangi birinin oturum açma bilgilerini geçerken okuyabilmesine olanak tanır. Bu tür telefon dinlemeleri hükümetler tarafından rutin olarak yapılmaktadır, ancak genel olarak, bunu söylemek dışında 'sahip olunan' kablolara değinmeyeceğiz: Sadece HTTPS kullanın. Özünde, oturum açma sırasında telefon dinleme/paket koklamaya karşı korunmanın tek pratik yolu HTTPS veya başka bir sertifika tabanlı şifreleme şeması (örneğin, [TLS][1]) veya kanıtlanmış & test edilmiş bir meydan okuma-yanıt şeması (örneğin, [Diffie-Hellman][2]-tabanlı SRP) kullanmaktır. Başka herhangi bir yöntem gizli dinleme yapan bir saldırgan tarafından kolayca atlatılabilir. Elbette, biraz pratik olmak istemiyorsanız, bir tür iki faktörlü kimlik doğrulama şeması da kullanabilirsiniz (örneğin, Google Authenticator uygulaması, fiziksel bir 'soğuk savaş tarzı' kod defteri veya bir RSA anahtar üreteci dongle). Doğru uygulanırsa, bu güvenli olmayan bir bağlantıyla bile çalışabilir, ancak bir geliştiricinin SSL'yi değil de iki faktörlü kimlik doğrulamayı uygulamaya istekli olacağını hayal etmek zor. (Yapmayın) Kendi JavaScript şifrelemeni/hashing'ini oluştur Web sitenize bir SSL sertifikası kurmanın algılanan (ancak artık [önlenebilir][27]) maliyeti ve teknik zorluğu göz önüne alındığında, bazı geliştiriciler, açık metin girişlerini güvenli olmayan bir kablo üzerinden geçirmekten kaçınmak için kendi tarayıcı içi karma veya şifreleme şemalarını kullanmaya cazip geliyor. Bu asil bir düşünce olsa da, yukarıdakilerden biriyle birleştirilmediği sürece, yani hattı güçlü bir şifreleme ile güvence altına almadığı ya da denenmiş ve test edilmiş bir meydan okuma-yanıt mekanizması kullanmadığı sürece (bunun ne olduğunu bilmiyorsanız, dijital güvenlikte kanıtlanması en zor, tasarlanması en zor ve uygulanması en zor kavramlardan biri olduğunu bilin) esasen işe yaramaz (ve bir [güvenlik açığı][3] olabilir). Şifreyi hash etmenin şifre ifşasına karşı etkili olabileceği doğru olsa da, tekrar saldırılarına, Man-In-The-Middle saldırılarına / ele geçirmelerine (bir saldırgan, tarayıcınıza ulaşmadan önce güvenli olmayan HTML sayfanıza birkaç bayt enjekte edebilirse, JavaScript'teki hash işlemini basitçe yorumlayabilir) veya kaba kuvvet saldırılarına (saldırgana hem kullanıcı adı, tuz hem de hash edilmiş şifre verdiğiniz için) karşı savunmasızdır. İnsanlığa karşı CAPTCHAS [CAPTCHA][4] belirli bir saldırı kategorisini engellemek içindir: insan operatör olmadan otomatik sözlük/kaba kuvvet deneme-yanılma. Bunun gerçek bir tehdit olduğuna şüphe yok, ancak bununla sorunsuz bir şekilde başa çıkmanın CAPTCHA gerektirmeyen yolları var, özellikle de düzgün tasarlanmış sunucu tarafı giriş azaltma şemaları - bunları daha sonra tartışacağız. CAPTCHA uygulamalarının aynı şekilde oluşturulmadığını bilin; genellikle insan tarafından çözülemezler, çoğu aslında botlara karşı etkisizdir, hepsi ucuz üçüncü dünya işçiliğine karşı etkisizdir ([OWASP][5]'e göre, mevcut atölye ücreti 500 test başına 12 $'dır) ve bazı uygulamalar bazı ülkelerde teknik olarak yasa dışı olabilir (bkz. [OWASP Authentication Cheat Sheet][6]). CAPTCHA kullanmanız gerekiyorsa, Google'ın [reCAPTCHA][7] uygulamasını kullanın, çünkü tanım gereği OCR-zordur (zaten OCR-yanlış sınıflandırılmış kitap taramalarını kullandığından) ve kullanıcı dostu olmak için çok çaba gösterir. Şahsen ben CAPTCHA'ları can sıkıcı buluyorum ve bunları yalnızca bir kullanıcı birkaç kez oturum açmayı başaramadığında ve kısıtlama gecikmeleri maksimuma ulaştığında son çare olarak kullanıyorum. Bu, kabul edilebilecek kadar nadiren gerçekleşir ve sistemi bir bütün olarak güçlendirir. Parolaların Saklanması / Girişlerin Doğrulanması Bu, son yıllarda gördüğümüz tüm kamuoyuna açık saldırılar ve kullanıcı veri sızıntılarından sonra nihayet yaygın bir bilgi olabilir, ancak söylenmesi gerekiyor: Parolaları veritabanınızda açık metin olarak saklamayın. Kullanıcı veritabanları rutin olarak saldırıya uğrar, sızdırılır veya SQL enjeksiyonu yoluyla elde edilir ve ham, düz metin şifreleri saklıyorsanız, bu oturum açma güvenliğiniz için anında oyun biter. Peki şifreyi saklayamıyorsanız, giriş formundan POST edilen giriş+şifre kombinasyonunun doğru olup olmadığını nasıl kontrol edersiniz? Cevap, bir [anahtar türetme işlevi][24] kullanarak hashing yapmaktır. Yeni bir kullanıcı oluşturulduğunda veya parola değiştirildiğinde, parolayı alır ve Argon2, bcrypt, scrypt veya PBKDF2 gibi bir KDF'den geçirerek açık metin parolasını ("correcthorsebatterystaple") veritabanınızda saklamak için çok daha güvenli olan uzun, rastgele görünümlü bir dizeye dönüştürürsünüz. Bir girişi doğrulamak için, girilen parola üzerinde aynı hash işlevini çalıştırırsınız, bu kez tuzu geçirirsiniz ve elde edilen hash dizesini veritabanınızda depolanan değerle karşılaştırırsınız. Argon2, bcrypt ve scrypt tuzu zaten hash ile birlikte depolar. Daha ayrıntılı bilgi için sec.stackexchange'deki bu [makaleye][23] göz atın. Bir tuzun kullanılmasının nedeni, hash'in kendi başına yeterli olmamasıdır - hash'i [gökkuşağı tablolarına][8] karşı korumak için bir 'tuz' eklemek isteyeceksiniz. Bir tuz, tam olarak eşleşen iki parolanın aynı hash değeri olarak saklanmasını etkili bir şekilde önler ve bir saldırganın parola tahmin saldırısı gerçekleştirmesi durumunda tüm veritabanının tek seferde taranmasını önler. Kullanıcı tarafından seçilen parolalar yeterince güçlü olmadığından (yani genellikle yeterli entropi içermediğinden) ve parola tahmin saldırısı, hash'lere erişimi olan bir saldırgan tarafından nispeten kısa sürede tamamlanabileceğinden, parola depolama için kriptografik bir hash kullanılmamalıdır. Bu nedenle KDF'ler kullanılır - bunlar etkin bir şekilde ["anahtarı esnetir"][25], yani bir saldırganın yaptığı her parola tahmini hash algoritmasının birden fazla tekrarına neden olur, örneğin 10.000 kez, bu da saldırganın parolayı 10.000 kat daha yavaş tahmin etmesine neden olur. Oturum verileri - "Spiderman69"** olarak giriş yaptınız Sunucu kullanıcı adı ve parolayı kullanıcı veritabanınızda doğruladıktan ve bir eşleşme bulduktan sonra, sistemin tarayıcının kimliğinin doğrulandığını hatırlamak için bir yola ihtiyacı vardır. Bu gerçek, oturum verilerinde yalnızca sunucu tarafında saklanmalıdır.
Oturum verilerine aşina değilseniz, işte nasıl çalıştığı: Rastgele oluşturulmuş tek bir dize, süresi dolan bir çerezde saklanır ve sunucuda depolanan bir veri koleksiyonuna (oturum verileri) referans vermek için kullanılır. Eğer bir MVC çatısı kullanıyorsanız, bu işlem şüphesiz zaten yapılmaktadır. Mümkünse, oturum çerezinin tarayıcıya gönderilirken Güvenli ve Yalnızca HTTP bayraklarının ayarlandığından emin olun. HttpOnly bayrağı, çerezin XSS saldırısı yoluyla okunmasına karşı bir miktar koruma sağlar. Güvenli bayrağı, çerezin yalnızca HTTPS üzerinden geri gönderilmesini sağlar ve bu nedenle ağ koklama saldırılarına karşı koruma sağlar. Çerezin değeri tahmin edilebilir olmamalıdır. Mevcut olmayan bir oturuma atıfta bulunan bir çerez sunulduğunda, oturum sabitlemesini önlemek için değeri hemen değiştirilmelidir.
BÖLÜM II: Oturumda Nasıl Kalınır - Meşhur "Beni Hatırla" Onay Kutusu
Kalıcı Oturum Açma Çerezleri ("beni hatırla" işlevi) tehlikeli bir bölgedir; bir yandan, kullanıcılar bunları nasıl kullanacaklarını anladıklarında tamamen geleneksel oturum açma işlemleri kadar güvenlidirler; ve diğer yandan, bunları halka açık bilgisayarlarda kullanabilen ve oturumu kapatmayı unutabilen ve tarayıcı çerezlerinin ne olduğunu veya nasıl silineceğini bilmeyen dikkatsiz kullanıcıların elinde muazzam bir güvenlik riski oluştururlar. Şahsen, düzenli olarak ziyaret ettiğim web siteleri için kalıcı girişleri seviyorum, ancak bunları nasıl güvenli bir şekilde kullanacağımı biliyorum. Kullanıcılarınızın da aynı şeyi bildiğinden eminseniz, kalıcı oturum açma bilgilerini vicdanınız rahat bir şekilde kullanabilirsiniz. Eğer değilseniz, o zaman giriş bilgilerini dikkatsizce kullanan kullanıcıların saldırıya uğradıklarında bunu kendi başlarına getirdikleri felsefesine katılabilirsiniz. Kullanıcılarımızın evlerine gidip, monitörlerinin kenarına dizdikleri şifrelerin yazılı olduğu, yüzlerini buruşturan Post-It notlarını yırtıp atacak halimiz de yok. Elbette, bazı sistemler hiçbir hesabın saldırıya uğramasını göze alamaz; bu tür sistemler için, kalıcı oturum açma bilgilerine sahip olmayı haklı çıkarmanın hiçbir yolu yoktur. Kalıcı oturum açma tanımlama bilgilerini uygulamaya karar verirseniz, bunu şu şekilde yaparsınız:
- Öncelikle, konuyla ilgili Paragon Initiative'in makalesini okumak için biraz zaman ayırın. Bir dizi unsuru doğru yapmanız gerekecek ve makale her birini açıklamak için harika bir iş çıkarıyor.
- Ve en yaygın tuzaklardan birini tekrarlamak gerekirse, VERİTABANINIZDA SÜREKLİ GİRİŞ BELİRTEÇLERİNİ (TOKEN) SAKLAMAYIN, SADECE HASH'LERİNİ SAKLAYIN! Giriş belirteçleri Parola Eşdeğeridir, bu nedenle bir saldırgan veritabanınızı ele geçirirse, belirteçleri herhangi bir hesaba giriş yapmak için kullanabilir, tıpkı açık metin giriş-parola kombinasyonları gibi. Bu nedenle, kalıcı oturum açma belirteçlerini depolarken hash kullanın (https://security.stackexchange.com/a/63438/5002'a göre zayıf bir hash bu amaç için yeterli olacaktır).
BÖLÜM III: Gizli Soruları Kullanma
Gizli soruları uygulamayın'. Gizli sorular' özelliği bir güvenlik anti-paternidir. OKUNMASI GEREKENLER listesindeki 4 numaralı bağlantıdan makaleyi okuyun. Bunu Sarah Palin'e sorabilirsiniz, önceki başkanlık kampanyası sırasında Yahoo! e-posta hesabı hacklenmişti çünkü güvenlik sorusunun cevabı... "Wasilla Lisesi" idi! Kullanıcı tarafından belirlenen sorularda bile, çoğu kullanıcının ikisinden birini seçmesi kuvvetle muhtemeldir:
- Annenin kızlık soyadı veya en sevilen evcil hayvan gibi 'standart' bir gizli soru
- Herkesin blogundan, LinkedIn profilinden veya benzer bir yerden alabileceği basit bir bilgi parçası
- Cevaplaması şifrelerini tahmin etmekten daha kolay olan herhangi bir soru. Bu da iyi bir şifre için aklınıza gelebilecek her sorudur. Sonuç olarak, güvenlik soruları neredeyse tüm biçimleri ve varyasyonlarıyla doğası gereği güvensizdir ve herhangi bir nedenle bir kimlik doğrulama şemasında kullanılmamalıdır. Güvenlik sorularının bu kadar yaygın olmasının gerçek nedeni, yeniden etkinleştirme koduna ulaşmak için e-postalarına erişemeyen kullanıcıların birkaç destek çağrısı maliyetinden tasarruf etmeleridir. Bu da güvenlik ve Sarah Palin'in itibarı pahasına olmaktadır. Buna değer mi? Muhtemelen değmez.
BÖLÜM IV: Unutulan Parola İşlevselliği
Unutulan/kaybolan kullanıcı parolalarını ele almak için neden asla güvenlik soruları kullanmamanız gerektiğinden daha önce bahsetmiştim; ayrıca kullanıcılara gerçek parolalarını asla e-posta ile göndermemeniz gerektiğini de söylemeye gerek yok. Bu alanda kaçınılması gereken en az iki yaygın tuzak daha vardır:
- Unutulan bir parolayı otomatik olarak oluşturulan güçlü bir parolaya sıfırlamayın - bu tür parolaların hatırlanması oldukça zordur, bu da kullanıcının ya parolayı değiştirmesi ya da monitörünün kenarındaki parlak sarı bir Post-It'e yazması gerektiği anlamına gelir. Yeni bir parola belirlemek yerine, kullanıcıların hemen yeni bir parola seçmesine izin verin - zaten yapmak istedikleri de budur. (Bunun bir istisnası, kullanıcıların normalde yazmadan hatırlamanın imkansız olduğu şifreleri saklamak/yönetmek için evrensel olarak bir şifre yöneticisi kullanması olabilir).
- Kayıp parola kodunu/token'ını her zaman veritabanında karma hale getirin. AGAIN, bu kod bir başka Parola Eşdeğeri örneğidir, bu nedenle bir saldırganın veritabanınızı ele geçirmesi durumunda karma hale getirilmelidir. Kayıp bir parola kodu istendiğinde, düz metin kodunu kullanıcının e-posta adresine gönderin, ardından hashleyin, hash'i veritabanınıza kaydedin - ve orijinali atın. Tıpkı bir parola veya kalıcı bir oturum açma belirteci gibi. Son bir not: 'kayıp şifre kodunu' girmek için kullandığınız arayüzün en az giriş formunuzun kendisi kadar güvenli olduğundan emin olun, aksi takdirde bir saldırgan erişim sağlamak için bunu kullanacaktır. Çok uzun 'kayıp parola kodları' (örneğin, büyük/küçük harfe duyarlı 16 alfanümerik karakter) oluşturduğunuzdan emin olmak iyi bir başlangıçtır, ancak giriş formunun kendisi için yaptığınız aynı kısıtlama şemasını eklemeyi düşünün.
BÖLÜM V: Parola Gücünü Kontrol Etme
Öncelikle, bir gerçeklik kontrolü için bu küçük makaleyi okumak isteyeceksiniz: En yaygın 500 parola Tamam, belki bu liste herhangi bir sistemde herhangi bir yerde en sık kullanılan şifrelerin kanonik listesi değildir, ancak uygulanan bir politika olmadığında insanların şifrelerini ne kadar kötü seçeceklerinin iyi bir göstergesidir. Ayrıca, son zamanlarda çalınan şifrelerin kamuya açık analizleriyle karşılaştırdığınızda liste korkutucu bir şekilde eve yakın görünüyor. Yani: Minimum parola gücü gerekliliği olmadığında, kullanıcıların %2'si en yaygın 20 paroladan birini kullanıyor. Bunun anlamı şudur: Bir saldırgan sadece 20 deneme yaparsa, web sitenizdeki her 50 hesaptan 1'i kırılabilir olacaktır. Bunu engellemek için bir parolanın entropisini hesaplamak ve ardından bir eşik uygulamak gerekir. Ulusal Standartlar ve Teknoloji Enstitüsü (NIST) Özel Yayın 800-63 çok iyi bir dizi öneride bulunmaktadır. Bu, bir sözlük ve klavye düzeni analizi ile birleştirildiğinde (örneğin, 'qwertyuiop' kötü bir paroladır), 18 bit entropi düzeyinde kötü seçilmiş tüm parolaların %99'unu reddedebilir. Basitçe parola gücünü hesaplamak ve kullanıcıya görsel bir güç ölçer göstermek iyidir, ancak yetersizdir. Zorlanmadığı sürece, birçok kullanıcı büyük olasılıkla bunu görmezden gelecektir. Yüksek entropili parolaların kullanıcı dostu olması konusunda yeni bir bakış açısı için Randall Munroe'nun Password Strength xkcd adlı kitabı şiddetle tavsiye edilir. Troy Hunt'ın Have I Been Pwned API programını kullanarak kullanıcıların şifrelerini kamuya açık veri ihlallerinde ele geçirilen şifrelerle karşılaştırın.
BÖLÜM VI: Çok Daha Fazlası - Veya: Hızlı Giriş Girişimlerini Önleme
Öncelikle rakamlara bir göz atın: Parola Kurtarma Hızları - Parolanız ne kadar süre dayanır Bu bağlantıdaki tablolara bakacak vaktiniz yoksa, işte bunların listesi:
- Zayıf bir şifreyi kırmak, abaküsle kırıyor olsanız bile neredeyse hiç zaman almaz
- Alfanümerik 9 karakterli bir şifreyi kırmak *harf büyüklüğüne duyarsızsa neredeyse hiç zaman almaz.
- Karmaşık, semboller ve harfler ve sayılar, büyük ve küçük harflerden oluşan bir şifreyi kırmak 8 karakterden daha az uzunsa neredeyse hiç zaman almaz (bir masaüstü bilgisayar 7 karaktere kadar olan tüm anahtar alanını birkaç gün hatta saat içinde arayabilir)
- *Bununla birlikte, saniyede bir deneme ile sınırlı olsaydınız, 6 karakterli bir parolayı kırmak bile aşırı miktarda zaman alırdı! Peki bu rakamlardan ne öğrenebiliriz? Pek çok şey, ancak en önemli kısma odaklanabiliriz: çok sayıda hızlı ve ardışık oturum açma girişimini (yani brute force saldırısını) önlemenin gerçekten o kadar da zor olmadığı gerçeği. Ancak bunu doğru bir şekilde önlemek göründüğü kadar kolay değildir. Genel olarak, kaba kuvvet saldırılarına karşı etkili olan üç seçeneğiniz vardır (ve sözlük saldırıları, ancak zaten güçlü bir parola politikası uyguladığınız için bunlar bir sorun olmamalıdır):
- N başarısız denemeden sonra bir CAPTCHA sunmak (çok sinir bozucu ve genellikle etkisiz -- ama burada kendimi tekrar ediyorum)
- Hesapları kilitleme** ve N başarısız denemeden sonra e-posta doğrulaması gerektirme (bu, gerçekleşmeyi bekleyen bir DoS saldırısıdır)
- Ve son olarak, login throttling: yani, N başarısız denemeden sonra denemeler arasında bir zaman gecikmesi ayarlamak (evet, DoS saldırıları hala mümkündür, ancak en azından çok daha az olasıdır ve gerçekleştirilmesi çok daha karmaşıktır). En iyi uygulama #1: Başarısız deneme sayısı ile artan kısa bir zaman gecikmesi, örneğin:
- 1 başarısız deneme = gecikme yok
- 2 başarısız deneme = 2 saniye gecikme
- 3 başarısız deneme = 4 saniye gecikme
- 4 başarısız deneme = 8 saniye gecikme
- 5 başarısız deneme = 16 saniye gecikme
- vs. Ortaya çıkan kilitleme süresi önceki kilitleme sürelerinin toplamından biraz daha büyük olduğu için bu şemaya DoS saldırısı yapmak çok pratik olmayacaktır. Açıklığa kavuşturmak için: Gecikme, yanıtın tarayıcıya döndürülmesinden önceki bir gecikme değildir. Daha çok, belirli bir hesaba veya belirli bir IP adresinden giriş denemelerinin kabul edilmeyeceği veya hiç değerlendirilmeyeceği bir zaman aşımı veya refrakter dönem gibidir. Yani, doğru kimlik bilgileri başarılı bir oturum açma işleminde geri dönmeyecek ve yanlış kimlik bilgileri gecikme artışını tetiklemeyecektir. En iyi uygulama #2: N başarısız denemeden sonra yürürlüğe giren orta uzunlukta bir zaman gecikmesi, örneğin:
- 1-4 başarısız deneme = gecikme yok
- 5 başarısız deneme = 15-30 dakika gecikme Bu şemaya DoS saldırısı oldukça pratik olmayacaktır, ancak kesinlikle yapılabilir. Ayrıca, bu kadar uzun bir gecikmenin meşru bir kullanıcı için çok can sıkıcı olabileceğini de belirtmek yerinde olacaktır. Unutkan kullanıcılar sizden hoşlanmayacaktır. En iyi uygulama #3: İki yaklaşımı birleştirmek - ya N başarısız denemeden sonra devreye giren sabit, kısa süreli bir gecikme, örneğin:
- 1-4 başarısız deneme = gecikme yok
- 5+ başarısız deneme = 20 saniye gecikme Ya da sabit bir üst sınırla artan bir gecikme, örneğin:
- 1 başarısız deneme = 5 saniye gecikme
- 2 başarısız deneme = 15 saniye gecikme
- 3+ başarısız deneme = 45 saniye gecikme Bu son şema OWASP en iyi uygulama önerilerinden alınmıştır (MUST-READ listesindeki 1 numaralı bağlantı) ve kısıtlayıcı olduğu kabul edilse bile en iyi uygulama olarak kabul edilmelidir. Bununla birlikte, genel bir kural olarak şunu söyleyebilirim: parola politikanız ne kadar güçlü olursa, kullanıcıları gecikmelerle o kadar az rahatsız etmek zorunda kalırsınız. Güçlü (büyük/küçük harfe duyarlı alfanümerik + gerekli sayı ve semboller) 9+ karakterli parolalar istiyorsanız, kısıtlamayı etkinleştirmeden önce kullanıcılara 2-4 gecikmesiz parola denemesi hakkı verebilirsiniz.* Bu son giriş kısıtlama şemasına DoS saldırısı yapmak çok pratik olmayacaktır. Son bir dokunuş olarak, her zaman kalıcı (çerez) girişlerin (ve/veya CAPTCHA ile doğrulanmış bir giriş formunun) geçmesine izin verin, böylece meşru kullanıcılar saldırı devam ederken geciktirilmeyecektir . Bu şekilde, çok pratik olmayan DoS saldırısı son derece pratik olmayan bir saldırı haline gelir. Ayrıca, yönetici hesaplarında daha agresif bir kısıtlama yapmak mantıklıdır, çünkü bunlar en çekici giriş noktalarıdır
BÖLÜM VII: Dağıtılmış Kaba Kuvvet Saldırıları
Bir kenara, daha gelişmiş saldırganlar giriş kısıtlamasını 'faaliyetlerini yayarak' atlatmaya çalışacaklardır:
- IP adresinin işaretlenmesini önlemek için bir botnet üzerindeki girişimleri dağıtmak
- Bir kullanıcı seçip en yaygın 50.000 şifreyi denemek yerine (ki kısıtlamamız nedeniyle bunu yapamazlar), en yaygın şifreyi seçip 50.000 kullanıcıya karşı deneyeceklerdir. Bu şekilde, sadece CAPTCHA'lar ve giriş kısıtlama gibi maksimum girişim önlemlerini aşmakla kalmazlar, aynı zamanda başarı şansları da artar, çünkü en yaygın 1 numaralı parola 49.995 numaradan çok daha olasıdır.
- Radara yakalanmamak için her bir kullanıcı hesabı için oturum açma isteklerini 30 saniye gibi aralıklarla yapmak Burada en iyi uygulama sistem genelinde başarısız oturum açma sayısını kaydetmek ve sitenizin hatalı oturum açma sıklığının çalışan bir ortalamasını, daha sonra tüm kullanıcılara uygulayacağınız bir üst sınır için temel olarak kullanmak olacaktır. Çok mu soyut? Başka şekilde ifade edeyim: Sitenizin son 3 ayda günde ortalama 120 hatalı giriş yaptığını varsayalım. Bunu (çalışan ortalama) kullanarak, sisteminiz genel sınırı bunun 3 katı olarak belirleyebilir -- yani 24 saatlik bir süre içinde 360 başarısız deneme. Ardından, tüm hesaplardaki toplam başarısız deneme sayısı bir gün içinde bu sayıyı aşarsa (veya daha da iyisi, hızlanma oranını izler ve hesaplanan bir eşikte tetiklerse), sistem genelinde giriş kısıtlamasını etkinleştirir - bu, TÜM kullanıcılar için kısa gecikmeler anlamına gelir (yine de, çerez girişleri ve/veya yedek CAPTCHA girişleri hariç). Ayrıca, dağıtılmış kaba kuvvet saldırılarını savuşturmak için daha fazla ayrıntı ve zor tuzaklardan nasıl kaçınılacağına dair gerçekten iyi bir tartışma içeren bir soru gönderdim
BÖLÜM VIII: İki Faktörlü Kimlik Doğrulama ve Kimlik Doğrulama Sağlayıcıları
Kimlik bilgileri, istismarlar, şifrelerin yazılıp kaybedilmesi, anahtarlı dizüstü bilgisayarların çalınması veya kullanıcıların kimlik avı sitelerine giriş yapması gibi nedenlerle tehlikeye girebilir. Girişler, bir telefon görüşmesi, SMS mesajı, uygulama veya dongle'dan alınan tek kullanımlık kodlar gibi bant dışı faktörleri kullanan iki faktörlü kimlik doğrulama ile daha fazla korunabilir. Çeşitli sağlayıcılar iki faktörlü kimlik doğrulama hizmetleri sunmaktadır. Kimlik doğrulama, kimlik bilgilerinin toplanmasını başka bir sağlayıcının üstlendiği tek oturum açma hizmetine tamamen devredilebilir. Bu, sorunu güvenilir bir üçüncü tarafa iter. Google ve Twitter standartlara dayalı SSO hizmetleri sunarken Facebook da benzer bir tescilli çözüm sunmaktadır.
Web Kimlik Doğrulaması Hakkında OKUNMASI GEREKEN LİNKLER
- OWASP Kimlik Doğrulama Rehberi / OWASP Kimlik Doğrulama Hile Sayfası
- Web'de İstemci Kimlik Doğrulamasının Yapılması ve Yapılmaması Gerekenler (çok okunabilir MIT araştırma makalesi)
- Wikipedia: HTTP çerezi
- Yedek kimlik doğrulaması için kişisel bilgi soruları: Facebook çağında güvenlik soruları (çok okunabilir Berkeley araştırma makalesi)
Kimlik bilgilerini %100 güvenli bir şekilde göndermenin tek pratik yolu SSL kullanmaktır. Parolayı hash etmek için JavaScript kullanmak güvenli değildir. İstemci tarafı parola karma için yaygın tuzaklar:
Parolaları asla veritabanında düz metin olarak saklamayın. Kendi sitenizin güvenliğini önemsemiyor olsanız bile. Bazı kullanıcılarınızın çevrimiçi banka hesaplarının şifresini tekrar kullanacağını varsayın. Bu nedenle, karma parolayı saklayın ve orijinalini atın. Ve parolanın erişim günlüklerinde veya uygulama günlüklerinde görünmediğinden emin olun. OWASP yeni uygulamalar için ilk tercihiniz olarak Argon2 kullanılmasını önermektedir. Eğer bu mevcut değilse, bunun yerine PBKDF2 veya scrypt kullanılmalıdır. Ve son olarak yukarıdakilerin hiçbiri mevcut değilse, bcrypt kullanın. Hash'ler kendi başlarına da güvensizdir. Örneğin, aynı parolalar aynı hash'ler anlamına gelir - bu da hash arama tablolarını çok sayıda parolayı aynı anda kırmanın etkili bir yolu haline getirir. Bunun yerine, tuzlanmış hash'i saklayın. Tuz, karma işleminden önce parolaya eklenen bir dizedir - her kullanıcı için farklı (rastgele) bir tuz kullanın. Tuz herkese açık bir değerdir, bu nedenle bunları veritabanındaki hash ile birlikte saklayabilirsiniz. Bu konuda daha fazla bilgi için buraya bakın. Bu, kullanıcıya unuttuğu şifreleri gönderemeyeceğiniz anlamına gelir (çünkü elinizde sadece hash vardır). Kullanıcının kimliğini doğrulamadığınız sürece kullanıcının şifresini sıfırlamayın (kullanıcılar saklanan (ve doğrulanan) e-posta adresine gönderilen e-postaları okuyabildiklerini kanıtlamalıdır).
Güvenlik soruları güvensizdir - kullanmaktan kaçının. Neden? Bir güvenlik sorusunun yaptığı her şeyi bir parola daha iyi yapar. Bu wiki'de @Jens Roland cevabı'daki BÖLÜM III: Gizli Soruların Kullanımı bölümünü okuyun.
Kullanıcı oturum açtıktan sonra, sunucu kullanıcıya bir oturum çerezi gönderir. Sunucu kullanıcı adını veya kimliğini çerezden alabilir, ancak başka hiç kimse böyle bir çerez oluşturamaz (TODO mekanizmaları açıklar). Çerezler ele geçirilebilir: yalnızca istemcinin makinesinin geri kalanı ve diğer iletişimler kadar güvenlidirler. Diskten okunabilir, ağ trafiğinde koklanabilir, siteler arası komut dosyası saldırısı ile ele geçirilebilir, zehirli bir DNS'den çalınabilir ve böylece istemci çerezlerini yanlış sunuculara gönderebilir. Kalıcı çerezler göndermeyin. Çerezler, istemci oturumunun sonunda (tarayıcı kapandığında veya etki alanınızdan ayrıldığında) sona ermelidir. Kullanıcılarınıza otomatik giriş yaptırmak istiyorsanız, kalıcı bir çerez ayarlayabilirsiniz, ancak bu çerez tam oturum çerezinden farklı olmalıdır. Kullanıcının otomatik oturum açtığına ve hassas işlemler için gerçek oturum açması gerektiğine dair ek bir bayrak ayarlayabilirsiniz. Bu, size sorunsuz, kişiselleştirilmiş bir alışveriş deneyimi sunmak isteyen ancak yine de finansal bilgilerinizi korumak isteyen alışveriş siteleri arasında popülerdir. Örneğin, Amazon'u ziyaret etmek için geri döndüğünüzde, size giriş yapmış gibi görünen bir sayfa gösterirler, ancak bir sipariş vermeye gittiğinizde (veya gönderim adresinizi, kredi kartınızı vb. değiştirdiğinizde), şifrenizi onaylamanızı isterler. Öte yandan, bankalar ve kredi kartları gibi finansal web siteleri yalnızca hassas verilere sahiptir ve otomatik girişe veya düşük güvenlik moduna izin vermemelidir.
Öncelikle, bu cevabın tam olarak bu soru için en uygun cevap olmadığına dair güçlü bir uyarı. Kesinlikle en iyi cevap olmamalıdır!
Gelecekte kimlik doğrulama konusunda daha iyi yaklaşımlar için bir yükseltme yolu bulmak amacıyla Mozilla'nın önerdiği BrowserID (ya da belki daha doğrusu Doğrulanmış E-posta Protokolü)'nden bahsedeceğim.
Bu şekilde özetleyeceğim:
@
domain" formu özlüdür ve çok çeşitli protokoller ve URI şemaları tarafından desteklenir. Böyle bir tanımlayıcı, elbette, en evrensel olarak bir e-posta adresi olarak tanınır.Bu kesinlikle "web siteleri için form tabanlı kimlik doğrulama" değildir. Ancak mevcut form tabanlı kimlik doğrulama normundan daha güvenli bir şeye geçiş çabasıdır: tarayıcı destekli kimlik doğrulama.