BÖLÜM I: Nasıl Giriş Yapılır?
Kimlik doğrulama için değerleri sunucu tarafında bir komut dosyasına POST yapan bir login + şifre HTML formu oluşturmayı zaten bildiğinizi varsayacağız. Aşağıdaki bölümler, pratik pratik kimlik bilgisi ve en yaygın güvenlik tuzaklarından nasıl kaçınılacağı ile ilgili modelleri ele alacaktır.
HTTPS'ye veya HTTPS'ye değil mi?
Bağlantı zaten güvenli değilse (yani, SSL / TLS kullanarak HTTPS üzerinden tünellenmişse), giriş formu değerleriniz, tarayıcı ve web sunucusu arasındaki satırda dinleyen herkesin girişlerini okurken okuyabilecekleri olan açık metin olarak gönderilir vasitasiyla. Bu tür telefon dinleme, rutin olarak hükümetler tarafından yapılır, ancak genel olarak, şunu söylemek dışında 'sahip olunan' kabloları ele almayacağız: Sadece HTTPS kullanın.
Temel olarak, oturum açma sırasında telefon dinleme / paket koklamasına karşı korumanın tek pratik yolu HTTPS veya başka bir sertifika tabanlı şifreleme şeması (örneğin, TLS ) veya kanıtlanmış ve test edilmiş bir meydan okuma yanıt şeması (örneğin, Diffie-Hellman) kullanmaktır. tabanlı SRP). Herhangi bir başka yöntem, gizli dinleyen bir saldırgan tarafından kolayca çözülebilir .
Elbette, biraz pratik olmaya istekliysen, bazı iki faktörlü kimlik doğrulama şemaları da kullanabilirsin (örneğin, Google Authenticator uygulaması, fiziksel bir 'soğuk savaş tarzı' kod kitabı veya bir RSA anahtar üreticisi dongle). Doğru uygulanırsa, bu güvenli olmayan bir bağlantıda bile işe yarayabilir, ancak bir dev'in SSL'yi değil, iki faktörlü kimlik doğrulamayı uygulamaya istekli olacağını hayal etmek zor.
(Yapmayın) Kendi JavaScript şifrelemenizi / karma işleminizi yapın
Web sitenize algılanan (şimdi kaçınılabilir ) maliyet ve teknik zorluklar göz önüne alındığında, web sitenize SSL sertifikası koymanın maliyeti ve teknik zorlukları göz önüne alındığında , bazı geliştiriciler güvenli olmayan bir kablo üzerinden net metin girişlerini geçirmemek için kendi tarayıcı içi karma ya da şifreleme şemalarını döndürme eğilimindedir.
Bu asil bir düşünce olsa da , yukarıdakilerden biriyle birleştirilmediği sürece esasen faydasızdır (ve bir güvenlik açığı olabilir ) - yani, hattı güçlü şifreleme ile sağlamlaştırmak veya denenmiş ve test edilmiş bir karşı-cevap kullanarak mekanizma (bunun ne olduğunu bilmiyorsanız, sadece kanıtlanması en zor, tasarlamanın en zor ve dijital güvenlik kavramlarını uygulamanın en zor olanlardan biri olduğunu öğrenin).
Şifrenin şifrenin ifşa edilmesine karşı etkili olabileceği doğru olsa da, saldırıları, Ortadaki Adam saldırıları / korsanlıklarını tekrarlamaya açıktır (eğer bir saldırgan güvenli olmayan HTML sayfanıza erişmeden önce birkaç bayt enjekte edebilirse). tarayıcıda, basitçe JavaScript'teki karmasını açıklayabilir) veya kaba kuvvetli saldırıları (saldırganı hem kullanıcı adı, hem de şifreli şifreyi verdiğinizden beri) yorumlayabilir.
CAPTCHAS insanlığa karşı
CAPTCHA belirli bir saldırı kategorisini engellemek içindir: otomatik operatör / kaba kuvvet deneme ve yanılma, insan operatörsüz. Bunun gerçek bir tehdit olduğuna dair hiçbir şüphe yoktur, ancak bir CAPTCHA gerektirmeyen, özellikle de uygun şekilde tasarlanmış sunucu tarafı oturum açma azaltma düzenleri gerektirmeyen, sorunsuz bir şekilde baş etmenin yolları vardır - bunları daha sonra tartışacağız.
CAPTCHA uygulamalarının aynı şekilde yaratılmadığını bilin; genellikle insani çözülemezler, çoğu aslında botlara karşı etkisizdir, hepsi ucuz üçüncü dünya işçiliğine karşı etkisizdir ( OWASP'a göre , mevcut terleme oranı 500 test başına 12 dolar) ve bazı uygulamalar olabilir. Bazı ülkelerde teknik olarak yasa dışı (bkz. OWASP Kimlik Doğrulama Hile Sayfası ). Bir CAPTCHA kullanmanız gerekiyorsa, Google'ın reCAPTCHA'sını kullanın , çünkü tanımı gereği OCR zor olduğundan (zaten OCR'yu yanlış sınıflandırılmış kitap taramaları kullandığından) ve kullanıcı dostu olmak için çok çaba sarfeder.
Şahsen, CAPTCHAS'ı can sıkıcı bulmaya meyilliyim ve bunları yalnızca bir kullanıcı birkaç kez giriş yapamadığında ve azaltma gecikmeleri maksimuma çıktığında son çare olarak kullanıyorum. Bu kabul edilebilir olmak için nadiren gerçekleşecek ve sistemi bir bütün olarak güçlendirecektir.
Şifreleri Saklamak / Girişleri Doğrulamak
Bu, son yıllarda gördüğümüz yüksek düzeyde tanıtılan bilgisayar korsanlıkları ve kullanıcı veri sızıntılarından sonra ortak bilgi olabilir, ancak şunu söylemek gerekir: Şifreleri veritabanınızda açık metin olarak saklamayın. Kullanıcı veritabanları, SQL enjeksiyonu yoluyla düzenli olarak saldırıya uğrulur, sızdırılır veya toplanır ve eğer ham, düz metinli şifreleri saklıyorsanız, oturum açma güvenliğiniz için anında oyun biter.
Öyleyse, şifreyi kaydedemiyorsanız, giriş formundan POST'lu giriş + şifre kombinasyonunun doğru olduğunu nasıl kontrol edersiniz? Cevap, bir anahtar türetme işlevi kullanarak özetliyor . Ne zaman yeni bir kullanıcı oluşturulursa veya bir şifre değiştirilsin, şifreyi al ve Argon2, bcrypt, scrypt veya PBKDF2 gibi bir KDF ile çalıştır, cleartext şifresini ("correcthorsebatterystaple") uzun, rastgele görünümlü bir dizeye çevirerek , veritabanında saklamak çok daha güvenlidir. Bir girişi doğrulamak için, girilen şifrenizde aynı hash işlevini çalıştırın, bu kez tuzu ekleyin ve elde edilen hash dizesini veritabanınızda depolanan değerle karşılaştırın. Argon2, bcrypt ve scrypt, tuzu zaten karma ile saklar. Daha ayrıntılı bilgi için sec.stackexchange adresindeki bu makaleye göz atın.
Bir tuzun kullanılmasının sebebi, kendi başına toplamanın yeterli olmamasıdır - karmaı gökkuşağı tablolarına karşı korumak için 'tuz' denilen bir tane eklemek istersiniz . Bir tuz, bir saldırganın bir şifre tahmin saldırısı gerçekleştirmesi durumunda, tüm veritabanının bir çalıştırmada taranmasını önleyerek, tam olarak aynı hash değeriyle depolanmasını önleyen iki şifreyi etkili bir şekilde önler.
Kullanıcı tarafından seçilen şifreler yeterince güçlü olmadığından (genellikle yeterli entropi içermiyorsa) ve şifre tahmin etme saldırısı, kısa sürede hashlere erişimi olan bir saldırgan tarafından tamamlanabildiği için şifreleme karma şifresi kullanılmamalıdır. Bu nedenle KDF'lerin kullanılması - bunlar etkili bir şekilde "anahtarı uzatır" , bu da bir saldırganın tahmin ettiği her şifre tahmininin karma algoritmanın çoklu tekrarlarına neden olduğu anlamına gelir, örneğin 10.000 kez, saldırganın şifreyi 10.000 kez daha yavaş tahmin etmesine neden olur.
Oturum verileri - "Spiderman69 olarak giriş yaptınız"
Sunucu, kullanıcı veritabanınıza karşı giriş ve şifreyi doğruladıktan ve bir eşleşme bulduğunda, sistem, tarayıcının kimliğinin doğrulandığını hatırlamak için bir yola ihtiyaç duyar. Bu gerçek, yalnızca oturum verilerinde yalnızca sunucu tarafında depolanmalıdır.
Oturum verilerini bilmiyorsanız, işte böyle çalışır: Rastgele oluşturulmuş tek bir dize süresi dolmuş bir çerezde depolanır ve sunucuda depolanan veri koleksiyonuna - oturum verisine - referans vermek için kullanılır. Bir MVC çerçevesi kullanıyorsanız, bu şüphesiz zaten ele alınmıştır.
Mümkünse, oturum çerezinin tarayıcıya gönderildiğinde ayarlanan güvenli ve Yalnızca HTTP bayraklarına sahip olduğundan emin olun. HttpOnly bayrağı, XSS saldırısı yoluyla okunan tanımlama bilgisine karşı bir miktar koruma sağlar. Güvenli bayrak, çerezin yalnızca HTTPS üzerinden geri gönderilmesini sağlar ve bu nedenle ağ koklama saldırılarına karşı korur. Çerezin değeri tahmin edilebilir olmamalıdır. Var olmayan bir oturuma atıfta bulunan bir çerez sunulduğunda, oturumun sabitlenmesini önlemek için değeri derhal değiştirilmelidir .
II. KISIM: Oturum Açılmadan Nasıl Kalabiliriz - Rezil "Beni Hatırla" Onay Kutusu
Kalıcı Giriş Çerezleri ("beni hatırla" işlevselliği) tehlikeli bir bölgedir; Bir yandan, kullanıcılar onları nasıl kullanacaklarını anladıklarında, tamamen geleneksel girişler kadar güvenlidirler; ve diğer taraftan, dikkatsiz kullanıcıların ellerinde, onları halka açık bilgisayarlarda kullanabilen ve çıkış yapmayı unutabilen ve tarayıcı çerezlerinin ne olduğunu ya da nasıl sileceğini bilemeyen çok büyük bir güvenlik riskidir.
Şahsen, düzenli olarak ziyaret ettiğim web siteleri için kalıcı girişler yapmayı seviyorum, ancak onları güvenli bir şekilde nasıl kullanacağımı biliyorum. Kullanıcılarınızın aynı şeyi bildiğinden eminseniz, kalıcı girişleri temiz bir vicdanla kullanabilirsiniz. Olmazsa - öyleyse, giriş bilgileriyle dikkatsiz olan kullanıcıların saldırıya uğradıklarında kendilerine getirdikleri felsefesine abone olabilirsiniz. Bizim kullanıcılarımızın evlerine gitmemiz ve yüz maskesi oluşturan tüm Post-It notlarının, monitörlerinin kenarında sıraya koydukları şifrelerle koparılması gibi bir şey değil.
Tabii ki, bazı sistemler hacklenecek herhangi bir hesaba sahip olamazlar ; Bu tür sistemler için, kalıcı girişlere sahip olduğunuzu haklı gösteremezsiniz.
Kalıcı giriş çerezleri uygulamaya karar verirseniz, işte böyle yaparsınız:
İlk önce, Paragon Girişimi'nin konuyla ilgili makalesini okumak için biraz zaman ayırın . Bir sürü öğeyi doğru yapmanız gerekecek ve makale, her birini açıklamak için harika bir iş çıkarıyor.
Ve sadece en yaygın tuzaklardan birini tekrarlamak için, VERİTABANIZDA, SADECE BİR HASH İÇİNDE KİŞİSEL GİRİŞ KEKLİĞİNİ (TOKEN) SAKMAYIN! Giriş belirteci Şifre Eşdeğeridir, bu nedenle bir saldırgan veritabanınızı ele geçirirse, belirteçleri herhangi bir hesaba giriş yapmak için, tıpkı açık metin giriş-şifre kombinasyonları gibi temizlerler. Bu nedenle, kalıcı oturum açma belirteçlerini depolarken karma kullanın ( https://security.stackexchange.com/a/63438/5002 uyarınca zayıf bir karma bu amaç için gayet iyi sonuç verir).
BÖLÜM III: Gizli Soruları Kullanma
'Gizli sorular' uygulamayın . 'Gizli sorular' özelliği güvenlik karşıtı bir kalıptır. MUST-READ listesinden 4 numaralı linkten makaleyi okuyun. Sarah Palin’e Yahoo! Bir önceki başkanlık kampanyası sırasında e-posta hesabı hacklendi çünkü güvenlik sorusunun cevabı ... "Wasilla Lisesi" idi!
Kullanıcı tarafından belirlenen sorularla bile, çoğu kullanıcının birini seçmesi olasıdır:
Anne kızlık soyadı veya favori evcil hayvan gibi bir 'standart' gizli soru
Herhangi birinin blogundan, LinkedIn profilinden veya benzerlerinden kaldırabileceği basit bir trivia parçası
Cevap vermesi daha kolay olan herhangi bir soru şifrelerini tahmin etmekten daha kolaydır. Hangi, iyi bir şifre için, hayal edebileceğiniz her soru
Sonuç olarak, güvenlik soruları doğal olarak tüm form ve varyasyonlarında doğal olarak güvensizdir ve herhangi bir nedenle bir doğrulama planında kullanılmamalıdır.
Güvenlik sorularının vahşi doğada bile var olmasının asıl nedeni, bir yeniden etkinleştirme koduna ulaşmak için e-postalarına erişemeyen kullanıcılardan gelen birkaç destek çağrısının maliyetini uygun şekilde kurtarmalarıdır. Bu güvenlik pahasına ve Sarah Palin ünü. Buna değer? Muhtemelen değil.
BÖLÜM IV: Unutulan Parola İşlevselliği
Unutulmuş / kayıp kullanıcı şifrelerini ele almak için neden hiçbir zaman güvenlik sorularını kullanmamanız gerektiğinden bahsettim ; aynı zamanda kullanıcılara gerçek şifrelerini asla e-postayla göndermemelisiniz demeden de geçerli. Bu alanda kaçınılması gereken en az iki tane çok yaygın tuzak vardır:
Etmeyin sıfırlamak bir autogenerated güçlü şifre unutulmuş bir parola - söz, parlak sarı üzerine Post-It onların monitörün kenarında - Böyle şifreleri kullanıcıya bunu değiştirmek veya yere yazmak gerekir anlamına gelir hatırlamak herkesin bildiği gibi zor. Yeni bir şifre belirlemek yerine, kullanıcıların derhal yenilerini seçmelerine izin verin - ki bu zaten ne yapmak istediklerini. (Bunun bir istisnası, kullanıcılar, normalde yazmadan hatırlamak imkansız olan şifreleri saklamak / yönetmek için evrensel olarak bir şifre yöneticisi kullanıyorsa olabilir).
Daima veritabanında kayıp şifre kodunu / jetonunu kullanın. TEKRAR , bu kod bir Parola Eşdeğerinin başka bir örneğidir, bu nedenle bir saldırganın veritabanınızı ele geçirmesi durumunda karıştırılmalıdır. Kayıp bir şifre kodu istendiğinde, düz metin kodunu kullanıcının e-posta adresine gönderin, ardından karma yapın, karma veri tabanına kaydedin - ve orijinali atın . Tıpkı bir şifre veya kalıcı bir giriş belirteci gibi.
Son bir not: 'Kayıp parola kodunu' girmek için arayüzünüzün en azından giriş formunuzun kendisi kadar güvenli olduğundan emin olun, aksi halde saldırgan erişim sağlamak için bunu kullanır. Çok uzun 'kayıp şifre kodları' (örneğin, büyük / küçük harf duyarlı 16 alfasayısal 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ün Kontrolü
İlk önce, bir gerçeklik kontrolü için bu küçük makaleyi okumak isteyeceksiniz: En yaygın 500 şifre
Tamam, belki de liste herhangi bir yerde herhangi bir sistemdeki en yaygın şifrelerden oluşan kanonik bir liste değildir , ancak zorla uygulanan bir politika olmadığında, insanların ne kadar zayıf bir şekilde şifrelerini seçeceklerinin iyi bir göstergesidir. Ayrıca, liste, yeni çalınan şifrelerle ilgili kamuya açık analizlerle karşılaştırdığınızda, eve korkunç bir şekilde yaklaşıyor.
Yani: Minimum şifre gücü gereksinimi olmadan, kullanıcıların% 2'si en yaygın 20 şifreden birini kullanır. Anlamı: Bir saldırgan sadece 20 girişimde bulunursa, web sitenizdeki 50 hesaptan 1'i kırılabilir.
Bunu engellemek, bir parolanın entropisinin hesaplanmasını ve ardından bir eşik uygulanmasını gerektirir. Ulusal Standartlar ve Teknoloji Enstitüsü (NIST) Özel Yayın 800-63 bir dizi çok iyi öneriye sahiptir. Bu, bir sözlük ve klavye düzeni analizi (örneğin, 'qwertyuiop' kötü bir şifredir) ile birleştirildiğinde, kötü seçilmiş tüm şifrelerin% 99'unu 18 bit entropi düzeyinde reddedebilir . Sadece şifre gücünü hesaplamak ve bir kullanıcıya görsel güç ölçer kullanmak, iyi fakat yetersizdir. Zorunlu olmadıkça, birçok kullanıcı bunu görmezden gelecektir.
Entropi şifrelerinin kullanım kolaylığı konusunda canlandırıcı bir görünüm için , Randall Munroe'nin Password Strength xkcd'i şiddetle tavsiye ediyoruz.
Kullanıcıların şifrelerini, genel veri ihlallerinde tehlikeye giren şifrelere karşı kontrol etmek için Troy Hunt'in Pwned API'sini kullanın.
BÖLÜM VI: Çok Daha Fazlası - Veya: Hızlı Ateşlemeli Girişim Girişimlerini Önleme
İlk olarak, sayılara bir göz atın: Şifre Kurtarma Hızları - Şifreniz ne kadar süre dayanır?
Bu bağlantıdaki tablolara bakmak için zamanınız yoksa, işte bunların listesi:
Bu sürer neredeyse hiçbir zaman bir abaküs ile çatlama olsanız bile, zayıf bir parolayı çözmek
Büyük - küçük harf duyarlı değilse, alfanümerik 9 karakterli bir şifreyi kırmak neredeyse zaman almaz
Bu sürer neredeyse hiçbir zaman Çünkü eğer karmaşık, semboller-ve-harfler-ve-sayı, büyük ve küçük harf-şifresini kırmak için daha az 8 karakter uzunluğunda (bir masaüstü bilgisayar bir konuda 7 karakterden tüm KEYSPACE kadar arama yapabilirsiniz günlerce hatta saatlerce)
Ancak, saniyede bir kez denemeyle sınırlı olsaydınız , 6 karakterlik bir şifreyi bile kırmak için zaman harcayamazdı !
Peki bu rakamlardan ne öğrenebiliriz? Pekala, çok, ama en önemli kısma odaklanabiliriz: Çok sayıda hızlı ateş peş peşe oturum açma girişiminin (yani kaba kuvvet saldırısı) engellenmesi gerçekten zor değil. Fakat doğru olanı engellemek göründüğü kadar kolay değildir.
Genel olarak konuşursak, kaba kuvvet saldırılarına (ve sözlük saldırılarına) karşı etkili olan üç seçeneğiniz vardır , ancak zaten güçlü parolalar politikası uyguladığınız için , bunların bir sorun olmaması gerekir :
N başarısız denemeden sonra bir CAPTCHA sunun (cehennem kadar can sıkıcı ve genellikle etkisiz - ama burada kendimi tekrar ediyorum)
Hesapların kilitlenmesi ve N başarısız denemeden sonra e-posta doğrulaması gerektiren (bu, gerçekleşmeyi bekleyen bir DoS saldırısıdır)
Ve son olarak, oturum açmayı azaltma : yani, N başarısız denemelerinden sonra yapılan girişimler arasında bir zaman gecikmesi ayarlamak (evet, DoS saldırıları hala mümkün, ama en azından onlar çok daha az muhtemel ve çekilmeleri çok daha karmaşık).
En iyi uygulama # 1: Başarısız deneme sayısı ile birlikte artan kısa bir gecikme, ö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 sn gecikme
- 4 başarısız deneme = 8 sn gecikme
- 5 başarısız deneme = 16 saniye gecikme
- vb.
Bu şemaya saldıran DoS çok pratik olmaz çünkü sonuçta kilitlenme süresi önceki kilitlenme sürelerinin toplamından biraz daha büyüktür.
Açıklığa kavuşturmak için: Gecikme, yanıtı tarayıcıya döndürmeden önce bir gecikme değildir . Belirli bir hesaba giriş veya belirli bir IP adresinden giriş yapma girişimlerinin hiç bir zaman kabul edilmeyeceği veya değerlendirilmediği zaman aşımı veya refrakter süresi gibi. Yani, doğru kimlik bilgileri başarılı bir oturum açma işleminde geri dönmeyecek ve hatalı kimlik bilgileri gecikme artışını tetiklemeyecektir.
En iyi uygulama # 2: N başarısız denemeden sonra geçerli olan orta uzunluktaki bir gecikme süresi:
- 1-4 başarısız deneme = gecikme yok
- 5 başarısız deneme = 15-30 dk gecikme
Bu şemaya saldıran DoS oldukça pratik olurdu, 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 unutmamak gerekebilir. Unutkan kullanıcılar senden hoşlanmayacaklar.
En iyi uygulama # 3: İki yaklaşımın birleştirilmesi - N başarısız denemeden sonra geçerli olan sabit, kısa bir zaman gecikmesi.
- 1-4 başarısız deneme = gecikme yok
- 5+ başarısız deneme = 20 sn gecikme
Veya, sabit bir üst sınır ile artan bir gecikme, örneğin:
- 1 başarısız deneme = 5 sn gecikme
- 2 başarısız deneme = 15 sn gecikme
- 3+ başarısız deneme = 45 sn gecikme
Bu son şema, OWASP en iyi uygulamalar önerilerinden (MUST-READ listesinden 1. link) alınmıştır ve kuşkusuz kısıtlayıcı tarafta olsa bile en iyi uygulama olarak düşünülmelidir.
Ancak, bir kural olarak, şunu söyleyebilirim ki: şifre politikanız ne kadar güçlüyse, kullanıcıları gecikmelerle o kadar az zorlarsınız. Güçlü (büyük / küçük harf duyarlı alfanümerikler + gerekli sayılar ve semboller) 9+ karakterli şifreler gerektiriyorsa, kullanıcılara azaltmayı etkinleştirmeden önce 2-4 gecikmeli olmayan şifre girişimi verebilirsiniz.
Bu son oturum açma azaltma düzenine saldıran DoS çok pratik olmazdı . Ve son bir dokunuş olarak, her zaman kalıcı (çerez) girişlerin (ve / veya CAPTCHA onaylı bir giriş formu) geçmesine izin verin, böylece meşru kullanıcılar saldırı devam ederken ertelenmez . Bu şekilde, pratik olmayan DoS saldırısı son derece pratik olmayan bir saldırı haline gelir .
Ek olarak, en cazip giriş noktaları olan yönetici hesaplarına daha agresif bir şekilde kısma yapmak mantıklı geliyor.
BÖLÜM VII: Dağıtılmış Brute Force Saldırıları
Tıpkı bir yana, daha gelişmiş saldırganlar 'faaliyetlerini yayarak' girişleri engellemeye çalışacaklar:
IP adresinin işaretlenmesini önlemek için girişimlerin botnet üzerine dağıtılması
Bir kullanıcı seçmek ve 50.000 en yaygın şifreyi denemek yerine (kullanamayacağımız, kullanamadıkları), en yaygın şifreyi seçecek ve 50.000 kullanıcıya karşı deneyeceklerdir. Bu şekilde, yalnızca CAPTCHA'lar ve oturum açma azaltma gibi maksimum denemeler yapmakla kalmazlar, başarı şansları da artar, çünkü en yaygın 1 numaralı şifre 49,995'ten çok daha fazladır
Her kullanıcı hesabı için oturum açma isteklerini, örneğin, 30 saniye arayla, radarın altından gizlice girmek
Burada, en iyi uygulama , başarısız oturum açma sayısını sistem genelinde günlüğe kaydetmek ve sitenizin hatalı oturum açma sıklığının ortalama çalışmasını kullanarak tüm kullanıcılara uygulayacağınız üst sınırın temelini oluşturmaktır.
Çok soyut? Tekrar ifade etmeme izin ver:
Sitenizin son 3 ay içinde günde ortalama 120 kötü giriş yaptığını varsayalım. Bunu kullanarak (ortalama çalışan), sisteminiz genel limiti 3 katına ayarlayabilir - yani. 360 saatlik 24 saatlik bir denemede başarısız oldu. 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ı izleyin ve hesaplanan bir eşikte tetikleyin), sistem genelinde oturum açma kısıtlamasını etkinleştirir - 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 daha ayrıntılı bilgi içeren bir soru ve dağıtılmış kaba kuvvet saldırılarını engellemede zorlu tuzaklardan nasıl uzak durulacağına dair gerçekten iyi bir tartışma yayınladım .
BÖLÜM VIII: İki Faktörlü Kimlik Doğrulama ve Kimlik Doğrulama Sağlayıcıları
Kötüye kullanma, yazılan ve kaybedilen şifreler, anahtarların çalındığı dizüstü bilgisayarlar veya oturum açma yapan kişilere kimlik avı sitelerine girip girmeme konusunda kimlik bilgilerinden ödün verilebilir. Oturum açma, bir telefon görüşmesinden alınan tek kullanımlık kodlar, SMS mesajı, uygulama veya donanım kilidi gibi bant dışı faktörleri kullanan iki faktörlü kimlik doğrulaması ile daha da korunabilir. Birkaç sağlayıcı, iki faktörlü kimlik doğrulama hizmetleri sunar.
Kimlik doğrulama, başka bir sağlayıcının kimlik bilgileri toplama işlemlerini gerçekleştirdiği tek oturum açma hizmetine tamamen devredilebilir. Bu, sorunu güvenilir bir üçüncü tarafa iter. Hem Google hem de Twitter standartlara dayalı SSO hizmetleri sunarken, Facebook da benzer bir özel çözüm sunar.
MUST READ LİNKLER Web Kimlik Doğrulama Hakkında
- Kimlik doğrulama için OWASP Rehberi / OWASP Kimlik Doğrulama Hile Sayfası
- Web'de Müşteri Kimlik Doğrulamanın Yapılması ve Yapılmaması Gerekenler (çok okunaklı MIT araştırma raporu)
- Wikipedia: HTTP çerezi
- Geri dönüş doğrulama için kişisel bilgi soruları: Facebook döneminde güvenlik soruları (çok okunabilir Berkeley araştırma makalesi)