BÖLÜM I: Nasıl Giriş Yapılır
Kimlik doğrulaması için sunucu tarafındaki bir komut dosyasına değerlerini GÖNDEREN bir giriş + şifre HTML formunun nasıl oluşturulacağını zaten bildiğinizi varsayalım. Aşağıdaki bölümler, pratik pratik için uygun kalıpları ve en yaygın güvenlik tuzaklarını nasıl önleyeceklerini ele alacaktır.
HTTPS'ye mi yoksa HTTPS'ye mi değil?
Bağlantı zaten güvenli olmadıkça (yani, SSL / TLS kullanarak HTTPS ile tünel), giriş formu değerleriniz cleartext olarak gönderilir, bu da tarayıcı ile web sunucusu arasındaki hat üzerinde herkesin geçerken oturum açma bilgilerini okuyabilmesini sağlar. vasitasiyla. Bu tür telefon dinleme işlemleri, genellikle devletler tarafından gerçekleştirilir, ancak genel olarak, 'sahip olunan' telleri ele almaktan başka bir şeye hitap etmeyiz: Önemli bir şeyi koruyorsanız, HTTPS'yi kullanın.
Özünde, sadece pratik Oturum açma sırasında telefon dinleme / paket koklamasından korunma 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-Hellmantabanlı SRP). Başka herhangi bir yöntem kolayca atlanabilir dinleyen bir saldırgan tarafından.
Elbette, biraz pratik olmak istemiyorsanız, iki faktörlü bir kimlik doğrulama şeması (ör. Google Authenticator uygulaması, fiziksel "soğuk savaş stili" kod kitabı veya bir RSA anahtar üreticisi dongle) biçimini de kullanabilirsiniz. Doğru bir şekilde uygulandığında, bu güvenli olmayan bir bağlantıyla bile çalışabilir, ancak bir devin SSL yerine iki faktörlü yetkilendirmeyi uygulamaya istekli olacağını düşünmek zordur.
(Yapmayın) Kendi JavaScript şifrelemeyi / hashing'i kendiniz toplayın
Web sitenizde bir SSL sertifikası oluşturmanın sıfır maliyet ve algılanan teknik zorluğu göz önüne alındığında, bazı geliştiriciler, güvenli olmayan bir tel üzerinden net metin girişlerini geçirmekten kaçınmak için kendi tarayıcı içi şifreleme veya şifreleme şemalarını hazırlama konusunda caziptir.
Bu asil bir düşünce iken, aslında işe yaramaz (ve güvenlik kusuru) Yukarıdakilerden biriyle birleştirilmediyse - yani, ya güçlü şifreleme ile ya da denenmiş ve test edilmiş bir karşı-yanıt mekanizmasını kullanarak çizgiyi güvenceye almaksızın (bunun ne olduğunu bilmiyorsanız, sadece bunun bir tane olduğunu bilin) kanıtlanması en zor olanı, tasarımı zor ve dijital güvenlik uygulamalarını zorlaştırması en zor olanıdır.
Parolayı bozmanın doğru olduğu halde olabilir karşı etkili şifre açıklaması, saldırıları yeniden başlatmak, savunmasız adam saldırıları / saldırıları (bir saldırgan tarayıcınıza ulaşmadan önce güvenli olmayan HTML sayfanıza birkaç bayt enjekte edebilirse, JavaScript’teki karmaşayı kolayca yorumlayabilir), ya da kaba kuvvet saldırıları (saldırganı hem kullanıcı adı, hem tuz hem de şifreli şifre verdiğiniz için).
CAPTCHAS insanlığa karşı
CAPTCHA'ları belirli bir saldırı kategorisini engellemeye yöneliktir: hiçbir insan operatörüyle otomatik sözlük / kaba kuvvet deneme-hatası. Bunun gerçek bir tehdit olduğuna şüphe yok; ancak CAPTCHA, özellikle uygun şekilde tasarlanmış sunucu taraflı giriş kısıtlama şemaları gerektirmeyen sorunsuz bir şekilde uğraşmanın yolları var. Bunu daha sonra tartışacağız.
CAPTCHA uygulamalarının benzer şekilde oluşturulmadığını bilin; Genellikle insani çözülemezler, çoğu aslında botlara karşı etkisizdir, hepsi ucuz üçüncü dünya emeğine karşı etkisizdir. OWASPŞu anki sweatshop oranı 500 test için 12 $ 'dır) ve bazı ülkelerde bazı uygulamalar teknik olarak yasa dışı olabilir (bkz. OWASP Kimlik Doğrulama Hile Sayfası). Bir CAPTCHA kullanmanız gerekiyorsa Google’ları kullanın reCAPTCHAÇünkü OCR-hard, tanım gereğidir (zaten OCR-yanlış sınıflandırılmış kitap taramalarını kullandığı için) ve kullanıcı dostu olmak için çok uğraşır.
Şahsen CAPTCHAS'ı sinir bozucu bulmaya eğilimliyim ve bir kullanıcı bir kaç kez giriş yapamadığında ve kısa süreli gecikme süreleri bitince sadece son çare olarak kullanıyorum. Bu, kabul edilebilecek kadar nadiren gerçekleşecek ve sistemi bir bütün olarak güçlendirecek.
Şifrelerin Saklanması / Girişlerin Doğrulanması
Son yıllarda gördüğümüz, son derece popüler hale getirilmiş hackler ve kullanıcı veri sızıntılarından sonra bu genel bir bilgi olabilir, ancak şunu söylemelisiniz: Şifrelerinizi veritabanında cleartext olarak saklamayın. Kullanıcı veritabanları, SQL enjeksiyonu ile rutin olarak saldırıya uğradı, sızdırıldı ya da toplandı, ve ham, düz metin şifreleri depolıyorsanız, giriş güvenliğiniz için anlık oyun bitti.
Bu yüzden şifreyi saklayamazsanız, giriş formundan POSTed giriş + şifre kombinasyonunun doğru olup olmadığını nasıl kontrol edersiniz? Cevap, anahtar türetme işlevi. Yeni bir kullanıcı oluşturulduğunda ya da bir şifre değiştirildiğinde, şifreyi alıp Argon2, bcrypt, scrypt ya da PBKDF2 gibi bir KDF'den geçirerek net metin parolasını ("correcthorsebatterystaple") uzun, rastgele görünümlü bir dizeye dönüştürürsünüz. Veritabanında saklamak için çok daha güvenli. Bir girişi doğrulamak için, girilen şifrede aynı hash işlevini çalıştırırsınız, bu sefer tuzu aktarır ve sonuçta oluşan hash dizesini veritabanınızda depolanan değere göre karşılaştırırsınız. Argon2, bcrypt ve scrypt tuzu şimdiden hash ile saklar. Bunu kontrol et makale Daha detaylı bilgi için sec.stackexchange üzerinde.
Bir tuzun kullanılmasının nedeni, kendi içinde karmaşanın yeterli olmamasıdır - karmayı korumak için sözde bir 'tuz' eklemek istersiniz. gökkuşağı masaları. Bir tuz, bir saldırganın bir şifre tahmin saldırısı gerçekleştirmesi durumunda tüm veritabanının bir seferde taranmasını engelleyerek, aynı karma değeri olarak depolanmaktan tamamen eşleşen iki şifreyi etkin bir şekilde önler.
Kullanıcı şifreleri yeterince güçlü olmadığından (yani genellikle yeterli entropi içermediğinden) ve şifre tahmin saldırısının nispeten kısa bir süre içinde karmaşalara erişimi olan bir saldırgan tarafından tamamlanabildiği için bir şifreleme karma şifresi kullanılmamalıdır. Bu yüzden bir KDF kullanılır - bunlar etkili bir şekilde "anahtarı uzat" her bir parolayıcının bir saldırganın tahmin ettiğini tahmin etmesi, karma algoritmayı birkaç kez yinelemeyi, örneğin 10,000 kez, saldırganın parolasını 10,000 kat daha yavaş tahmin etmeyi gerektirir.
Seans 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, sistemin tarayıcının doğrulandığını hatırlamanın bir yolu olmalıdır. Bu gerçek sadece oturum verilerinde sunucu tarafında saklanmalıdır.
Oturum verilerine aşina değilseniz, işte nasıl çalışır: Rastgele oluşturulmuş tek bir dize, bir zaman aşımına uğrayan çerezde saklanır ve sunucuda depolanan bir veri topluluğuna (oturum verileri) başvurmak 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 güvenli ve HTTP Sadece bayraklarının ayarlandığından emin olun. Httponly bayrağı, XSS saldırısı tarafından okunan çerezlere karşı biraz koruma sağlar. Güvenli bayrak, çerezin sadece HTTPS ile geri gönderilmesini sağlar ve bu nedenle ağ koklama saldırılarına karşı koruma sağlar. Çerezin değeri öngörülebilir olmamalıdır. Mevcut olmayan bir oturuma atıfta bulunan bir çerez sunulduğunda, önlenmesi için değeri hemen değiştirilmelidir. oturum sabitleme.
KISIM II: Nasıl Giriş Yapılır? - Beni Unutma "Beni Hatırla" Onay Kutusu
Kalıcı Giriş Çerezleri ("Beni hatırla" işlevi) bir tehlike bölgesidir; Bir yandan, kullanıcılar bunları nasıl kullanacaklarını anladıklarında geleneksel girişler kadar güvenlidirler; ve diğer yandan, dikkatsiz kullanıcıların ellerinde muazzam bir güvenlik riski taşıyorlar, bu da onları kamuya açık bilgisayarlarda kullanabiliyorlar ve çıkış yapmayı unutuyorlar, ve hangi tarayıcı çerezlerinin olduğunu ya da bunları nasıl sileceklerini bilemiyorlar.
Şahsen ben düzenli olarak ziyaret ettiğim web siteleri için sürekli girişleri severim, ancak bunları nasıl güvenli bir şekilde ele alacağımı biliyorum. Kullanıcılarınızın aynı şeyi bildiği konusunda olumluysanız, kalıcı oturumları temiz bir vicdanla kullanabilirsiniz. Değilse - o zaman, o zaman giriş kimlik bilgileri ile dikkatsiz olan kullanıcıların saldırıya uğramışlarsa kendilerine getirdikleri felsefeye abone olabilirsiniz. Kullanıcılarımızın evlerine gidip, tüm bu facepalm-indükleyici Post-It notlarını, monitörlerinin kenarlarına dizilmiş şifrelerle koparmak gibi değil.
Tabii ki, bazı sistemler sahip olamaz herhangi hesaplar kesildi; Bu tür sistemler için, kalıcı girişlere sahip olmanın haklı bir yolu yoktur.
Kalıcı giriş çerezleri uygulamaya karar verirseniz, bunu nasıl yaparsınız:
-
İlk önce okumak için biraz zaman ayırın Paragon Girişimi makalesi Konuyla ilgili. Doğru bir demet öğe almanız gerekecek ve makale her birini açıklamak için harika bir iş çıkardı.
-
Ve sadece en yaygın tuzaklardan birini tekrarlamak, VERİ TABANI'NDA SADECE BİR GEMİ HATASIYLA GÜNLÜK GİRİŞ COOKIE'Nİ (TOKEN) SAKLAYINIZ! Giriş belirteci Parola Eşdeğeridir, bu nedenle bir saldırgan ellerinizi veritabanınıza aldığında, herhangi bir hesaba giriş yapmak için jetonları kullanabilirler, tıpkı oturum açma şifresi kombinasyonları gibi. Bu nedenle, hashing kullanın (göre https://security.stackexchange.com/a/63438/5002 Kalıcı giriş tokensi saklanırken zayıf bir karma, bu amaç için iyi olacaktır.
BÖLÜM III: Gizli Soruları Kullanma
'Gizli soruları' uygulama. 'Gizli sorular' özelliği bir güvenlik anti-desen. ZORUNLU listeden 4 numaralı linkten kağıdı okuyun. Sarah Palin’e bundan sonra, Yahoo’dan sonra sorabilirsin. Güvenlik sorusunun cevabı "Wasilla Lisesi" olduğu için e-posta hesabı önceki başkanlık kampanyası sırasında hacklendi!
Kullanıcı tarafından belirlenen sorularda bile, çoğu kullanıcının aşağıdakilerden birini seçmesi olasıdır:
-
Annenin kızlık soyadı ya da favori evcil hayvanı gibi bir 'standart' gizli soru
-
Herkesin blog'larından, LinkedIn profillerinden veya benzerlerinden kaldırabileceği basit bir trivia parçası.
-
Parolalarını tahmin etmekten daha kolay bir soru. Hangi, herhangi bir iyi şifre için, hayal edebileceğiniz her soru
Sonuç olarak, güvenlik soruları, hemen hemen tüm form ve varyasyonlarında doğal olarak güvensizdir ve herhangi bir nedenden dolayı bir doğrulama şemasında kullanılmamalıdır.
Güvenlikle ilgili soruların neden yabancılar için mevcut olmasının gerçek nedeni, yeniden etkinleştirme kodunu almak için e-postalarına erişemeyen kullanıcılardan birkaç destek çağrısının maliyetini uygun bir şekilde kaydetmeleridir. Bu güvenlik ve Sarah Palin'in saygınlığı pahasına. Buna değer? Muhtemelen değil.
BÖLÜM IV: Unutulan Şifre İşlevselliği
Neden gerektiğini söylemiştim asla güvenlik soruları kullanmayınunutulmuş / kayıp kullanıcı şifrelerini işlemek için; Ayrıca, kullanıcılara gerçek şifrelerini asla e-posta ile göndermemeniz gerektiğini söylemeden devam eder. Bu alanda kaçınmak için en az iki genel tuzak var:
-
Yapma sıfırlamak otomatik olarak oluşturulmuş güçlü bir parola için unutulmuş bir parola - bu tür parolaların hatırlanması zor bir şeydir, bu da kullanıcının onu değiştirmesi veya yazması gerektiği anlamına gelir - örneğin, monitörlerinin kenarında parlak sarı bir Post-It. Yeni bir şifre ayarlamak yerine, kullanıcıların hemen yeni bir tane seçmelerine izin verin. Bu, zaten yapmak istedikleri şeydir. (Bunun istisnası, eğer kullanıcılar, normalde yazmadan hatırlamak imkansız olacak şifreleri saklamak / yönetmek için bir şifre yöneticisi kullanıyorsa).
-
Her zaman veritabanında kayıp şifre kodu / jetonu vardır. TEKRARBu kod, bir Parola Eşdeğeri'nin başka bir örneğidir, bu nedenle bir saldırganın ellerinizi veritabanına alması durumunda bir karmaşanın olması ZORUNLUdur. Kayıp şifre kodu istendiğinde, düz metin kodunu kullanıcının e-posta adresine yollayın, sonra karta kaydedin ve karmaşayı veritabanınıza kaydedin - ve orijinali atmak. Sadece bir şifre veya kalıcı bir giriş belirteci gibi.
Son not: Her zaman 'kayıp şifre kodunu' girmek için kullandığınız arayüzün, giriş formunun kendisi kadar güvenli olduğundan emin olun, yoksa bir saldırgan bunun yerine erişim kazanmak için bunu kullanacaktır. Çok uzun 'kayıp şifre kodları' oluşturduğunuzdan emin olmak (örneğin, büyük küçük harf duyarlı alfasayısal karakterler) iyi bir başlangıçtır, ancak giriş formunun kendisi için yaptığınız aynı kısıtlama şemasını eklemeyi düşünebilirsiniz.
BÖLÜM V: Şifre Güvenliğini Kontrol Etme
Öncelikle, bir gerçeklik kontrolü için bu küçük makaleyi okumak isteyeceksiniz: En yaygın 500 şifreler
Tamam, belki de liste standart en yaygın şifrelerin listesi herhangi sistem herhangi bir yerdeAncak, yürürlükte olan bir politika bulunmadığında insanların parolalarını ne kadar zayıf seçeceklerinin iyi bir göstergesidir. Ayrıca, son çalınan şifrelerin herkese açık analizleriyle karşılaştırdığınızda liste korkutucu bir şekilde eve yakın görünüyor.
Yani: Minimum şifre gücü gereksinimleri olmadan, kullanıcıların% 2'si en yaygın 20 şifreden birini kullanır. Anlamı: Bir saldırganın sadece 20 denemesi olursa, web sitenizde 50 hesapta 1 şifre kırılabilir.
Bunu engellemek, bir şifrenin entropisini hesaplamayı ve daha sonra bir eşik uygulamayı gerektirir. Ulusal Standartlar ve Teknoloji Enstitüsü (NIST) Özel Yayın 800-63 çok iyi önerilerden oluşan bir dizi var. Bu, bir sözlük ve klavye düzeni analizi ile birleştirildiğinde (örneğin, 'qwertyuiop' kötü bir paroladır), kötü seçilmiş tüm şifrelerin% 99'unu reddet 18 bit entropi düzeyinde. Sadece şifre gücünü hesaplamak ve görsel güç ölçer gösteriliyor Bir kullanıcıya iyi, ama yetersiz. Zorlanılmadıkça, pek çok kullanıcı büyük olasılıkla bunu göz ardı eder.
Ve yüksek entropi şifrelerin kullanıcı dostu olmasını ferahlamak için Randall Munroe'nin Şifre Gücü xkcd şiddetle tavsiye edilir.
BÖLÜM VI: Çok Daha Fazla - Veya: Hızlı Yangın Giriş Denemelerini Önleme
İlk önce, sayılara bir göz atın: Şifre Kurtarma Hızları - Şifreniz ne kadar süre dayanacak?
Bu bağlantıdaki tablolara bakmak için zamanınız yoksa, işte bunların listesi:
-
Alır neredeyse hiç zaman yok zayıf bir şifreyi kırmak için, bir abaküsle çatlasanız bile
-
Alır neredeyse hiç zaman yok eğer bir alfanümerik 9 karakterli şifreyi kırmak büyük / küçük harfe duyarlı
-
Alır neredeyse hiç zaman yok eğer karmaşık, sembol-ve-harf-ve-sayılar, üst-ve-küçük harf şifre kırmak için 8 karakterden daha az (Masaüstü PC, gün veya saat cinsinden toplam 7 karaktere kadar tüm tuş aralığını arayabilir)
-
Bununla birlikte, 6 karakterlik bir şifreyi bile kırmak için çok fazla zaman harcamalı, Saniyede bir denemeyle sınırlı olsaydınız!
Peki bu sayılardan neler öğrenebiliriz? Pek çok şey, ama en önemli kısma odaklanabiliyoruz: çok sayıda hızlı-ateş ardışık giriş girişiminin önlenmesi. kaba kuvvet saldırı) gerçekten zor değil. Ama bunu engellemek sağ göründüğü kadar kolay değil.
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 ilkesi kullandığınız için, bir sorun olmamalıdır):
-
Mevcut bir CAPTCHA N başarısız girişimlerden sonra (cehennem gibi rahatsız edici ve çoğu zaman etkisiz - ama ben burada kendimi tekrarlıyorum)
-
Kilitli hesaplar N başarısız denemeden sonra e-posta doğrulaması gerektiriyor (bu bir DoS saldırı olmasını beklemek)
-
Ve sonunda, giriş kısılmasıYani, N başarısız girişimlerden sonra girişimler arasında bir zaman gecikmesi ayarlanması (evet, DoS saldırıları hala mümkündür, ancak en azından çok daha az olasıdır ve çekilmesi çok daha karmaşıktır).
En iyi uygulama # 1: Başarısız denemelerin sayısıyla artacak kısa bir gecikme:
- 1 başarısız girişim = gecikme yok
- 2 başarısız deneme = 2 sn gecikme
- 3 başarısız girişim = 4 sn gecikme
- 4 başarısız deneme = 8 sn gecikme
- 5 başarısız deneme = 16 sn gecikme
- vb.
Bu şemaya saldıran DoS, çok pratik değildir, sonuçta ortaya çıkan kilitlenme süresi, önceki kilitlenme sürelerinin toplamından biraz daha büyüktür.
Açıklığa kavuşturmak için: Gecikme değil yanıtı tarayıcıya geri göndermeden önce bir gecikme. Daha çok, belirli bir hesaba giriş yapan veya belirli bir IP adresinden yapılan girişimlerin kabul edilmeyeceği veya değerlendirilmeyeceği bir zaman aşımı veya refrakter dönem gibidir. Yani, doğru kimlik bilgileri başarılı bir girişte 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 gecikme süresi:
- 1-4 başarısız denemeler = gecikme yok
- 5 başarısız girişim = 15-30 dk gecikme
Bu programa saldıran DoS oldukça pratik bir uygulama olacaktır, ancak kesinlikle yapılabilir. Ayrıca, böyle uzun bir gecikmenin meşru bir kullanıcı için çok can sıkıcı olabileceğine dikkat etmek yerinde olabilir. Unutkan kullanıcılar sizi beğenmeyecek.
En iyi uygulama # 3: İki yaklaşımı birleştirmek - N başarısız denemeden sonra yürürlüğe giren sabit, kısa bir gecikme, örneğin:
- 1-4 başarısız denemeler = gecikme yok
- 5+ başarısız denemeler = 20 sn gecikme
Veya, aşağıdaki gibi sabit bir üst sınır ile artan bir gecikme:
- 1 başarısız girişim = 5 sn gecikme
- 2 başarısız deneme = 15 sn gecikme
- 3+ başarısız deneme sayısı = 45 saniye gecikme
Bu son şema, OWASP en iyi uygulama önerilerinden alınmıştır (ZORUNLU listeden 1. bağlantı) ve kısıtlayıcı tarafa kabul edilmiş olsa bile en iyi uygulama olarak düşünülmelidir.
Bununla birlikte, bir kural olarak şunu söyleyebilirim: şifre politikanız ne kadar güçlü olursa, kullanıcıları gecikme konusunda daha az sorunla karşı karşıya bırakabilirsiniz. Güçlü (büyük küçük harf duyarlı alfanümerik + gerekli sayılar ve semboller) 9+ karakter parolaları gerektiriyorsa, kullanıcılara, kısaltmayı etkinleştirmeden önce 2-4 gecikmeli olmayan parola girişimleri verebilirsiniz.
Bu son giriş kısıtlama şemasına saldıran DoS olurdu çok pratik. Ve son bir dokunuş olarak, sürekli (çerez) girişlerin (ve / veya bir CAPTCHA-onaylı giriş formunun) geçmesine izin verin, böylece meşru kullanıcılar bile gecikmeyeceklerdir. saldırı devam ederken. Bu şekilde, çok pratik olmayan DoS saldırısı bir son derece pratik olmayan saldırı.
Ek olarak, yönetici hesaplarında daha agresif azaltma yapmak mantıklıdır çünkü bunlar en çekici giriş noktalarıdır
BÖLÜM VII: Dağıtılmış Brute Force Attacks
Tıpkı bir kenara göre, daha gelişmiş saldırganlar, 'aktivitelerini yayarak' girişin azaltılmasını engellemeye çalışacaklardır:
-
IP adresini işaretlemeyi engellemek için botnet'teki girişimleri dağıtma
-
Bir kullanıcı seçip 50.000 en çok kullanılan şifreyi (ki bu da bizim boğazımızdan dolayı yapamazlar) denemek yerine, en yaygın şifreyi seçecek ve bunun yerine 50.000 kullanıcıya karşı çalışacaklar. Böylelikle, CAPTCHAs ve oturum açma daraltma gibi azami denemelerle ilgili önlemleri almakla kalmıyor, aynı zamanda başarı şansları da artıyor, çünkü en yaygın 1 numaralı şifre 49.995 rakamından çok daha fazladır.
-
Radarın altından gizlice girmek için, 30 saniye arayla, her kullanıcı hesabının giriş isteklerini sınırlandırın
İşte, en iyi uygulama sistem çapında, başarısız girişlerin sayısını günlüğe kaydetmeve sitenizin kötü giriş frekansının çalışan bir ortalamasını kullanarak tüm kullanıcılara yüklediğiniz bir üst sınırın temeli olarak kullanabilirsiniz.
Çok soyut? Tekrar ifade edeyim:
Son 3 ay içinde sitenizin günde ortalama 120 hatalı giriş yaptığını varsayalım. Bunu kullanarak (ortalama çalışma), sisteminiz küresel sınırı 3 katına ayarlayabilir - yani. 24 saatlik bir süre zarfında 360 denemede başarısız oldu. Ardından, tüm hesaplarda başarısız olan tüm deneme sayısı bir gün içinde bu sayıyı aşarsa (veya daha da iyisi, hesaplanan eşik üzerindeki hızlanma ve tetikleme oranını izleyin), sistem genelinde oturum açma kısayolunu etkinleştirir - bu da TÜM kullanıcılar için kısa gecikmeler anlamına gelir (hala, çerez girişleri ve / veya yedek CAPTCHA girişleri hariç).
Ayrıca bir soru gönderdim daha fazla ayrıntı ve zorlu pitfilerin nasıl önleneceğine dair gerçekten iyi bir tartışma dağıtılmış kaba kuvvet saldırılarını savuşturmak
BÖLÜM VIII: İki Faktörlü Kimlik Doğrulama ve Kimlik Doğrulama Sağlayıcıları
İstisnalar, parolaların yazılması ve kaybolması, anahtarların çalınmasıyla dizüstü bilgisayarlar veya kimlik avı yapan kişilerin kimlik avı sitelerine girmesiyle kimlik bilgileri ele geçirilebilir. 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 da korunabilir. Birkaç sağlayıcı, iki faktörlü kimlik doğrulama hizmetleri sunmaktadır.
Kimlik doğrulaması, başka bir hizmet sağlayıcının kimlik bilgilerini topladığı bir tek oturum açma hizmetine tamamen verilebilir. Bu, sorunu güvenilir bir üçüncü tarafa iter. Google ve Twitter hem standartlara dayalı SSO hizmetleri sağlarken, Facebook benzer bir tescilli çözüm sunar.
Web Kimlik Doğrulama Hakkında LÜTFEN OKUYUN
- Kimlik Doğrulama için OWASP Rehberi / OWASP Kimlik Doğrulama Hile Sayfası
- Web'de İstemci Kimlik Doğrulaması Yapma ve Yapma (çok okunabilir MIT araştırma raporu)
- Wikipedia: HTTP çerezi
- Geri dönüş kimlik doğrulaması için kişisel bilgi soruları: Facebook çağında güvenlik soruları (çok okunabilir Berkeley araştırma raporu)
Kesin Makale
Gönderme bilgileri
Kimlik bilgilerini% 100 güvenli bir şekilde göndermenin tek pratik yolu kullanmaktır. SSL. Şifreyi almak için JavaScript'i kullanmak güvenli değildir. İstemci tarafı şifre karmaşası için yaygın tuzaklar:
- İstemci ve sunucu arasındaki bağlantı şifrelenmemişse, yaptığınız her şey ortadaki adam saldırılarına karşı savunmasız. Saldırgan, gelen javascript'i karmaşayı kırmak veya sunucuya tüm kimlik bilgilerini göndermek için değiştirebilir, istemci yanıtlarını dinleyebilir ve kullanıcıları mükemmel bir şekilde taklit edebilir. Vb. Güvenilir Sertifika Yetkilileri ile SSL, MitM saldırılarını önlemek için tasarlanmıştır.
- Sunucu tarafından alınan karma şifre daha az güvenli ek yapmazsanız, sunucuda gereksiz çalışma.
Başka bir güvenli yöntem var SRPama patentli olsa da serbest lisanslı) ve birkaç iyi uygulama vardır.
Şifreleri saklamak
Şifreleri veritabanında hiç düz metin olarak saklamayın. Kendi sitenizin güvenliğini umursanız bile değil. Bazı kullanıcılarınızın çevrimiçi banka hesabının şifresini yeniden kullanacağını varsayalım. Bu yüzden, karma şifreyi saklayın ve orijinali atın. Ve erişim günlüklerinde veya uygulama günlüklerinde şifrenin görünmediğinden emin olun. OWASP Argon2 kullanımını önerir yeni uygulamalar için ilk tercihiniz olarak. Bu mümkün değilse, PBKDF2 veya scrypt yerine kullanılmalıdır. Son olarak, yukarıdakilerin hiçbiri mevcut değilse, bcrypt kullanın.
Kuşkular kendileri de güvensizdir. Örneğin, aynı şifreler aynı kareler anlamına gelir - bu, karma arama tablolarını aynı anda çok sayıda şifreyi kırmanın etkili bir yoludur. Bunun yerine, tuzlu karması. Tuz, hashmadan önce şifreye eklenen bir dizedir - kullanıcı başına farklı (rastgele) bir tuz kullanın. Tuz genel bir değerdir, bu yüzden bunları veritabanındaki karma ile saklayabilirsiniz. Görmek İşte Bunun için daha fazlası için.
Bu, kullanıcıya unutulmuş şifrelerini gönderemediğiniz anlamına gelir (çünkü sadece karmaşınız olur). Kullanıcının kimliğini doğrulamıyorsanız, kullanıcının şifresini sıfırlamayın (kullanıcıların kayıtlı (ve onaylanmış) e-posta adresine gönderilen e-postaları okuyabileceklerini kanıtlamaları gerekir.)
Güvenlik SORULARI
Güvenlik soruları güvensiz - bunları kullanmaktan kaçının. Niye ya? Bir güvenlik sorusu olursa, bir şifre daha iyi olur. okumak BÖLÜM III: Gizli Soruları Kullanma içinde @Jens Roland cevap Bu wiki'de.
Oturum çerezleri
Kullanıcı giriş yaptıktan sonra sunucu kullanıcıya bir oturum çerezi gönderir. Sunucu, kullanıcı adını veya kimliğini çerezden alabilir, ancak hiç kimse böyle bir çerez oluşturamaz (TODO açıkla mekanizmaları).
Çerezler kaçırılabilir: Onlar sadece müşterinin makinesi ve diğer iletişimin geri kalanı kadar güvenlidir. Diskten okunabilirler, ağ trafiğinde koklanırlar, çapraz-site betik saldırısı ile kaldırılırlar, zehirli bir DNS'den cilalanırlar, böylece istemci çerezlerini yanlış sunuculara gönderir. Kalıcı çerezleri yollama. Çerezler, müşteri oturumunun sonunda sona erer (tarayıcı kapanır veya alanınızı bırakır).
Kullanıcılarınızı otomatik olarak yazmak istiyorsanız, kalıcı bir çerez ayarlayabilirsiniz, ancak tam oturum çerezinden farklı olmalıdır. Kullanıcının otomatik olarak giriş yaptığı ek bir bayrak ayarlayabilir ve hassas işlemler için gerçek olarak giriş yapmanız gerekir. Bu, size kesintisiz, kişiselleştirilmiş bir alışveriş deneyimi sunmak isteyen ancak yine de finansal bilgilerinizi koruyan alışveriş siteleriyle popülerdir. Örneğin, Amazon'u ziyaret etmeye döndüğünüzde, giriş yaptığınız gibi görünen bir sayfa gösterir, ancak bir sipariş verdiğinizde (veya gönderim adresinizi, kredi kartınızı vb. Değiştirdiğinizde) sizden onayınızı istersiniz. şifreniz.
Ö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.
Dış kaynakların listesi
Sadece iyi çalıştığımı bulduğum bu çözümü paylaşacağımı düşündüm.
Ben buna derim Kukla alan (icat etmedim, o yüzden bana itibar etmeyin).
Kısacası: bunu sadece sizin
<form> ve doğrulama sırasında boş olması için kontrol edin:
<input type="text" name="email" style="display:none" />
Hile, bir alanı, gerekli bir alana yerleştirmek zorunda olduğunu düşünmek için bir botu kandırmaktır, bu yüzden "e-posta" girdisini seçtim. Kullandığınız e-posta adı verilen bir alanınız varsa, "alan", "telefon" veya "e-posta adresi" gibi başka bir şeyi adlandırmayı deneyin. İhtiyacınız olmadığını bildiğiniz bir şeyi seçin ve insanların normalde bir web formuna doldurmak için mantıklı bulacağı bir şey gibi görünüyor. Şimdi saklan
input CSS veya JavaScript / jQuery kullanarak alan - size en uygun olanı seçin - sadece yapamaz girişi ayarla
type için
hidden ya da bot bunun için düşmeyecek.
Formu doğruladığınızda (istemci veya sunucu tarafı) kukla alanınızın bir insan veya bot tarafından gönderilip gönderilmediğini belirlemek için doldurulmuş olup olmadığını kontrol edin.
Örnek:
Bir insan durumunda:
Kullanıcı kukla alanını görmez (benim durumumda "e-posta" olarak anılacaktır) ve onu doldurmaya çalışmaz. Böylece, form gönderildiğinde kukla alanın değeri hala boş olmalıdır.
Bir bot durumunda: Bot türü tipinde bir alan görecek
text ve bir isim
email (ya da her ne iseniz) ve mantıklı olarak uygun verilerle doldurmaya çalışın. Giriş formunu hoş bir CSS ile şekillendirdiyseniz, web geliştiricileri bunu her zaman yapar. Kukla alandaki değer ne olursa olsun, daha büyük olduğu sürece
0 karakter.
Bu yöntemi bir konuk defterinde birlikte kullanıyorum. CAPTCHAve o zamandan beri tek bir spam mesaj görmedim. Daha önce bir CAPTCHA çözümü kullandım, ancak sonuçta her saat yaklaşık beş spam postayla sonuçlandı. Kukla alanın formda eklenmesi, tüm spamlerin görünmesini durdurdu (en azından şimdiye kadar).
Bunun bir giriş / kimlik doğrulama formuyla da iyi bir şekilde kullanılabileceğine inanıyorum.
Uyarı: Tabii ki bu yöntem% 100 aptal kanıtı değildir. Bots, stil ile giriş alanlarını yok saymak için programlanabilir
display:none ona uygulandı. Ayrıca, tüm form alanlarını otomatik olarak doldurmak için otomatik olarak tamamlama (çoğu tarayıcının yerleşik olduğu gibi!) Kullanan kişiler hakkında düşünmeniz gerekir. Kukla bir alan açabilirler.
Ayrıca kukla alanını ekranın dışarısı dışında görünmesine rağmen bunu biraz değiştirebilirsin, ama bu tamamen size kalmış.
Yaratıcı ol!
Yukarıdaki cevabın "yanlış" olduğunu düşünmüyorum, fakat üzerinde durulmayan geniş kapsamlı kimlik alanları var (ya da "çerez oturumlarının nasıl uygulanacağı" üzerinde duruluyor, "hangi seçeneklerin mevcut olduğu ve ne olduğu off".
Önerilen düzenlemelerim / cevaplarım
- Sorun, hesap kurulumunda şifre kontrolünden daha fazladır.
- İki faktörlü outhenitication kullanımı daha akıllı şifreli şifreleme araçlarından çok daha güvenlidir.
-
Kendi giriş formunuzu veya şifrelerinizi veritabanı depolamayı denemeyin.
Saklanan veriler hesap oluşturmada ve kendi oluşturulmasında değer taşır (yani, Facebook gibi web 2.0 stili, Flickr, vb.)
- Özet Kimlik Doğrulama, tüm ana tarayıcılarda ve sunucularda desteklenen, güvenli bir kanal üzerinden bile şifre göndermeyen standartlara dayalı bir yaklaşımdır.
Bu, tarayıcının kendisi her seferinde iletişimi yeniden şifreleyeceği için "oturumlar" veya çerezlere sahip olma gereksinimini ortadan kaldırır. En “hafif” gelişme yaklaşımıdır.
Bununla birlikte, kamu, düşük değerli hizmetler hariç, bunu önermiyorum. Bu, yukarıdaki diğer cevaplardan bazılarıyla ilgili bir sorundur - sunucu tarafı kimlik doğrulama mekanizmalarını yeniden uygulamayın - bu sorun çözülmüş ve çoğu ana tarayıcı tarafından desteklenmiştir. Çerez kullanmayın. Kendi elinizdeki veritabanında hiçbir şey saklamayın. İsteğin onaylanması durumunda, istek başına sor. Her şey yapılandırma ve üçüncü taraf güvenilir yazılım tarafından desteklenmelidir.
Yani ...
İlk olarak, bir hesabın ilk oluşturulmasını (bir şifre ile) karıştırıyoruz
Şifrenin daha sonra tekrar kontrol edilmesi. Flickr'im ve sitenizi ilk kez oluşturuyorsam, yeni kullanıcının sıfır değere (boş web alanı) erişimi vardır. Hesabı oluşturan kişinin isimleri hakkında yalan söylemesi gerçekten umrumda değil. Hastane intraneti / extranetinin bir hesabını oluşturuyorsam, değer tüm tıbbi kayıtlarda yatıyor ve ben de yap Hesap oluşturucunun kimliğine (*) dikkat edin.
Bu çok zor kısmı. bir tek İyi çözüm, bir güven ağıdır. Örneğin, hastaneye bir doktor olarak katılıyorsunuz. Fotoğrafınızla, pasaport numaranızla ve bir genel anahtarla bir yere yerleştirilmiş bir web sayfası oluşturursunuz ve hepsini özel anahtarla birleştirirsiniz. Ardından hastaneyi ziyaret edersiniz ve sistem yöneticisi pasaportunuza bakar, fotoğrafın size uyup uymadığını görür ve web sayfası / fotoğraf hashisini hastane özel anahtarı ile birleştirir. Artık anahtar ve jetonları güvenli bir şekilde değiştirebiliyoruz. Hastaneye güvenen herkesin yaptığı gibi (BTW gizli sos var). Sistem yöneticisi ayrıca size bir RSA dongle veya diğer iki faktörlü kimlik doğrulama.
Ama bu bir çok güçlük ve çok web 2.0 değil. Bununla birlikte, kendi kendine yaratılmayan değerli bilgilere erişimi olan yeni hesaplar oluşturmanın tek güvenli yoludur.
-
Kerberos ve SPNEGO - güvenilir bir üçüncü tarafa sahip mekanizmaların tek işareti - temelde kullanıcı güvenilir bir üçüncü tarafa karşı doğrular. (Bu herhangi bir şekilde güvenilir olmamakla birlikte OAuth)
-
SRP - Güvenilir bir üçüncü taraf olmadan akıllı şifre kimlik doğrulaması. Ama burada "bu daha maliyetli olsa bile, iki faktörlü kimlik doğrulama kullanmak daha güvenli" alanlarına giriyoruz
-
SSL İstemci tarafı - istemcilere bir genel anahtar sertifikası verin (tüm önemli tarayıcılarda destek - ancak istemci makine güvenliği ile ilgili soruları artırır).
Sonuçta bu bir zorunluluk - güvenlik ihlalinin maliyeti ve daha güvenli yaklaşımların uygulanmasının maliyeti. Bir gün, uygun görebiliriz PKI Yaygın olarak kabul edilmiş ve böylece kendi kimlik doğrulama formları ve veritabanları yok. Bir gün...