Soru Form tabanlı web sitesi kimlik doğrulaması için kesin kılavuz [kapalı]


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

Yığın Taşımının sadece çok özel teknik sorular için bir kaynak olması gerektiğine değil, aynı zamanda ortak sorunlardaki varyasyonların nasıl çözüleceğine dair genel kılavuzlar için de olduğuna 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ğıdakileri içermelidir:

  • Nasıl giriş yapılır
  • Nasıl çıkış yapılır
  • Nasıl giriş yapılır
  • Çerezleri yönetme (önerilen ayarlar dahil)
  • SSL / HTTPS şifreleme
  • Şifreler nasıl saklanır?
  • Gizli soruları kullanma
  • Unutulan kullanıcı adı / şifre işlevi
  • Kullanımı nonce'ları önlemek siteler arası talep sahteciliği (CSRF)
  • OpenID
  • "Beni hatırla" onay kutusu
  • Kullanıcı adları ve şifrelerin tarayıcı otomatik tamamlaması
  • Gizli URL'ler (genel) URL sindirilerek korunur
  • Şifre gücünü kontrol etme
  • E-posta doğrulama
  • ve daha fazlası hakkında  form tabanlı kimlik doğrulama...

Aşağıdakileri içermemelidir:

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

Lütfen bize yardımcı olun:

  1. Alt başlık önerme
  2. Bu konuda iyi makaleler sunmak
  3. Resmi cevabı düzenleme

5002


Menşei


HTTP Temel Kimlik Doğrulamasını neden hariç tutmalısınız? Ajax üzerinden HTML Formlarında çalışabilir: peej.co.uk/articles/http-auth-with-html-forms.html - system PAUSE
HTTP Temel Auth, bir tarayıcıyı unutmak (karşılaştırmalı olarak) olma özelliğine sahiptir. Ayrıca, bağlantıyı güvenli hale getirmek için SSL ile kullanmıyorsanız (yani HTTPS) korkunç derecede güvensizdir. - Donal Fellows
Oturumların (fiksasyon ve kaçırma dahil) çerezlerden (güvenli ve sadece http bayrakları) HTTP tabanlı SSO'dan bahsetmeye değer olacağını düşünüyorum. - symcbean
Süper kullanışlı HttpOnly JavaScript tabanlı çerez hırsızlığını (XSS saldırılarının bir alt kümesi) önleyen çerez bayrağı da bir yerlerde belirtilmelidir. - Alan H.
Vay. Uzun cevaplar, bazıları için düzinelerce oy, ama hiç kimse, HTTP üzerinden giriş formları sunma konusunda ortak hatadan bahsetmiyor. Hatta "https: // ... 'e gönderir" diyen insanlarla tartışmıştım ve bir saldırganın şifrelenmemiş sayfayı yeniden yazmamasının emin olup olmadıklarını sorduğumda sadece boş bakışlar aldım. . - dzuelke


Cevaplar:


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:

  1. İ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ı.

  2. 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:

  1. 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).

  2. 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:

  1. Alır neredeyse hiç zaman yok zayıf bir şifreyi kırmak için, bir abaküsle çatlasanız bile

  2. Alır neredeyse hiç zaman yok eğer bir alfanümerik 9 karakterli şifreyi kırmak büyük / küçük harfe duyarlı

  3. 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)

  4. 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

  1. Kimlik Doğrulama için OWASP Rehberi / OWASP Kimlik Doğrulama Hile Sayfası
  2. Web'de İstemci Kimlik Doğrulaması Yapma ve Yapma (çok okunabilir MIT araştırma raporu)
  3. Wikipedia: HTTP çerezi
  4. 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)

3498



Aslında Captcha bölümüne katılmıyorum, evet Captchas can sıkıcıdır ve kırılabilirler (recaptcha dışında ancak bu insanlar tarafından ancak zorlukla çözülebilir!) Fakat bu tamamen spam filtresi kullanmamanın sebebi. % 0.1'den az yanlış negatifler .. Bu site Captcha'ları kullanıyor, mükemmel değiller ama önemli miktarda spam kesiyorlar ve onlara iyi bir alternatif yok. - Waleed Eissa
@Jeff: Cevabımla ilgili sorunlarınızın olduğunu duyduğuma üzüldüm. Meta hakkında bu cevap hakkında bir tartışma olduğunu bilmiyordum, benden rica etseydiniz memnuniyetle kendimce düzenlerdim. Ve benim mesajları silme sadece benim hesabımdan 1200 itibar sildi, hangi acıyor :( - Jens Roland
"Kimlik doğrulama jetonlarını gönderdikten sonra, sistemin kimlik doğruladığınızı hatırlamanın bir yolu olmalı - bu durum yalnızca sunucu verilerinde oturumda saklanmalıdır. Oturum verilerinin referansı için bir çerez kullanılabilir." Tam olarak değil. Vatansız sunucuların için kriptografik olarak imzalanmış bir çerez kullanabilirsiniz. Takas etmek imkansızdır, sunucu kaynaklarını birbirine bağlamaz ve yapışkan oturumlara ya da diğer kurnazlıklara ihtiyaç duymaz. - Martin Probst
"Bir masaüstü bilgisayar, 90 Günden daha kısa sürede 7 karaktere kadar FULL KEYSPACE'i arayabilir" Son GPU'lu bir makine, 1 günden az bir sürede tam 7 char tuş alanını arayabilir. Bir satırın GPU'su saniyede 1 milyar hash taşıyabilir. golubev.com/hashgpu.htm  Bu, doğrudan adreslenmeyen parola deposuyla ilgili bazı sonuçlara yol açar. - Frank Farmer
CSRF korumasına değinilmediğine şaşırdım ... - Flukey


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


387



İmzalanmış SSL sertifikalarını çevreleyen son MITM güvenlik açığı verildiğinde (blog.startcom.org/?p=145Bu nedenle, SSL ve bir çeşit Zorluk yanıtı kimlik doğrulaması (SRP'ye alternatifler var) kombinasyonu muhtemelen daha iyi bir çözümdür. - Kevin Loney
Bu şeylerin çoğu durumsaldır. Oturum çerezlerini hiç kullanma eğiliminde değilim. çerezleri ele geçirilmek neredeyse sunucu hatasıdır. Orta / paket koklama adam o ortak - Shawn
BCrypt Nuget paketi: nuget.org/List/Packages/BCrypt - Fabian Vilers
Bu cevap hakkında not 1: Bu bir wiki olarak düzenlenecek bir taslaktır. Bunu düzenleyebiliyorsanız, hoşgeldiniz demektir. - Peter Mortensen


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

Devam edip, Mozilla’nın teklifinden bahsedeceğim BrowserId (ya da belki daha doğrusu, Doğrulanmış E-posta ProtokolüGelecekte kimlik doğrulamaya daha iyi yaklaşımlar için bir yükseltme yolu bulma ruhunda.

Bu şekilde özetleyeceğim:

  1. Mozilla kar amacı gütmeyen bir değerler Bu soruna iyi çözümler bulmakla uyumludur.
  2. Bugünün gerçekliği, çoğu web sitesinin form tabanlı kimlik doğrulaması kullanmasıdır.
  3. Form tabanlı kimlik doğrulaması büyük bir dezavantaja sahiptir, Kimlik avı. Kullanıcılardan, Kullanıcı Bilgileri (tarayıcı) tarafından kontrol edilen bir alan yerine, uzak bir kuruluş tarafından kontrol edilen bir alana hassas bilgiler girmeleri istenir.
  4. Tarayıcılar gizlice güvendikleri için (Kullanıcı Aracının tüm fikri, Kullanıcı adına hareket etmektir), bu durumu iyileştirmeye yardımcı olabilirler.
  5. Geriye doğru ilerleyen birincil kuvvet burada dağıtım kilitlenme. Çözümler, kendi başlarına bir miktar artan fayda sağlayan adımlara ayrılmalıdır.
  6. İnternet altyapısına dahil edilen kimliğin ifade edilmesi için en basit desantralize yöntem alan adıdır.
  7. İkinci bir kimlik ifade düzeyi olarak, her alan kendi hesaplarını yönetir.
  8. Form "hesap@domain ”çok çeşitli protokoller ve URI şemaları tarafından özlü ve destekleniyor. Böyle bir tanımlayıcı, elbette, çoğu evrensel olarak bir e-posta adresi olarak kabul edilir.
  9. E-posta sağlayıcıları zaten çevrimiçi fiili birincil kimlik sağlayıcılarıdır. Mevcut şifre sıfırlama akışları genellikle, hesabın ilişkili e-posta adresini kontrol ettiğinizi kanıtlayabilirseniz bir hesabın kontrolünü ele geçirmenizi sağlar.
  10. Doğrulanmış E-posta Protokolü, etki alanı B'ye ait bir hesabınız olduğunda etki alanı B'ye kanıtlanma sürecini kolaylaştırmak için, açık anahtar şifrelemesine dayanan güvenli bir yöntem sağlamak için önerilmiştir.
  11. Doğrulanmış E-posta Protokolünü desteklemeyen tarayıcılarda (şu anda bunların hepsi) Mozilla, istemci tarafında JavaScript kodunda protokolü uygulayan bir çerçeve sağlar.
  12. Doğrulanmış E-posta Protokolünü desteklemeyen e-posta hizmetleri için, protokol, üçüncü tarafların bir kullanıcının bir hesabın sahipliğini doğruladıklarını iddia ederek güvenilir bir aracı olarak hareket etmelerine olanak tanır. Çok sayıda üçüncü tarafa sahip olmak arzu edilmez; Bu özellik sadece bir yükseltme yoluna izin vermek içindir ve e-posta hizmetlerinin bu iddiaları kendilerinin sağlaması daha çok tercih edilir.
  13. Mozilla, güvenilir bir üçüncü taraf olarak hareket etmek için kendi hizmetlerini sunar. Doğrulanmış E-posta Protokolünü uygulayan Hizmet Sağlayıcıları (yani, Geriye Gönderen Taraflar), Mozilla'nın iddialarına güvenmeyi seçebilir veya etmeyebilir. Mozilla’nın hizmeti, kullanıcıların onayını içeren bir e-posta göndermenin geleneksel yollarını kullanarak, kullanıcıların hesap sahipliğini doğrular.
  14. Servis Sağlayıcılar, elbette sunmak istedikleri kimlik doğrulama yöntemlerinin başka bir yöntemine ek olarak bu protokolü bir seçenek olarak sunabilirler.
  15. Burada aranan büyük bir kullanıcı arayüzü yararı “kimlik seçici” dir. Bir kullanıcı bir siteyi ziyaret ettiğinde ve kimliğini doğrulamayı seçtiğinde, tarayıcıları kendilerini siteye tanıtmak için kullanabilecekleri bir dizi e-posta adresi (“kişisel”, “çalışma”, “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ıyı kullanıcının oturumu hakkında daha fazla bilgi edinme - Öncelikle şu anda oturum açtıkları kişiler - tarayıcı kromunda bunu görüntüleyebilir.
  17. Bu sistemin dağınık yapısı nedeniyle Facebook, Twitter, Google vb. Gibi büyük sitelere kilitlenmekten kaçınılır. Herhangi bir birey kendi alanlarına sahip olabilir ve bu nedenle kendi kimlik sağlayıcıları olarak hareket edebilir.

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


146



Tarayıcı Kimliği bağlantısı öldü - Mehdi
Proje güvensiz gibi görünüyor. en.wikipedia.org/wiki/Mozilla_Persona - Jeff Olson


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!


120



Bu yararlı bir spam karşıtı hiledir, ancak 'e-posta' dışında bir alan adı kullanmanızı öneririm ya da sitenin gerçek kullanıcılarını yanlışlıkla engellemek için tarayıcı otomatik dolgunluğunun doldurduğunu görebilirsiniz. - Nico Burns
Ben de bunlardan birkaç tane daha var visibility:hidden ve ayrıca position:absolute;top:-9000px ayrıca yapabilirsin text-indent ve ayrıca z-index Bu elemanlardan birkaçı ve sıkıştırılmış CSS dosya adlarını garip isimlerle yerleştirebilirsiniz - çünkü botlar 1 görüntüyü algılayabildiğinden: yok ve şimdi bir dizi kombinasyon için kontrol ediyorlar - aslında bu yöntemleri kullanıyorlar ve ticaretin eski numaraları . +1 - TheBlackBenzKid
Görme bozukluğu olan bir kullanıcı, formda gezinmek için ekran okuyucusu kullanıyorsa ne olur? - gtcharlie
Bu tekniğin bir adı var: bal küpü en.wikipedia.org/wiki/Honeypot_(computing) - pixeline
Satır içi stiline gerek yok. Sadece alana bir sınıf ekleyin (belki de bir bot için bir şey ifade etmeyen garip bir kelime kullanın) ve sitenin CSS dosyasıyla gizleyin. Sevmek: <input type="text" name="email" class="cucaracha"> ve CSS’nizde: .cucaracha { display:none; }. - Ricardo Zea


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.)

    1. Ö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.

  1. 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)

  2. 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

  3. 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...


71



Hangi cevabın bahsettiğini anlatmak zor 'Yukarıdaki cevabın yanlış olduğunu düşünmüyorum' ' - Davorak


Karma olduğunda, MD5 gibi hızlı karma algoritmalar kullanmayın (birçok donanım uygulaması var). SHA-512 gibi bir şey kullanın. Şifreler için, daha yavaş karmalar daha iyidir.

Daha hızlı, karma oluşturabilirsiniz, daha hızlı herhangi bir kaba kuvvet denetleyicisi çalışabilir. Daha yavaş karmalar bu nedenle kaba kuvvetleri yavaşlatır. Yavaş bir karma algoritma, daha uzun şifreler için kaba zorlama (8 basamak +) yapar.


48



SHA-512 de hızlı, bu yüzden binlerce iterasyona ihtiyacınız var. - Seun Osewa
"hızlı karma algoritmaları kullanmayın ... daha yavaş karmalar daha iyidir" - Açıklama? Belgeler? - one.beat.consumer
Açıklama: Hızlı bir şekilde karma oluşturabileceğiniz, daha hızlı herhangi bir kaba kuvvet denetleyicisi çalışabilir. Daha yavaş karmalar bu nedenle kaba kuvvetleri yavaşlatır. Yavaş bir karma algoritma, daha uzun şifreler için kaba zorlama (8 basamak +) yapar. - NickG
Daha yavaş, yavaşça hash etmek için tasarlanan bcrypt gibi bir şey gibi. - Fabian Nicollier


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

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


46





Kimlik doğrulama sistemlerine dair en sevdiğim kural: parola değil parolalar kullanın. Hatırlanması kolay, çatlamak zor. Daha fazla bilgi: Kodlama Korkusu: Şifreler vs Pass İfadeleri


41





Derinlemesine savunmaya dayalı olarak kullandığım bir öneri eklemek istiyorum. Düzenli kullanıcılar olarak yöneticiler için aynı yetki ve yetki sistemine sahip olmanız gerekmez. Yüksek ayrıcalıklar veren istekler için ayrı bir kodun ayrı bir kod üzerinde ayrı bir giriş formuna sahip olabilirsiniz. Bu, düzenli kullanıcılar için tam bir acı olacak seçimler yapabilir. Kullanmış olduğum bir şey, yönetici erişimi için giriş URL'sini gerçekten karıştırmak ve yeni URL'ye yöneticiye e-posta göndermektir. Yeni URL'niz keyfi olarak zor olabileceğinden (çok uzun rastgele bir dize) herhangi bir kaba kuvvet saldırısını hemen durdurur, ancak yöneticinizin tek rahatsızlığı e-postasındaki bir bağlantıyı takip etmektir. Saldırgan artık POST’un nereye gideceğini artık bilmiyor.


20



E-posta güvenli olmadığı için bir e-postadaki basit bir bağlantı aslında güvenli değildir. - David Spector
Yine de, iki faktörlü olmayan başka bir jeton tabanlı şifre sıfırlama sistemi kadar güvenlidir. Neredeyse hepsi bu. - Iain Duncan