Web siteleri için form tabanlı kimlik doğrulama

Stack Overflow'un sadece çok spesifik teknik sorular için değil, aynı zamanda yaygın problemlerdeki varyasyonların nasıl çözüleceğine dair genel yönergeler için bir kaynak olması gerektiğine inanıyoruz. "Web siteleri için form tabanlı kimlik doğrulaması" böyle bir deneme için iyi bir konu olmalıdır.

Aşağıdaki gibi konuları içermelidir:

• Nasıl giriş yapılır
• Çıkış nasıl yapılır
• Oturumunuz nasıl açık kalır?
• Çerezleri yönetme (önerilen ayarlar dahil)
• SSL / HTTPS şifrelemesi
• Parolalar nasıl saklanır?
• Gizli soruları kullanma
• Unutulan kullanıcı adı / şifre işlevselliği
• Siteler arası istek sahtekarlıklarını (CSRF) önlemek için nonces kullanımı
• OpenID
• "Beni hatırla" onay kutusu
• Kullanıcı adlarının ve şifrelerin tarayıcı otomatik tamamlanması
• Gizli URL'ler (genel URL , özet tarafından korunur)
• Şifre gücünü kontrol etme
• E-posta doğrulaması
• ve form tabanlı kimlik doğrulama hakkında çok daha fazlası ...

Aşağıdaki gibi şeyleri içermemelidir:

• Roller ve yetkilendirme
• HTTP temel kimlik doğrulaması

Lütfen bize yardım edin:

1. Alt konular önerme
2. Bu konuda iyi makaleler gönderme
3. Resmi yanıtı düzenleme

BÖLÜM I: Nasıl Giriş Yapılır

Kimlik doğrulaması için değerleri sunucu tarafındaki bir komut dosyasına POST yapan bir oturum açma + şifre HTML formunun nasıl oluşturulacağını bildiğinizi varsayacağız. Aşağıdaki bölümlerde sağlam pratik kimlik doğrulama kalıpları ve en yaygın güvenlik tuzaklarından nasıl kaçınılacağı ele alınacaktır.

HTTPS'ye mi, HTTPS'ye mi?

Bağlantı zaten güvenli değilse (yani, SSL / TLS kullanarak HTTPS aracılığıyla tünellenmişse), giriş formu değerleriniz açık metin olarak gönderilir; vasıtasıyla. Bu tür telefon dinleme, hükümetler tarafından rutin olarak yapılır, ancak genel olarak, şunu söylemek dışında 'sahip olunan' kablolara değinmeyiz: Sadece HTTPS kullanın.

Aslında, 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 ) veya kanıtlanmış ve test edilmiş bir meydan okuma tepki şeması (örneğin, Diffie-Hellman) kullanmaktır. tabanlı SRP). Başka herhangi bir yöntem, gizli dinleme yapan bir saldırgan tarafından kolayca atlatılabilir .

Elbette, biraz pratik olmamaya istekliyseniz, bir tür iki faktörlü kimlik doğrulama şeması da kullanabilirsiniz (örneğin, Google Şifrematik uygulaması, fiziksel bir 'soğuk savaş tarzı' kod çizelgesi veya bir RSA anahtar üreteci dongle'ı). Doğru şekilde uygulanırsa, güvenli olmayan bir bağlantıda bile işe yarayabilir, ancak bir geliştiricinin SSL'yi değil iki faktörlü kimlik doğrulaması yapmaya istekli olacağını hayal etmek zordur.

(Yapmayın) Kendi JavaScript şifrelemenizi / özetlemenizi hazırlayın

Web sitenizde bir SSL sertifikası oluşturmanın algılanan (şimdi önlenebilir olsa da ) maliyeti ve teknik zorluğu göz önüne alındığında , bazı geliştiriciler güvenli olmayan bir tel üzerinden açık metin girişlerini geçmemek için kendi tarayıcı içi karma veya şifreleme şemalarını kullanmaya eğilimlidir.

Bu asil bir düşünce olsa da , yukarıdakilerden biriyle birleştirilmedikçe esasen işe yaramaz (ve bir güvenlik kusuru olabilir ) - yani, hattı güçlü şifrelemeyle sabitlemek veya denenmiş ve test edilmiş bir meydan okuma yanıtı kullanmak mekanizma (bunun ne olduğunu bilmiyorsanız, kanıtlanması en zor olanı, tasarımı en zor olanı ve kavramları dijital güvenlikte uygulaması en zorlarından biri olduğunu bilin).

Parolayı karma işleminin parola ifşa edilmesine karşı etkili olabileceği doğru olsa da, saldırıları, Ortadaki Adam saldırılarını / kaçırmalarını tekrar savunmasızdır (bir saldırgan güvenli olmayan HTML sayfanıza ulaşmadan önce birkaç bayt enjekte edebilirse) tarayıcıda basitçe JavaScript'teki karma işlemi yorumlayabilir) veya kaba kuvvet saldırıları (saldırgana hem kullanıcı adını, hem tuz, hem de karma şifreyi verdiğiniz için).

İnsanlığa karşı CAPTCHAS

CAPTCHA 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 yoktur, ancak CAPTCHA gerektirmeyen, özellikle düzgün tasarlanmış sunucu tarafı giriş kısıtlama şemaları gerektirmeyen sorunsuz bir şekilde başa çıkmanın yolları vardır - bunları daha sonra tartışacağız.

CAPTCHA uygulamalarının benzer şekilde yaratılmadığını bilin; genellikle insan tarafından çözülemezler, çoğu botlara karşı etkisizdir, hepsi ucuz üçüncü dünya emeğine karşı etkisizdir ( OWASP'a göre , mevcut sweathop oranı 500 test başına 12 $) ve bazı uygulamalar olabilir bazı ülkelerde teknik olarak yasa dışıdır (bkz. OWASP Kimlik Doğrulama Cheat Sheet ). Bir CAPTCHA kullanmanız gerekiyorsa, tanım gereği OCR açısından zor olduğundan (zaten OCR ile yanlış sınıflandırılmış kitap taramaları kullandığından) ve kullanıcı dostu olması çok zor olduğu için Google'ın reCAPTCHA'sını kullanın .

Şahsen, CAPTCHAS'ı sinir bozucu bulma eğilimindeyim ve bunları yalnızca bir kullanıcı birkaç kez giriş yapamadığında ve azaltma gecikmeleri en üst düzeye çıktığında son çare olarak kullanıyorum. Bu, kabul edilebilir olmak için nadiren yeterli olur ve sistemi bir bütün olarak güçlendirir.

Parolaları Saklama / Oturum açma bilgilerini doğrulama

Son olarak, son yıllarda yaygın olarak gördüğümüz tüm yaygın hack'lerden ve kullanıcı veri sızıntılarından sonra bu yaygın bir bilgi olabilir, ancak söylenmesi gerekir: Parolaları veritabanınızda açık metin olarak saklamayın. Kullanıcı veritabanları SQL enjeksiyonu yoluyla rutin olarak hacklenir, sızdırılır veya toplanır ve ham, düz metin şifreleri saklıyorsanız, giriş güvenliğiniz için anında oyun biter.

Şifreyi saklayamıyorsanız, giriş formundan POSTed olan login + şifre kombinasyonunun doğru olup olmadığını nasıl kontrol edersiniz? Cevap, bir anahtar türetme işlevi kullanılarak özetlenmektedir . Yeni bir kullanıcı oluşturulduğunda veya bir şifre değiştirildiğinde, şifreyi alıp Argon2, bcrypt, scrypt veya PBKDF2 gibi bir KDF aracılığıyla çalıştırırsınız ve açık metin şifresini ("doğruhorsebatterystaple") uzun, rastgele görünümlü bir dizeye dönüştürürsünüz , veritabanınızda saklamak çok daha güvenli. Bir girişi doğrulamak için, girilen parola üzerinde aynı karma işlevini çalıştırırsınız, bu sefer tuzdan geçer ve elde edilen karma dizesini veritabanınızda depolanan değerle karşılaştırırsınız. 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 nedeni, kendi içinde karmalamanın yeterli olmamasıdır - hash'i gökkuşağı tablolarına karşı korumak için 'tuz' eklemek isteyeceksiniz . Bir tuz etkili bir şekilde eşleşen iki parolanın aynı karma değer olarak depolanmasını önler ve bir saldırgan bir parola tahmin saldırısı yürütüyorsa tüm veritabanının bir seferde taranmasını önler.

Kullanıcı tarafından seçilen şifreler yeterince güçlü olmadığından (yani genellikle yeterli entropi içermediğinden) ve parola tahmin saldırısı, karma değerlere erişimi olan bir saldırgan tarafından nispeten kısa sürede tamamlanabileceğinden, parola depolaması için bir şifreleme karması kullanılmamalıdır. Bu nedenle KDF'ler kullanılır - bunlar etkili bir şekilde "anahtarı uzatır" , yani bir saldırganın yaptığı her parola, karma algoritmanın örneğin 10.000 kez birden çok kez tekrarlanmasına neden olur ve 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ı veritabanınıza karşı oturum açma adı ve parolayı doğruladıktan ve bir eşleşme bulduğunda, sistem tarayıcının kimliğinin doğrulandığını hatırlamanın bir yoluna ihtiyaç duyar. Bu gerçek, yalnızca sunucu tarafında oturum verilerinde saklanmalıdır.

Oturum verilerine aşina değilseniz, şu şekilde çalışır: Rastgele oluşturulmuş tek bir dize, süresi dolan bir çerezde saklanır ve sunucuda depolanan bir veri koleksiyonuna (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 çerezinde tarayıcıya gönderildiğinde güvenli ve Yalnızca HTTP bayraklarının ayarlandığından emin olun. HttpOnly bayrağı, XSS saldırısı yoluyla okunan çerezlere karşı bir miktar koruma sağlar. Güvenli bayrak, çerezin yalnızca HTTPS yoluyla geri gönderilmesini sağlar ve bu nedenle ağ koklama saldırılarına karşı korur. Çerezin değeri öngörülebilir olmamalıdır. Var olmayan bir oturuma referans veren bir çerez sunulduğunda, oturumun sabitlenmesini önlemek için değeri derhal değiştirilmelidir .

BÖLÜM II: Oturum Açılmış Nasıl Kalınır - Rezil "Beni Hatırla" Onay Kutusu

Kalıcı Oturum Açma Çerezleri ("beni hatırla" işlevselliği) bir tehlike bölgesidir; bir yandan, kullanıcılar bunları nasıl kullanacaklarını anladıklarında tamamen geleneksel girişler kadar güvenlidirler; diğer yandan, dikkatsiz kullanıcıların ellerinde, herkese açık bilgisayarlarda kullanabilen ve oturumu kapatmayı unutabilen ve tarayıcı çerezlerinin ne olduğunu veya nasıl silineceğini bilmeyen çok büyük bir güvenlik riskidir.

Şahsen, düzenli olarak ziyaret ettiğim web siteleri için kalıcı girişleri severim, ancak bunları nasıl güvenli bir şekilde kullanacağımı biliyorum. Kullanıcılarınızın aynı şeyi bildiğinden eminseniz, temiz bir vicdanla kalıcı girişler kullanabilirsiniz. Değilse - iyi, o zaman giriş kimlik bilgileriyle dikkatsiz olan kullanıcıların hacklendiklerinde kendilerine getirdikleri felsefesine abone olabilirsiniz. Kullanıcılarımızın evlerine gidip, monitörlerinin kenarında sıraladıkları parolalarla facepalm indükleyen tüm Post-It notlarını koparmak gibi bir şey değil.

Elbette, bazı sistemler herhangi bir hesabın saldırıya uğramasını göze alamaz ; bu tür sistemler için, kalıcı giriş bilgilerine sahip olmanın haklı bir yolu yoktur.

Kalıcı giriş çerezleri uygulamaya karar verirseniz, bunu şu şekilde yapabilirsiniz:

1. İlk olarak, Paragon Girişimi'nin konuyla ilgili makalesini okumak için biraz zaman ayırın . Bir grup öğeyi doğru almanız gerekir ve makale her birini açıklamak için harika bir iş çıkarır.

2. Ve sadece en yaygın tuzaklardan birini tekrarlamak için , SADECE BİR ŞEY, SİZİN VERİTABANIZDA, SÜREKLİ GİRİŞ ÇEREZİ (TOKEN) KOYMAYIN! Giriş jetonu Parola Eşdeğeridir, bu nedenle bir saldırgan veritabanınıza ellerini sokarsa, açık metin giriş parolası kombinasyonlarıymış gibi herhangi bir hesaba giriş yapmak için jetonları kullanabilir. Bu nedenle, kalıcı giriş jetonlarını saklarken karma ( https://security.stackexchange.com/a/63438/5002 uyarınca zayıf bir karma bu amaç için iyi olacaktır) kullanın.

BÖLÜM III: Gizli Soruları Kullanma

'Gizli sorular' uygulamayın . 'Gizli sorular' özelliği bir güvenlik karşıtı modeldir. MUST-READ listesinden 4 numaralı bağlantıdan makaleyi okuyun. Sarah Palin'den Yahoo! güvenlik sorusunun cevabı "Wasilla Lisesi" olduğu için bir önceki başkanlık kampanyası sırasında e-posta hesabı saldırıya uğradı!

Kullanıcı tarafından belirtilen sorularla bile, çoğu kullanıcının aşağıdakilerden birini seçmesi büyük olasılıkla:

• Annenin kızlık soyadı veya favori evcil hayvanı gibi 'standart' gizli bir soru

• Herkesin blogundan, LinkedIn profilinden veya benzerlerinden kaldırabileceği basit bir trivia parçası

• Cevap vermesi daha kolay olan soruları şifrelerini tahmin etmekten daha kolaydır. Hangi, herhangi bir iyi şifre için, hayal edebileceğiniz her soru

Sonuç olarak, güvenlik soruları neredeyse tüm biçimleri ve varyasyonlarında doğal olarak güvensizdir ve herhangi bir nedenle bir kimlik doğrulama şemasında kullanılmamalıdır.

Güvenlik sorularının vahşi doğada bile var olmasının gerçek nedeni, bir yeniden etkinleştirme koduna ulaşmak için e-postalarına erişemeyen kullanıcıların birkaç destek çağrısının maliyetini uygun bir şekilde kaydetmeleridir. Bu güvenlik ve Sarah Palin'in itibarı pahasına. Buna değer? Muhtemelen değil.

BÖLÜM IV: Unutulan Parola İşlevselliği

Unutulan / kaybolan kullanıcı şifrelerini işlemek için neden güvenlik sorularını asla kullanmamanız gerektiğinden bahsetmiştim ; kullanıcılara gerçek şifrelerini asla e-posta ile göndermemeniz gerektiğini de söylemeye gerek yok. Bu alanda kaçınılması gereken en az iki ortak tuzak daha vardır:

1. 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 hemen yeni bir şifre seçmesine izin verin - bu zaten yapmak istedikleri şeydir. (Bunun bir istisnası, kullanıcılar, normalde bir yere yazmadan hatırlanması imkansız olan şifreleri saklamak / yönetmek için evrensel olarak bir şifre yöneticisi kullanıyorsa olabilir).

2. Her zaman veritabanında kayıp parola kodunu / jetonunu karma yapın. TEKRAR , bu kod bir Parola Eşdeğeri başka bir örneğidir, bu nedenle bir saldırganın veritabanınıza ellerini alması durumunda karma olmalı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 veritabanını kaydedin - ve orijinali atın . Tıpkı bir şifre veya kalıcı bir giriş jetonu gibi.

Son bir not: 'kayıp şifre kodunu' girme arayüzünüzün her zaman giriş formunuzun kendisi kadar güvenli olduğundan emin olun, yoksa bir saldırgan bunun yerine erişim elde etmek için bunu kullanır. Çok uzun 'kayıp parola kodları' oluşturduğunuzdan emin olmak (örneğin, büyük / küçük harf duyarlı 16 alfasayısal karakter) 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 Edilmesi

İlk olarak, 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 şifrelerin kanonik listesi değildir , ancak yürürlükteki bir politika olmadığında insanların şifrelerini ne kadar kötü seçeceklerinin iyi bir göstergesidir. Ayrıca, son ç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 şifre gücü gereksinimi olmadan, kullanıcıların% 2'si en yaygın 20 şifreden birini kullanır. Anlamı: Eğer bir saldırgan sadece 20 deneme yaparsa, web sitenizdeki 50 hesaptan 1'i kırılabilir.

Bunun önlenmesi için bir parolanın entropisinin hesaplanması ve ardından bir eşiğin uygulanması gerekir. Ulusal Standartlar ve Teknoloji Enstitüsü (NIST) Özel Yayını 800-63 bir dizi çok iyi öneriye sahiptir. 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 parolaların% 99'unu entropi 18 bit düzeyinde reddedebilir . Sadece şifre gücünü hesaplamak ve bir kullanıcıya bir görsel güç ölçer göstermek iyi, ancak yetersizdir. Zorla uygulanmadığı sürece, birçok kullanıcı büyük olasılıkla görmezden gelecektir.

Ve yüksek entropili şifrelerin kullanıcı dostu olması için Randall Munroe'nin Şifre Gücü xkcd önerilir.

Genel veri ihlallerinde tehlikeye giren parolalara karşı kullanıcıların şifrelerini kontrol etmek için Troy Hunt'ın Pwned API'sini kullanın.

VI. BÖLÜM: Çok Daha Fazlası - Veya: Hızlı Yangın Giriş Denemelerini Önleme

İlk olarak, sayılara bir göz atın: Şifre Kurtarma Hızları - Şifreniz ne kadar süre dayanacaktır

Bu bağlantıdaki tablolara bakacak vaktiniz yoksa, işte bunların listesi:

1. Bu sürer neredeyse hiçbir zaman bir abaküs ile çatlama olsanız bile, zayıf bir parolayı çözmek

2. Büyük / küçük harf duyarlı değilse, alfasayısal 9 karakterlik bir parolayı kırmak neredeyse hiç zaman almaz

3. 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ün ve hatta saat)

4. Bununla birlikte, saniyede bir deneme ile sınırlı olsaydınız , 6 karakterlik bir şifreyi bile kırmak çok uzun sürecektir !

Peki bu rakamlardan ne öğrenebiliriz? Çok, ama en önemli bölüme odaklanabiliriz: Çok sayıda hızlı ateş ardışık giriş denemesini (yani kaba kuvvet saldırısı) önlemenin o kadar da zor olmadığı gerçeği. Ancak doğru bir şekilde önlenmesi göründüğü kadar kolay değildir.

Genel olarak konuşursak, hepsi kaba kuvvet saldırılarına karşı etkili üç seçeneğiniz var (ve sözlük saldırıları, ancak zaten güçlü bir şifre politikası kullandığınız için, bunlar bir sorun olmamalı) :

• N başarısız denemeden sonra bir CAPTCHA sunun (cehennem gibi can sıkıcı ve genellikle etkisiz - ama kendimi burada tekrarlıyorum)

• N başarısız denemeden sonra hesapları kilitleme ve e-posta doğrulaması gerektirme (bu, gerçekleşmeyi bekleyen bir DoS saldırısıdır)

• Ve son olarak, giriş kısıtlaması : yani, N başarısız girişimden sonra girişimler arasında bir zaman gecikmesi ayarlamak (evet, DoS saldırıları hala mümkündür, ancak en azından onlar daha az olasıdır ve çekilmesi çok daha karmaşıktır).

En iyi uygulama # 1: Başarısız deneme sayısıyla birlikte artan kısa bir gecikme, örneğin:

• 1 başarısız deneme = gecikme yok
• 2 başarısız deneme = 2 sn 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 sn gecikme
• vb.

Ortaya çıkan kilitleme süresi, önceki kilitleme sürelerinin toplamından biraz daha büyük olduğu için, bu şemaya saldıran çok pratik olmayacaktır.

Açıklığa kavuşturmak için: Gecikme, tarayıcıya yanıt döndürülmeden önceki bir gecikme değildir . Daha çok, belirli bir hesaba veya belirli bir IP adresinden giriş girişimlerinin kabul edilmeyeceği veya değerlendirilmeyeceği bir zaman aşımı veya refrakter dönemi gibidir. Diğer bir deyişle, doğru kimlik bilgileri başarılı bir girişte döndürülmez ve yanlış kimlik bilgileri gecikme artışını tetiklemez.

En iyi uygulama # 2: N başarısız denemeden sonra yürürlüğe giren orta uzunlukta bir gecikme, örneğin:

• 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 değildir, 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 belirtmek de uygun olabilir. Unutkan kullanıcılar sizi sevmeyecek.

En iyi uygulama # 3: İki yaklaşımı birleştirmek - N başarısız denemeden sonra yürürlüğe 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 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 uygulama önerilerinden (MUST-READ listesinden bağlantı 1) alınmıştır ve kısıtlayıcı tarafta olsa bile en iyi uygulama olarak kabul edilmelidir.

Bununla birlikte, genel bir kural olarak şunu söyleyebilirim: şifre politikanız ne kadar güçlü olursa, gecikmeleri olan kullanıcıları daha az rahatsız etmeniz gerekir. Güçlü (büyük / küçük harf duyarlı alfanümerikler + gereken sayılar ve semboller) 9+ karakter parolalarına ihtiyacınız varsa, kullanıcılara kısıtlamayı etkinleştirmeden önce 2-4 gecikmeli şifre denemesi yapabilirsiniz.

Bu son giriş kısıtlama düzenine saldıran DoS çok pratik olmaz. Ve son dokunuş olarak, sürekli (çerez) girişlerinin (ve / veya CAPTCHA onaylı bir giriş formunun) geçmesine izin verin, böylece saldırı devam ederken meşru kullanıcılar gecikmez . Bu şekilde, çok pratik olmayan DoS saldırısı son derece pratik olmayan bir saldırı haline gelir .

Buna ek olarak, 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ık Kaba Kuvvet Saldırıları

Tıpkı bir yana, daha gelişmiş saldırganlar 'faaliyetlerini yayarak' giriş kısıtlamasını atlatmaya çalışacaklar:

• IP adresi işaretlemesini önlemek için bir botnet üzerindeki denemeleri dağıtma

• Bir kullanıcıyı seçmek ve en sık kullanılan 50.000 şifreyi denemek yerine (kısıtlama nedeniyle yapamayacakları), en yaygın şifreyi seçecek ve bunun yerine 50.000 kullanıcıya karşı deneyeceklerdir. Bu şekilde, sadece CAPTCHA'lar ve giriş kısıtlaması gibi maksimum deneme önlemleri almakla kalmazlar, aynı zamanda başarı şansları da artar, çünkü 1 numaralı en yaygın şifre 49.995 sayısından çok daha olasıdır.

• Radarın altına gizlice girmek için her bir kullanıcı hesabı için 30 saniye arayla oturum açma isteklerini aralamak

Burada en iyi uygulama , sistem genelinde başarısız oturum açma sayısını günlüğe kaydetmek ve sitenizin kötü giriş sıklığının çalışan bir ortalamasını, daha sonra tüm kullanıcılara uygulayacağınız bir üst sınırın temeli olarak kullanmak olacaktır.

Çok soyut mu? Yeniden ifade edeyim:

Sitenizin son 3 ayda günde ortalama 120 kötü giriş yapmış olduğunu varsayalım. Bunu (çalışan ortalama) kullanarak, sisteminiz küresel sınırı 3 katına ayarlayabilir - yani. 24 saatlik bir süre içinde 360 ​​başarısız girişim. Ardından, tüm hesaplardaki başarısız denemelerin toplam 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 tetikleme), sistem genelinde giriş kısıtlamasını etkinleştirir - yani TÜM kullanıcılar için kısa gecikmeler (yine de, çerez girişleri ve / veya yedek CAPTCHA girişleri hariç).

Ayrıca, daha fazla ayrıntı ve dağıtılmış kaba kuvvet saldırılarını engellemede zor tuzaklardan nasıl kaçınacağımız hakkında gerçekten iyi bir tartışma gönderdim .

BÖLÜM VIII: İki Faktörlü Kimlik Doğrulama ve Kimlik Doğrulama Sağlayıcıları

İstismarlar, parolalar yazılmak ve kaybolmak, anahtarları çalınan dizüstü bilgisayarlar veya kimlik avı sitelerine giriş yapan kullanıcılar olsun, kimlik bilgilerinden ödün verilebilir. Girişler, 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. Birçok sağlayıcı iki faktörlü kimlik doğrulama hizmetleri sunar.

Kimlik doğrulama işlemi, başka bir sağlayıcının toplama kimlik bilgilerini işlediği tek oturum açma hizmetine tamamen devredilebilir. Bu, sorunu güvenilir bir üçüncü tarafa iletir. Google ve Twitter her ikisi de standartlara dayalı TOA hizmetleri sunarken, Facebook benzer bir tescilli çözüm sunar.

ZORUNLU OKUYUN LİNKLER Web Kimlik Doğrulaması Hakkında

1. OWASP Kimlik Doğrulama Kılavuzu / OWASP Kimlik Doğrulama Hile Sayfası
2. Web'de İstemci Kimlik Doğrulaması Yapılması ve Yapılmaması Gerekenler (çok okunabilir MIT araştırma belgesi)
3. Wikipedia: HTTP çerezi
4. Yedek kimlik doğrulaması için kişisel bilgi soruları: Facebook çağındaki güvenlik soruları (çok okunabilir Berkeley araştırma makalesi)

Kesin Makale

Kimlik bilgisi gönderme

Kimlik bilgilerini% 100 güvenli bir şekilde göndermenin tek pratik yolu SSL kullanmaktır . Parolayı karma yapmak için JavaScript kullanmak güvenli değildir. İstemci tarafı parola karması 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ızdır . Saldırgan, hash kırmak veya tüm kimlik bilgilerini sunucularına göndermek için gelen javascript'in yerini alabilir, istemci yanıtlarını dinleyebilir ve kullanıcıları mükemmel bir şekilde taklit edebilir vb. Vb. Güvenilir Sertifika Yetkilileriyle SSL, MitM saldırılarını önlemek için tasarlanmıştır.
• Sunucuda ek, yedekli çalışma yapmazsanız , sunucu tarafından alınan karma parola daha az güvenlidir .

SRP adı verilen başka bir güvenli yöntem var , ancak patentli ( özgürce lisanslanmış olmasına rağmen ) ve çok az iyi uygulama var.

Parolaları saklama

Parolaları hiçbir zaman veritabanında düz metin olarak saklamayın. Kendi sitenizin güvenliğini önemsemeseniz bile. Bazı kullanıcılarınızın çevrimiçi banka hesaplarının şifresini yeniden kullanacağını varsayın. Bu nedenle, karma şifreyi saklayın ve orijinali atın. Ve şifrenin 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 kullanmanızı önerir . 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.

Hashler kendi başlarına da güvensizdir. Örneğin, özdeş şifreler özdeş karmalar anlamına gelir - bu, karma arama tablolarını aynı anda birçok şifreyi kırmanın etkili bir yolu haline getirir. Bunun yerine, tuzlanmış karmayı saklayın . Tuz, karma işleminden önce şifreye eklenen bir dizedir - kullanıcı başına farklı (rastgele) bir tuz kullanın. Tuz genel bir değerdir, bu nedenle bunları veritabanında karma ile saklayabilirsiniz. Bununla ilgili daha fazla bilgi için buraya bakın .

Bu, kullanıcıya unutulmuş şifrelerini gönderemeyeceğiniz anlamına gelir (çünkü sadece karma 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 depolanan (ve onaylanan) e-posta adresine gönderilen e-postaları okuyabileceklerini kanıtlamalıdır.)

Güvenlik SORULARI

Güvenlik soruları güvensizdir - bunları kullanmaktan kaçının. Neden? Bir güvenlik sorusunun yaptığı her şey, bir şifre daha iyi olur. Okuma BÖLÜM III: Gizli Sorular kullanma içinde @Jens Roland cevap burada bu wiki.

Oturum çerezleri

Kullanıcı oturum açtıktan sonra, sunucu kullanıcıya bir oturum çerezi gönderir. Sunucu, çerezden kullanıcı adını veya kimliği alabilir, ancak başka hiç kimse böyle bir çerez oluşturamaz (TODO açıklama mekanizmaları).

Çerezler ele geçirilebilir : sadece müşterinin makinesinin geri kalanı ve diğer iletişimler kadar güvenlidir. Diskten okunabilir, ağ trafiğinde koklanabilir, siteler arası komut dosyası saldırısı ile kaldırılabilir, zehirli bir DNS'den kimlik avı yapılır, böylece istemci çerezlerini yanlış sunuculara gönderir. Kalıcı çerezler göndermeyin. Çerezlerin, istemci oturumunun sonunda süresi dolmalıdır (tarayıcı kapanır veya alan adınızdan ayrılır).

Kullanıcılarınızı otomatik olarak oturum açmak istiyorsanız kalıcı bir çerez ayarlayabilirsiniz ancak tam oturum çerezinden farklı olmalıdır. Kullanıcının otomatik olarak oturum açtığı ve hassas işlemler için gerçek olarak oturum açması gereken ek bir bayrak ayarlayabilirsiniz. Bu, size kesintisiz, kişiselleştirilmiş bir alışveriş deneyimi sunmak, ancak yine de finansal bilgilerinizi korumak isteyen alışveriş siteleri arasında popülerdir. Örneğin, Amazon'u ziyaret ettiğinizde size giriş yapmış gibi görünen bir sayfa gösterir, ancak sipariş verdiğinizde (veya gönderim adresinizi, kredi kartınızı vb.), Onaylamanızı ister şifreniz.

Öte yandan, bankalar ve kredi kartları gibi finansal web siteleri yalnızca hassas verilere sahiptir ve otomatik giriş veya düşük güvenlik moduna izin vermemelidir.

Dış kaynakların listesi

• Web'de İstemci Kimlik Doğrulaması Yapılması ve Yapılmaması Gerekenler (PDF)
  21 sayfalık akademik makale ile ilgili birçok ipucu.
• YC'ye sorun:
  Konu ile ilgili Kullanıcı Doğrulama Forumu tartışması için En İyi Uygulamalar
• Muhtemelen Şifreleri Saklıyorsunuz Şifreleri saklama ile
  ilgili giriş makalesi
• Tartışma: Korku Kodlama: Muhtemelen Şifreleri Yanlış
  Saklıyorsunuz Kodlama Korku makalesi hakkında tartışma.
• Parolaları asla veritabanında saklamayın!
  Parolaların veritabanında depolanmasıyla ilgili bir başka uyarı.
• Şifre kırma
  Çeşitli şifre karma düzenlerinin zayıflıkları hakkında Wikipedia makalesi.
• Gökkuşağı tabloları ile yeterli: Güvenli Şifre Şemaları Hakkında Bilmeniz Gerekenler
  Gökkuşağı tabloları ve bunlara karşı ve diğer iş parçacıklarına karşı nasıl savunulacağı hakkında tartışma. Kapsamlı tartışmalar içerir.

İlk olarak, bu cevabın bu kesin soru için en uygun olmadığı konusunda güçlü bir uyarı. Kesinlikle en iyi cevap olmamalı!

İleride kimlik doğrulamaya daha iyi yaklaşımlar için bir yükseltme yolu bulma ruhu içinde Mozilla'nın önerilen BrowserID'sinden (veya belki de daha doğrusu Doğrulanmış E-posta Protokolünden ) bahsedeceğim .

Bu şekilde özetleyeceğim:

1. Mozilla, bu soruna iyi çözümler bulmaya iyi uyum sağlayan değerlerle kar amacı gütmeyen bir kuruluştur .
2. Bugün gerçek şu ki, çoğu web sitesi form tabanlı kimlik doğrulama kullanıyor
3. Form tabanlı kimlik doğrulamanın büyük bir dezavantajı vardır, bu da kimlik avı riskinin artmasıdır . Kullanıcılardan, Kullanıcı Aracısı (tarayıcı) tarafından kontrol edilen bir alan yerine uzak bir varlık tarafından kontrol edilen bir alana hassas bilgiler girmeleri istenir.
4. Tarayıcılar dolaylı olarak güvenilir olduğundan (bir Kullanıcı Aracısının fikri Kullanıcı adına hareket etmektir), bu durumu iyileştirmeye yardımcı olabilir.
5. Buradaki ilerlemeyi engelleyen birincil güç dağıtım kilitlenmesidir . Çözeltiler, kendi başlarına bir miktar fayda sağlayan basamaklara ayrılmalıdır.
6. İnternet altyapısında yerleşik bir kimliği ifade etmenin en basit merkezi olmayan yöntemi alan adıdır.
7. Kimliğini ifade etmenin ikinci düzeyi olarak, her etki alanı kendi hesap kümesini yönetir.
8. “Hesap @alanı” formu kısa ve geniş bir protokol ve URI şeması yelpazesi ile desteklenir. Böyle bir tanımlayıcı elbette en evrensel olarak bir e-posta adresi olarak tanınır.
9. E-posta sağlayıcıları zaten çevrimiçi fiili birincil kimlik sağlayıcılarıdır. Geçerli şifre sıfırlama akışları, genellikle o hesabın ilişkili e-posta adresini kontrol ettiğinizi kanıtlayabiliyorsanız bir hesabın kontrolünü ele almanıza olanak tanır.
10. Doğrulanmış E-posta Protokolü, A alanında bir hesabınız olduğunu B alan adına kanıtlama sürecini kolaylaştırmak için ortak anahtar şifrelemesine dayalı güvenli bir yöntem sağlaması önerildi.
11. Doğrulanmış E-posta Protokolünü (şu anda hepsi) desteklemeyen tarayıcılar için Mozilla, protokolü istemci tarafı JavaScript kodunda uygulayan bir şim sağlar.
12. Doğrulanmış E-posta Protokolünü desteklemeyen e-posta hizmetleri için, protokol üçüncü tarafların güvenilir bir aracı olarak hareket etmelerine izin vererek kullanıcının bir hesabın sahipliğini doğruladıklarını iddia eder. Çok sayıda üçüncü tarafa sahip olmak arzu edilmez; bu özellik yalnızca bir yükseltme yoluna izin vermek içindir ve e-posta hizmetlerinin bu iddiaları kendileri sağlaması çok tercih edilir.
13. Mozilla, böyle güvenilir bir üçüncü taraf gibi davranmak için kendi hizmetlerini sunar. Doğrulanmış E-posta Protokolünü uygulayan Servis Sağlayıcılar (yani Güvenen Taraflar) Mozilla'nın iddialarına güvenmeyi veya güvenmemeyi seçebilir. Mozilla'nın hizmeti, onay bağlantısına sahip geleneksel bir e-posta gönderme yöntemini kullanarak kullanıcıların hesap sahipliğini doğrular.
14. Servis Sağlayıcılar, elbette, sunmak istedikleri diğer kimlik doğrulama yöntemlerine ek olarak bu protokolü bir seçenek olarak sunabilir.
15. Burada aranan büyük bir kullanıcı arayüzü avantajı “kimlik seçici” dir. Bir kullanıcı bir siteyi ziyaret ettiğinde ve kimlik doğrulaması yapmayı seçtiğinde, tarayıcıları kendilerine siteyi tanımlamak için kullanabilecekleri bir dizi e-posta adresi (“kişisel”, “iş”, “politik aktivizm” vb.) Gösterir.
16. Bu çabanın bir parçası olarak aranan bir başka büyük kullanıcı arayüzü avantajı , tarayıcının kullanıcının oturumu hakkında daha fazla bilgi sahibi olmasına yardımcı olmaktır - şu anda oturum açmış olanlar - bu nedenle tarayıcı kromunda görüntülenebilir.
17. Bu sistemin dağıtılmış doğası nedeniyle, Facebook, Twitter, Google vb. Gibi büyük sitelere kilitlenmeyi önler. Herhangi bir kişi kendi etki alanına sahip olabilir ve bu nedenle kendi kimlik sağlayıcısı olarak hareket edebilir.

Bu kesinlikle “web siteleri için form tabanlı kimlik doğrulaması” değildir. Ancak, mevcut form tabanlı kimlik doğrulama normundan daha güvenli bir şeye geçmek için bir çabadır: tarayıcı destekli kimlik doğrulama.

Sadece iyi çalıştığını bulduğum bu çözümü paylaşacağımı düşündüm.

Buna Dummy Field diyorum (bunu icat etmedim, bu yüzden bana kredi vermeyin).

Kısacası: sadece bunu içine yerleştirmeniz <form>ve onaylarken boş olup olmadığını kontrol etmeniz yeterlidir :

<input type="text" name="email" style="display:none" />

İşin püf noktası, gerekli bir alana veri eklemek zorunda olduğunu düşünmek için bir botu kandırmaktır, bu yüzden girişe "e-posta" adını verdim. Kullandığınız e-posta adı verilen bir alanınız varsa kukla alana "şirket", "telefon" veya "e-posta adresi" gibi bir ad vermeyi denemelisiniz. İhtiyacınız olmadığını bildiğiniz bir şeyi ve insanların normalde bir web formunu doldurmak için mantıklı bulacağı bir şey seçin. Şimdi gizlemek inputsize en uygun ne olursa olsun - - CSS veya JavaScript / jQuery kullanarak alanı sadece yok girişini ayarlamak typeiçin hiddenya da başka bot bunun için düşmez.

Formu doğrularken (istemci veya sunucu tarafı), bir insan veya bot tarafından gönderilip gönderilmediğini belirlemek için kukla alanınızın doldurulup doldurulmadığını kontrol edin.

Misal:

İnsan olması durumunda: Kullanıcı kukla alanı (benim durumumda "e-posta" olarak adlandırılır) görmez ve doldurmaya çalışmaz. Bu nedenle, form gönderildiğinde kukla alanın değeri hala boş olmalıdır.

Bot durumunda: Bot, türü olan bir alan textve adı email(veya adı ne olursa olsun) görür ve mantıksal olarak uygun verilerle doldurmaya çalışır. Giriş formunu süslü bir CSS ile şekillendirmeniz önemli değil, web geliştiricileri bunu her zaman yapıyor. Sahte alandaki değer ne olursa olsun, 0karakterlerden daha büyük olduğu sürece umursamıyoruz .

Bu yöntemi konuk defterinde CAPTCHA ile birlikte kullandım ve o zamandan beri tek bir spam gönderi görmedim. Daha önce yalnızca CAPTCHA'ya özel bir çözüm kullanmıştım, ancak sonunda her saat yaklaşık beş spam yayınıyla sonuçlandı. Formdaki kukla alanın eklenmesi (en azından şimdiye kadar) tüm spam'lerin görünmesini durdurdu.

Bunun bir giriş / kimlik doğrulama formu ile de kullanılabileceğine inanıyorum.

Uyarı : Elbette bu yöntem% 100 kusursuz değildir. Botlar, display:noneuygulanan stil ile giriş alanlarını yoksaymak üzere programlanabilir . Ayrıca, kendileri için tüm form alanlarını otomatik olarak doldurmak için bir tür otomatik tamamlama biçimi (çoğu tarayıcının yerleşik olduğu gibi!) Kullanan kişileri de düşünmelisiniz. Kukla bir alan da alabilirler.

Ayrıca, kukla alanı görünür halde bırakarak ekranın sınırları dışında bırakarak biraz değiştirebilirsiniz, ancak bu tamamen size bağlıdır.

Yaratıcı ol!

Yukarıdaki cevabın "yanlış" olduğunu düşünmüyorum, ancak dokunulmayan geniş kimlik doğrulama alanları var (ya da daha çok vurgu, "hangi seçeneklerin mevcut olduğu ve ticaretin ne olduğu" değil, "çerez oturumlarının nasıl uygulanacağı" -offs".

Önerilen düzenlemelerim / yanıtlarım

• Sorun, hesap kurulumunda şifre kontrolünden daha fazladır.
• İki faktörlü kimlik doğrulamanın kullanımı, daha akıllı parola şifreleme yöntemlerinden çok daha güvenlidir

• Saklanan veriler hesap oluşturmada değersiz ve kendi kendine oluşturulmuş (yani Facebook, Flickr , vb.

  1. Özet Kimlik Doğrulama, tüm büyük 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ğinden, "oturumlar" veya çerezler gerektirmez. En "hafif" geliştirme yaklaşımıdır.

Ancak, halka açık, düşük değerli hizmetler dışında bunu önermiyorum. Bu, yukarıdaki diğer cevapların bazılarıyla ilgili bir sorundur - sunucu tarafı kimlik doğrulama mekanizmalarını yeniden uygulamayı denemeyin - bu sorun çözülmüştür ve çoğu büyük tarayıcı tarafından desteklenmektedir. Çerez kullanmayın. Kendi elle toplanan veritabanınızda hiçbir şey saklamayın. İstek başına, isteğin doğrulanıp doğrulanmadığını sorun. Diğer her şey yapılandırma ve üçüncü tarafların güvendiği yazılımlarla desteklenmelidir.

Yani ...

İlk olarak, bir hesabın ilk oluşturulmasını (bir şifre ile) daha sonra şifreyi tekrar kontrol etmekle karıştırıyoruz. Flickr'ım ve sitenizi ilk kez oluşturuyorsanız, yeni kullanıcının sıfır değerine (boş web alanı) erişimi olur. Hesabı oluşturan kişinin ismiyle ilgili yalan söyleyip söylememesi gerçekten umrumda değil. Hastaneye intranet / extranet bir hesap oluşturma, tüm tıbbi kayıtlarda değer yatıyor ve bunu yapmak hesap yaratıcısının kimliği (*) umurumda.

Bu çok zor olan kısım. Sadece iyi çözüm güven ağıdır. Örneğin hastaneye doktor olarak katılıyorsunuz. Fotoğrafınızla, pasaport numaranızla ve genel anahtarınızla bir yerde barındırılan bir web sayfası oluşturursunuz ve hepsini özel anahtarla hash edersiniz. Daha sonra hastaneyi ziyaret edersiniz ve sistem yöneticisi pasaportunuza bakar, fotoğrafın sizinle eşleşip eşleşmediğini görür ve ardından web sayfasını / fotoğraf karmasını hastane özel anahtarıyla karıştırır. Artık anahtarları ve tokenleri güvenli bir şekilde değiştirebiliriz. Hastane güvenen herkes gibi (orada gizli sos BTW). Sistem yöneticisi size bir RSA dongle'ı veya başka bir iki faktörlü kimlik doğrulama da verebilir .

Ancak bu çok zor bir durum ve web 2.0 değil. Ancak, kendiliğinden oluşturulmayan değerli bilgilere erişimi olan yeni hesaplar oluşturmanın tek güvenli yoludur.

1. Kerberos ve SPNEGO - güvenilir bir üçüncü tarafa sahip tek oturum açma mekanizmaları - temel olarak kullanıcı güvenilir bir üçüncü tarafa karşı doğrulama yapar. (Not: Bu hiçbir şekilde güvenilir oAuth değildir )

2. SRP - güvenilir bir üçüncü taraf olmadan bir tür akıllı şifre doğrulaması. Ancak burada "daha pahalı olsa bile iki faktörlü kimlik doğrulaması kullanmak daha güvenli" alanlarına giriyoruz.

3. SSL istemci tarafı - istemcilere genel bir anahtar sertifikası verin (tüm önemli tarayıcılarda destek - ancak istemci makine güvenliği hakkında soruları gündeme getirir).

Sonunda, bu bir ödünleşmedir - bir güvenlik ihlalinin maliyeti ve daha güvenli yaklaşımların uygulanması maliyeti nedir? Bir gün, uygun bir PKI'nın yaygın olarak kabul edildiğini görebiliriz ve böylece artık kendi rulo kimlik doğrulama formları ve veritabanları yok. Bir gün...

Karma yaparken, MD5 gibi hızlı karma algoritmalar kullanmayın (birçok donanım uygulaması vardır). SHA-512 gibi bir şey kullanın. Parolalar için daha yavaş karmalar daha iyidir.

Ne kadar hızlı karma oluşturursanız, herhangi bir kaba kuvvet denetleyicisi o kadar hızlı çalışabilir. Yavaş karmalar bu nedenle kaba zorlamayı yavaşlatır. Yavaş karma algoritma, daha uzun parolalar için kaba zorlamayı pratik yapmaz (8 basamak +)

Gerçekçi şifre gücü tahmini hakkında iyi bir makale:

Dropbox Teknik Blog »Blog Arşivi» zxcvbn: gerçekçi şifre gücü tahmini

Kimlik doğrulama sistemleriyle ilgili en sevdiğim kural: parola değil parola kullanın. Hatırlaması kolay, çatlaması zor. Daha fazla bilgi: Kodlama Korku: Şifreler ve Geçiş İfadeleri

Derinlemesine savunmaya dayalı olarak kullandığım bir öneri eklemek istiyorum. Yöneticiler için normal kullanıcılarla aynı kimlik doğrulama sistemine sahip olmanıza gerek yoktur. Yüksek ayrıcalık tanıyacak istekler için ayrı bir kod yürüten ayrı bir URL'de ayrı bir giriş formunuz olabilir. Bu, normal kullanıcılar için tamamen acı çekecek seçimler yapabilir. Kullandığım, yönetici erişimi için giriş URL'sini karıştırmak ve yöneticiye yeni URL'yi e-postayla göndermektir. Yeni URL'niz keyfi olarak zor olabileceğinden (çok uzun rasgele dize), ancak yönetici kullanıcınızın tek rahatsızlığı e-postalarındaki bir bağlantıyı izlediğinden, herhangi bir kaba kuvvet saldırısını hemen durdurur. Saldırgan artık nereye POST yapacağını bile bilmiyor.

Buna bir cevap olarak mı yoksa bir yorum olarak mı cevap vermenin en iyisi olduğunu bilmiyorum. İlk seçeneği tercih ettim.

Poing ile ilgili olarak BÖLÜM IV: Unutulan Parola İşlevselliği ilk cevapta, Zamanlama Saldırıları hakkında bir noktaya değineceğim .

In hatırla şifre formları, bir saldırganın potansiyel e-postaların tam listesini kontrol edin ve sisteme kayıtlı oldukları tespit olabilir (aşağıdaki bağlantıya bakınız).

Unutulan Şifre Formu ile ilgili olarak, bazı gecikme fonksiyonu ile başarılı ve başarısız sorgular arasında eşit zamanların iyi bir fikir olduğunu ekleyebilirim.

https://crypto.stanford.edu/~dabo/papers/webtiming.pdf

Çok önemli bir yorum eklemek istiyorum: -

• " Şirket içi , internet içi bir ortamda", yukarıdakilerin tümü olmasa bile çoğu geçerli olmayabilir!

Birçok şirket, URL'lerle uygulanmış olan "kurumsal uygulamalar" olan "yalnızca dahili kullanım" web sitelerini kullanır. Bu URL'ler (sözde ...) yalnızca "şirketin dahili ağı" içinde çözülebilir. (Hangi ağ sihirli bir şekilde VPN bağlantılı tüm 'yol savaşçılarını' içerir.)

Bir kullanıcı yukarıda bahsedilen ağa adanmış bir şekilde bağlandığında, kimliği ("kimlik doğrulaması") [zaten ...] "kesin olarak bilinir" ve onun gibi bazı şeyleri yapma izni ("yetkilendirme") ... gibi. .. "bu web sitesine erişmek için."

Bu "kimlik doğrulama + yetkilendirme" hizmeti, LDAP (Microsoft OpenDirectory) veya Kerberos gibi birkaç farklı teknoloji tarafından sağlanabilir .

Kendi bakış açınıza göre, şunu biliyorsunuz: Web sitenizde meşru bir şekilde rüzgâr alan herkesin [sihirli bir şekilde sihirli bir şekilde ... içeren bir ortam değişkeni ...] ile birlikte olması gerektiğini söyledi. ( örneğin , böyle bir tokenin bulunmaması derhal gerekçelendirilmelidir 404 Not Found.)

Simgenin değeri sizin için bir anlam ifade etmiyor, ancak ihtiyaç ortaya çıkarsa, web sitenizin "(yetkili olarak) bilen birine (LDAP ... vb.)" (Her biri!) olabilir. Başka bir deyişle, do not boşuna kendinizi herhangi "yerli üretim mantığı." Bunun yerine, Kurum'u soruşturuyorsunuz ve kararına dolaylı olarak güveniyorsunuz.

Hah ... "vahşi ve yünlü internet" den oldukça zihinsel bir geçiş.

Kullanım OpenID Bağlan ya Kullanıcı Tarafından Yönetilen Erişim .

Çünkü hiçbir şey yapmamaktan daha etkili değildir.