A végleges útmutató a forma-alapú weboldal hitelesítés

szavazat
4k

Forma-alapú hitelesítés honlapok

Úgy véljük, hogy Veremtúlcsordulás ne csak a forrás nagyon konkrét technikai kérdések, hanem általános iránymutatást, hogyan kell megoldani variációk közös problémákra. „Form alapú hitelesítés honlapok” kell egy finom téma egy ilyen kísérlet.

Ennek tartalmaznia kell olyan témákat, mint:

  • Hogyan kell bejelentkezni
  • Hogyan kijelentkezni
  • Hogyan maradsz bejelentkezve
  • Cookie-k kezelése (beleértve az ajánlott beállítások)
  • SSL / HTTPS titkosítás
  • Hogyan kell tárolni a jelszavakat
  • A titkos kérdésre
  • Elfelejtett felhasználónév / jelszó alkalmassága
  • Használata nonces megelőzésére cross-site request hamisítvány (CSRF)
  • OpenID
  • „Emlékezz rám” jelölőnégyzetet
  • Böngésző automatikus kiegészítést felhasználónevek és jelszavak
  • Titkos URL-ek (nyilvános URL által védett emésztett)
  • Ellenőrzés jelszó erőssége
  • E-mail érvényesítés
  • és sokkal többet űrlap alapú hitelesítést ...

Nem lehet itt a dolgok, mint:

  • Szerepek és engedélyezés
  • HTTP alapszintű hitelesítés

Kérjük, segítsen nekünk:

  1. ami arra utal, altémák
  2. Benyújtása jó cikkek erről a témáról
  3. Szerkesztése a hivatalos válasz
A kérdést 02/08/2008 20:51
a forrás felhasználó
Más nyelveken...                            


12 válasz

szavazat
382

végleges cikk

Küldés hitelesítő

Az egyetlen módja, hogy küldjön hitelesítő 100% biztonságos a segítségével SSL . A JavaScript használata hash a jelszó nem biztonságos. Gyakori buktatók ügyféloldali jelszó hash:

  • Ha a kapcsolat a kliens és a szerver nem titkosított, minden, amit csinál sebezhető man-in-the-middle támadás . A támadó helyett a bejövő javascript megtörni tördelő vagy küldje hitelesítő a szerverre, tudták hallgatni ügyfél válaszokat és megszemélyesíteni felhasználó tökéletesen, stb stb SSL megbízható tanúsító hatóságok célja, hogy megakadályozza mitm támadásokat.
  • A kivonatolt jelszót kapja meg a szerver nem kevésbé biztonságos , ha nem teszed további, felesleges munka a szerveren.

Van egy biztonságos módszer az úgynevezett SRP , de ez a szabadalmaztatott (bár ez szabad licencű ), és van néhány jó megvalósítások elérhető.

tárolása jelszavak

Soha ne tároljon jelszavakat egyszerű szövegként szerepel az adatbázisban. Még ha nem törődnek a biztonsági saját honlapján. Tegyük fel, hogy néhány felhasználó újra a jelszót az online bankszámlát. Tehát, tárolja a kivonatolt jelszót, és dobja el az eredetit. És győződjön meg róla, a jelszó nem jelenik meg a hozzáférési naplók vagy alkalmazás naplók. OWASP használatát javasolja Argon2 , mint az első választás az új alkalmazásokat. Ha ez nem áll rendelkezésre, vagy PBKDF2 scrypt kell használni. És végül, ha a fentiek egyike sem áll rendelkezésre, használja bcrypt.

Hash önmagukban is bizonytalan. Például azonos jelszavakat jelent azonos hash - ez teszi hash keresési táblák hatékony módja a repedés sok jelszavakat egyszerre. Ehelyett tárolja a sózott hash. A só egy string mellékelt a jelszó hash előtt - használjon egy másik (random) só felhasználónként. A só egy közös értéket, így azokat tárolja a hash az adatbázisban. Lásd itt erről többet.

Ez azt jelenti, hogy nem küld a felhasználó saját elfelejtett jelszavak (mert csak a hash). Ne állítsa vissza a felhasználó jelszavát, kivéve, ha a felhasználó hitelesítése (felhasználók bizonyítaniuk kell, hogy képesek olvasni az e-maileket küldött a tárolt (és validált) e-mail címét.)

Biztonsági kérdések

Biztonsági kérdés bizonytalan - ne használja őket. Miért? Bármi egy biztonsági kérdést tesz egy jelszót nem jobb. Olvasd RÉSZ: A titkos kérdések a @Jens Roland válaszolni itt, ebben a wikiben.

session cookie-k

Miután a felhasználó bejelentkezik, a szerver küld a felhasználó session cookie-t. A szerver lehet letölteni a felhasználónevét vagy id a cookie-t, de senki sem tud generálni, mint a cookie (TODO magyarázza mechanizmusok).

A cookie-k eltérített : ők csak annyira biztonságos, mint a többi kliens gépen és egyéb kommunikáció. Ők lehet olvasni a lemezről, beleszagolt a hálózati forgalmat, emelik a cross-site scripting támadást, phished egy mérgezett DNS így a kliens elküldi a cookie-kat a rossz szerver. Ne küldjön tartós cookie-kat. A cookie-k le kell járnia a végén a ügyfélmunkamenethez (böngésző bezárása vagy elhagyja a domain).

Ha azt szeretnénk, hogy Autologin a felhasználóknak, akkor tartós sütiket, de meg kell különbözik a teljes session cookie. Beállíthatjuk kiegészítő zászlót, hogy a felhasználó automatikus jelentkezve, és be kell jelentkezni az igazi érzékeny műveleteket. Ez népszerű bevásárló helyek, hogy szeretné, hogy az Ön zökkenőmentes, személyre szabott vásárlási élmény, de még mindig védi a pénzügyi részleteket. Például, amikor visszatér, hogy nézze meg az Amazon, akkor megmutatom egy oldal, amely úgy néz ki, mint te vagy jelentkezve, de ha megy a megrendelést (vagy módosítsa a szállítási címet, hitelkártya, stb), akkor kérjük, hogy erősítse a jelszavad.

Pénzügyi weboldalak, mint a bankok és hitelkártya másrészt, csak az érzékeny adatokat, és nem teszi lehetővé az automatikus bejelentkezés, vagy egy alacsony biztonsági módban.

Lista a külső erőforrások

Válaszolt 02/08/2008 21:40
a forrás felhasználó

szavazat
3k

I. RÉSZ: hogyan kell bejelentkezni

Azt feltételezzük, hogy már tudja, hogyan kell elkészíteni egy login + jelszó HTML formában POST az értékeket egy script a szerver oldalon a hitelesítéshez. Az alábbi szakaszok foglalkozik majd mintát hang gyakorlati auth, és hogyan lehet elkerülni a leggyakoribb biztonsági buktatókat.

Ahhoz, hogy HTTPS vagy nem HTTPS?

Kivéve, ha a kapcsolat már biztonságos (vagyis bújtatott keresztül HTTPS SSL / TLS), a bejelentkezési űrlap értékeit kerül elküldésre kódolatlan, amely lehetővé teszi, hogy bárki lehallgatás a sorban a böngésző és a webszerver képes lesz olvasni bejelentkezéseket, mert át keresztül. Ez a fajta lehallgatás történik rutinszerűen a kormányok, de általában nem fogunk foglalkozni „tulajdonában” vezetékek kivételével mondani: Ha van védelme valami fontos HTTPS protokollt használják.

Lényegében az egyetlen gyakorlati módja, hogy megvédje lehallgatás / csomag szippantás során a bejelentkezés használatával HTTPS vagy más tanúsítvány alapú titkosítási rendszer (például TLS ), illetve a bizonyított és tesztelt kérdés-válasz rendszer (például a DiffieHellman- -alapú SRP). Bármilyen más módszer, könnyen megkerülhető egy lehallgatás támadó.

Persze, ha hajlandó, hogy egy kicsit kivitelezhetetlen, akkor is foglalkoztat valamilyen formában a kéttényezős hitelesítést rendszert (pl a Google Hitelesítő alkalmazás, a fizikai „hidegháború stílusú” kódkönyvből vagy egy RSA kulcsot generátor dongle). Ha helyesen alkalmazzák, ez a munka még nem biztonságos kapcsolatot, de nehéz elképzelni, hogy egy dev hajlandó lenne kétfaktoros azonosítási de nem SSL-t.

(Ne) Roll-a-saját JavaScript titkosítás / tördelő

Tekintettel a zéró költség és az észlelt technikai nehézsége létrehozásáról SSL tanúsítvány a honlapon, néhány fejlesztők hajlamosak dobni a saját in-böngésző tördelő vagy titkosítási rendszerek elkerülése érdekében elhaladó kódolatlan keresztüli bejelentkezést fedezetlen vezetéket.

Bár ez egy nemes gondolat, ez lényegében használhatatlan (és lehet egy biztonsági hiba ), ha ez párosul a fenti - azaz vagy biztosítja a vonal erős titkosítással vagy egy kipróbált és tesztelt kérdés-válasz mechanizmus (ha nem tudod mi ez, csak tudom, hogy ez az egyik legnehezebb bizonyítani, a legtöbb nehéz tervezni, és legnehezebb megvalósítani fogalmak a digitális biztonság).

Bár igaz, hogy tördeljük a jelszó lehet ellen hatásos jelszó nyilvánosságra hozatala , ki van téve a visszajátszás támadások, Man-in-the-middle támadások / eltérítések (ha a támadó az injekciót néhány bájtot fedezetlen HTML oldalt mielőtt az elérné a böngésző, akkor egyszerűen megjegyzésbe tördelő a JavaScript), vagy brute-force támadások (mert akkor átadta a támadó mindkét felhasználónév, a sót és a kivonatolt jelszót).

CAPTCHA emberiség elleni

CAPTCHA célja, hogy kiküszöböljék egy adott kategóriába a támadás: az automatizált szótár / brute force próba-és hiba nélkül emberi operátor. Kétségtelen, hogy ez egy valós veszélyt, azonban vannak módszerek foglalkozik vele zökkenőmentesen, amelyek nem igényelnek CAPTCHA kifejezetten megfelelően tervezett szerveroldalon bejelentkezés fojtás rendszerek - megbeszéljük azokat később.

Tudd, hogy CAPTCHA megvalósítások nem jönnek létre egyaránt; gyakran nem emberi megoldható, legtöbbjük valójában hatástalan botok ellen, mindegyik ellen hatástalanok olcsó harmadik világbeli munkaerő (az OWASP , a jelenlegi kizsákmányoló ráta 12 $ 500 teszt), és néhány megvalósítások technikailag illegális néhány országban (lásd OWASP Authentication Cheat Sheet ). Ha kell használni a CAPTCHA használja a Google reCAPTCHA , mert az OCR-kemény definíció (mert használja már OCR-pontos eredményt könyv vizsgál), és megpróbál nagyon nehéz lesz felhasználóbarát.

Személy szerint én inkább találni CAPTCHA idegesítő, és használja őket, csak a legvégső esetben, ha a felhasználó nem a bejelentkezéshez több alkalommal és fojtás késedelmek maxxed ki. Ez fog történni ritkán ahhoz, hogy elfogadható, és erősíti a rendszer egészére.

Tárolása jelszavak / ellenőrzése bejelentkezések

Ez végül a közös tudás, miután az összes nagy nyilvánosságot csapkod és felhasználói adatok kiszivárgása láttunk az elmúlt években, de el kell mondani: Ne tároljon jelszavakat a kódolatlan az adatbázisban. Felhasználói adatbázisok rutinszerűen csapkodott, kiszivárgott vagy félretett keresztül SQL injection, és ha nyerstej tárolására, szöveges jelszavakat, azaz azonnali game over a bejelentkezési biztonság.

Tehát, ha nem tudja tárolni a jelszót, hogyan ellenőrizze, hogy a belépés + jelszó kombinációt POSToltad a bejelentkezési űrlap helyes? A válasz tördeljük egy kulcs származtatás függvény . Amikor egy új felhasználó létrehozásakor vagy jelszó megváltozik, akkor megteszi a jelszót, és fuss át a KDF, mint például Argon2, bcrypt, scrypt vagy PBKDF2 fordult a kódolatlan jelszó ( „correcthorsebatterystaple”) egy hosszú, véletlenszerű megjelenésű húr , ami sokkal biztonságosabb tárolni az adatbázisban. Annak ellenőrzésére, a belépés, akkor fennáll az azonos hash függvény a megadott jelszót, ez idő halad, a sót, és hasonlítsa össze a kapott hash karakterláncot az adatbázisban található. Argon2, bcrypt és scrypt tárolja a sót a hash már. Nézd meg ezt a cikket a sec.stackexchange részletes információkat.

Az ok a sót használnak azért van, mert tördeljük önmagában nem elegendő - szeretne hozzáadni egy úgynevezett „só”, hogy megvédje a hash ellen szivárványos táblákat . A só hatékonyan megelőzi két jelszó egyezik pontosan rögzítse, mint az azonos hash érték, amely megakadályozza a teljes adatbázis szkennelt egy menetben, ha egy támadó végrehajtó jelszó találgatás támadást.

A kriptográfiai hash nem használható jelszó tárolására, mert a felhasználó által kiválasztott jelszavak nem elég erős (azaz általában nem tartalmaznak elég entrópia) és egy jelszó találgatás támadás lehet kitölteni egy viszonylag rövid idő alatt egy támadó hozzáférést a hash-eket. Ez az, amiért a KDF használnak - ezek hatékonyan „nyúlik a kulcs” azt jelenti, hogy minden jelszó kitalálni a támadó teszi magában iterációjával az algoritmus többszöri, például 10.000-szer, így a támadó jelszó találgatás 10.000-szer lassabb.

Session adatok - „Te vagy bejelentkezve Spiderman69”

Ha a kiszolgáló ellenőrizte a bejelentkezési név és jelszó ellen felhasználói adatbázist, és találtam egy mérkőzés, a rendszernek szüksége van egy módja annak, hogy ne feledje, hogy a böngésző már hitelesítve. Ez a tény csak elveszett tárolni szerver oldalon a munkamenet adatokat.

Ha Ön nem ismeri a munkamenet adatokat, itt van, hogyan működik: Egy véletlenszerűen generált karakterlánc tárolása egy lejáró cookie hivatkozunk az adatgyűjtés - a munkamenet adatokat -, amely tárolja a szerveren. Ha ön használ egy MVC keretrendszer, ez kétségtelenül kezelik már.

Ha egyáltalán lehetséges, ellenőrizze, hogy a session cookie van a biztonságos és HTTP Csak jelzők, amikor elküldte a böngészőnek. A HttpOnly zászló némi védelmet nyújt a cookie olvas egy XSS támadást. A biztonságos zászló biztosítja, hogy a cookie-k csak a küldött vissza HTTPS, és ezért védi a hálózatot szippantás támadásokat. Az érték a cookie ne legyen kiszámítható. Amennyiben a cookie-e egy nem létező ülésén kerül bemutatásra, értékét azonnal ki kell cserélni, hogy megakadályozzák a munkamenet rögzítés .

RÉSZ: hogyan maradjon bejelentkezve - a hírhedt „Remember Me” jelölőnégyzet

Kitartó Bejelentkezés kekszek ( „Emlékezz rám” funkciót) egy veszélyzónában; egyrészt, hogy teljes egészében ugyanolyan biztonságos, mint a hagyományos bejelentkezést, amikor a felhasználók megértsék, hogyan kell kezelni őket; és másrészt, ők egy hatalmas biztonsági kockázatot a kezében óvatlan felhasználók számára, akik használják őket nyilvános számítógépek és felejtsd el, hogy jelentkezzen ki, és aki nem tudja, mi a böngésző cookie, vagy hogyan kell törölni őket.

Én személy szerint szeretem a tartós bejelentkezési a weboldalak meglátogatom rendszeresen, de tudom, hogyan kell kezelni őket biztonságosan. Ha biztos abban, hogy a felhasználók tudják ugyanazt, akkor tartós bejelentkezési tiszta lelkiismerettel. Ha nem - nos, akkor iratkozz fel a filozófia, hogy a felhasználók, akik gondatlan azok bejelentkezési adatait hozta fel magukat, ha kap csapkodott. Ez nem olyan, megyünk mi felhasználói házak és Leszakítom mindazok homlokára csap indukáló Post-It jegyzi jelszavak általuk sorakoznak a szélén a monitorok sem.

Természetesen egyes rendszerek nem engedheti meg magának, hogy minden számla csapkodott; Az ilyen rendszerek, nincs mód arra, hogy igazolják, amelyek tartós bejelentkezéseket.

Ha úgy dönt, hogy végre tartós bejelentkezési cookie-kat, ez hogyan csináld:

  1. Először is, hogy egy kis időt, hogy olvassa el a Paragon Initiative cikket a témában. El kell kapni egy csomó elem van, és a cikk nem egy nagy munkát elmagyarázza mindegyik.

  2. És csak ismételni az egyik leggyakoribb buktatókat, NE TÁROLJON kitartó bejelentkezési cookie (token), az adatbázisban, csak egy hash-IT! A bejelentkezési jelszó token egyenértékű, tehát ha egy támadó rá a kezét az adatbázisban, akkor jönne a tokeneket jelentkezzen be, hogy minden számla, csak úgy, mintha kódolatlan login-jelszó kombinációt. Ezért használja tördelő (az https://security.stackexchange.com/a/63438/5002 gyenge hash nem csak finom erre a célra), amikor tárolja kitartó belépés zsetont.

RÉSZ: A titkos kérdések

Ne hajtsa végre „titkos kérdésre” . A „titkos kérdésre” funkció egy biztonsági anti-mintát. Olvassa el a papírt a kapcsolat szám 4-től a must-olvasni a listát. Akkor kérje Sarah Palin, hogy az egyik, utána a Yahoo! E-mail fiók kapott feltört egy ezt megelőző elnökválasztási kampány, mert a válasz a biztonsági kérdést ... „Wasilla High School”!

Még a felhasználó által megadott kérdésekre, akkor nagyon valószínű, hogy a legtöbb felhasználó választhat:

  • A „standard” titkos kérdés, mint anyja neve, vagy kedvenc állata

  • Egy egyszerű darab trivia, hogy bárki tudott felemelni a saját blog, LinkedIn profilja, vagy hasonló

  • Bármilyen kérdés, hogy könnyebb válaszolni, mint találgatás a jelszavát. Mely, bármilyen tisztességes jelszavakat, minden kérdés, amit el tud képzelni

Összefoglalva, a biztonsági kérdéseket eredendően nem biztonságosak szinte valamennyi formáját és variációk, és nem alkalmazhatók egy hitelesítési rendszert, bármilyen okból.

Az igazi ok, amiért a biztonsági kérdéseket is létezik a természetben az, hogy kényelmesen menteni a költsége néhány támogató hívások számára, akik nem tudnak hozzáférni az e-mail eljutni reaktiválási kódot. Ez rovására biztonság és Sarah Palin hírnevét. Megéri? Valószínűleg nem.

RÉSZ: Elfelejtett jelszó Funkcionalitás

Már említettem, hogy miért kell soha nem használja a biztonsági kérdéseket kezelésére elfelejtett / elveszett a felhasználói jelszavakat; ez is magától értetődik, hogy soha ne e-mail felhasználók tényleges jelszavakat. Vannak még legalább két túlságosan is gyakori buktatókat elkerülni ezen a területen:

  1. Ne állítsa vissza az elfelejtett jelszót is automatikusan generált erős jelszót - például jelszavak közismerten nehéz emlékezni, ami azt jelenti, a felhasználónak kell a módosítását vagy írd le - mondjuk, egy fényes, sárga Post-It szélén a monitort. Beállítása helyett egy új jelszót, csak hagyja, hogy a felhasználók felvenni egy új azonnal - ami mit akarnak csinálni egyébként.

  2. Mindig hash az elveszett jelszó kód / token az adatbázisban. ISMÉT , ezt a kódot egy másik példája a jelszó egyenértékű, ezért kell hash-sel esetén a támadó rá a kezét az adatbázist. Amikor egy elfelejtett jelszó kódot kér, küldje az egyszerű szöveges kódot a felhasználó e-mail címét, majd hash meg, kivéve a hash az adatbázis - és eldobni az eredeti . Csakúgy, mint egy jelszó vagy tartós bejelentkezés jelzőt.

Egy utolsó megjegyzés: mindig győződjön meg róla, hogy interfész belépő „elfelejtett jelszó kód” legalább olyan biztonságos, mint a bejelentkezési űrlapban vagy a támadó egyszerűen csak használja ezt, hogy hozzáférjen helyett. Ügyelve arra, hogy létrehoz nagyon hosszú "elfelejtett jelszó kódok (például 16 esetben érzékeny alfanumerikus karakter) egy jó kezdet, de vegye fel ugyanazt a fojtás rendszer, hogy te a bejelentkezési űrlap is.

V. RÉSZ: Ellenőrzés Jelszó Strength

Először is, akkor szeretnénk olvasni ezt a kis cikket a valósággal: A 500 leggyakoribb jelszavak

Oké, talán a lista nem a kanonikus listáját leggyakoribb jelszavak bármilyen rendszerben bárhol valaha , de ez jól jelzi, hogy milyen rosszul ember választja a jelszavukat, ha nincs érvényesített politikája. Plusz, a listát úgy néz ki, félelmetesen közel otthon, ha összehasonlítjuk a nyilvánosan elérhető elemzéseket nemrégiben ellopott jelszavak.

Tehát: Ha nincs jelszó minimális szilárdsági követelményeknek, 2% -a felhasználó használja az egyik top 20 leggyakoribb jelszavak. Jelentése: ha a támadó kap csak 20 próbálkozás, 1 50 fiókot a honlapon lesz feltörhetővé teszi.

Meghiúsítva ehhez kiszámításakor az entrópia egy jelszót, majd alkalmazása a küszöböt. A National Institute of Standards and Technology (NIST) Special Publication 800-63 van egy sor nagyon jó javaslatokat. Ez, kombinálva egy szótárat és billentyűzetkiosztást analízis (például „qwertyuiop” rossz jelszó), akkor utasítsa 99% -át rosszul kiválasztott jelszavak szinten 18 bites entrópia. Egyszerűen kiszámítása jelszó erősségét, illetve mutató vizuális erejét mérő a felhasználó jó, de nem elegendő. Hacsak nem érvényesül, sok felhasználó valószínűleg figyelmen kívül hagyja.

És egy frissítő veszi felhasználóbarát magas entrópia jelszavakat, Randall Munroe a jelszó erőssége xkcd erősen ajánlott.

RÉSZ: még sok más - Vagy: megelőzése gyorstüzelő bejelentkezési kísérletek

Először is, vessen egy pillantást a számok: Password Recovery sebességfokozat - Meddig jelszavát felállni

Ha nincs ideje, hogy nézd át a táblákat, hogy a linket, itt a lista róluk:

  1. Tart gyakorlatilag nincs ideje , hogy kiváló a gyenge jelszó, akkor is, ha repedés egy abakusz

  2. Tart gyakorlatilag nincs idő feltörni egy alfanumerikus 9 karakteres jelszó, ha ez esetben érzéketlen

  3. Tart gyakorlatilag nincs idő feltörni egy bonyolult, szimbólumok-és betűk-és számok, felső-kisbetű jelszót, ha ez kevesebb, mint 8 karakter hosszú (egy asztali PC lehet keresni a teljes kulcstérnek akár 7 karakterek a napok kérdése, vagy akár óra)

  4. Lenne azonban, hogy egy rengeteg időt feltörni még egy 6 karakteres jelszó, ha arra korlátozódik egyetlen kísérlet másodpercenként!

Tehát mit tanulhatunk ezekből a számokból? Nos, sok, de tudunk összpontosítani a legfontosabb része: az a tény, hogy megakadályozzák nagyszámú gyorstüzelő egymást követő bejelentkezési kísérletek (pl. A brute force attack) tényleg nem olyan nehéz. De megakadályozza, hogy jobb nem olyan egyszerű, mint amilyennek látszik.

Általánosságban elmondható, hogy három lehetőség közül választhat, amelyek minden ellen hatásos brute-force támadások (és szótár támadások, de mivel már alkalmazó erős jelszavakat politika, akkor nem lesz probléma) :

  • Jelenleg egy CAPTCHA után N sikertelen kísérlet után (bosszantó, mint a pokol, és gyakran nem hatékony - de én ismételni magam itt)

  • Záró beszámoló igénylő e-mail ellenőrző után N sikertelen kísérlet után (ez egy DoS támadás vár, hogy megtörténjen)

  • És végül, belépés fojtás : ez, amelyben a késleltetést kísérletek közötti követően N sikertelen kísérlet után (igen, DoS támadások továbbra is lehetséges, de legalább sokkal kevésbé valószínű, és sokkal bonyolultabb, hogy húzza le).

Legjobb gyakorlat # 1: Egy rövid késleltetés, amely növeli a sok sikertelen próbálkozás, mint például:

  • 1 sikertelen kísérlet = nincs késleltetés
  • 2 sikertelen próbálkozás = 2 mp késleltetés
  • 3 sikertelen próbálkozás = 4 sec késleltetés
  • 4 sikertelen kísérlet = 8 mp késleltetési
  • 5 sikertelen kísérlet = 16 mp késleltetési
  • stb.

DoS támadásokat ez a rendszer nagyon praktikus, mert a kapott lockout idő valamivel nagyobb, mint az összege az előző kizárási időket.

Annak tisztázása: A késleltetés nem késés, mielőtt visszatért a válasz a böngészőnek. Ez több, mint egy timeout vagy tűzálló időszak, amely alatt a bejelentkezési kísérletek egy adott számla vagy egy adott IP-cím nem fogadható el vagy nem értékelték egyáltalán. Ez azt jelenti, helyes hitelesítő adatokat nem tér vissza a sikeres bejelentkezést, és helytelen hitelesítő adatokat nem fogja kiváltani a késedelem növekedését.

Legjobb gyakorlat # 2: A közepes hosszúságú késleltetési idő, hogy megy után hatályba N sikertelen próbálkozás, mint például:

  • 1-4 sikertelen kísérletek = nincs késleltetés
  • 5 sikertelen kísérlet = 15-30 perc késés

DoS támadásokat ez a rendszer lenne elég praktikus, de biztosan megvalósítható. Azt is fontos lehet megjegyezni, hogy egy ilyen hosszú késése Nagyon bosszantó tud lenni egy jogos felhasználót. Feledékeny felhasználók nem szeretik Önt.

Legjobb gyakorlat # 3: Ötvözi a két megközelítés - akár vezetékes, rövid késéssel, hogy megy után hatályba N sikertelen próbálkozás, mint például:

  • 1-4 sikertelen kísérletek = nincs késleltetés
  • 5+ sikertelen kísérletek = 20 mp késleltetési

Vagy egyre késleltetés fix felső határa, mint például:

  • 1 sikertelen kísérlet = 5 sec késleltetés
  • 2 sikertelen próbálkozás = 15 mp késleltetési
  • 3+ sikertelen kísérletek = 45 mp késleltetési

Ezt a végső rendszer vettünk a OWASP legjobb gyakorlatok javaslatok (link 1-től a kötelező olvasmány listát), és figyelembe kell venni a legjobb gyakorlatot, akkor is, ha ugyan a korlátozó oldalon.

Mint ökölszabály azonban azt mondják: minél erősebb a jelszavát politika, annál kevesebbet kell bug felhasználók késedelmet. Ha szüksége van az erős (a kis- és nagybetűk alfanumerikus + szükséges a számok és szimbólumok) 9+ karakteres jelszavakat, meg lehet adni a felhasználó számára a 2-4 nem késik jelszó kísérlet előtt aktiválja a fojtás.

DoS támadásokat ez a végső bejelentkezés fojtás rendszer lenne nagyon praktikus. És egy utolsó érintés, mindig persistent (cookie) bejelentkezési (és / vagy a CAPTCHA-ellenőrzött bejelentkezés formában) kell áthaladni, így jogos a felhasználók nem is késik , míg a támadás van folyamatban . Így a nagyon praktikus DoS támadás válik rendkívül praktikus támadás.

Továbbá, van értelme csinálni agresszívabb fojtás az admin számlák, mivel ezek a legvonzóbb belépési pontok

RÉSZ: Elosztott brute force támadások

Csakúgy, mint félre, fejlettebb támadók megpróbálják megkerülni bejelentkezés fojtás által „terjed a tevékenységek”:

  • Szétosztása a kísérletek egy botnet, hogy megakadályozzák IP cím megjelölési

  • Ahelyett szedés egy felhasználót, és megpróbálja a 50.000 leggyakoribb jelszavak (ami nem tudnak, mert a mi fojtás), akkor vedd a leggyakoribb jelszót, majd próbálja ellen 50.000 felhasználó helyett. Így, nem csak ők kap körül maximális próbálkozások intézkedések, mint a CAPTCHA és belépés szabályozása, a siker lehetősége is emelkedik, hiszen az 1. számú leggyakoribb jelszó sokkal nagyobb valószínűséggel száma 49,995

  • Térköz a bejelentkezési kérelmet az egyes felhasználói fiókok, mondjuk, 30 másodperces időközönként, hogy settenkedik a radar

Itt a legjobb gyakorlat lenne az adatgyűjtés több sikertelen bejelentkezések, az egész rendszerre kiterjedő , és egy mozgóátlag webhelye rossz login gyakorisága, mint az alapját egy felső határ, amit majd elő az összes felhasználó.

Túl elvont? Hadd fogalmazzam:

Tegyük fel, hogy helyén volt átlagosan 120 rossz bejelentkezési naponta az elmúlt 3 hónapban. Felhasználva, hogy (mozgóátlag), hogy a rendszere a rendszer a globális korlát 3-szor, hogy - pl. 360 sikertelen próbálkozás egy 24 órás időszakban. Aztán, ha az összes sikertelen kísérlet az összes fiókra meghaladja azt a számot egy napon belül (vagy még jobb, nyomon követi a gyorsulás és a trigger a kiszámított küszöbértéket), akkor aktiválódik az egész rendszerre kiterjedő bejelentkezés fojtás - azaz rövid késedelem minden felhasználó számára (még, kivéve a cookie-felhasználóneveket és / vagy biztonsági CAPTCHA azonosítók).

Azt is írt egy kérdést részleteket, és egy igazán jó vita, hogyan lehet elkerülni a trükkös pitfals elrémisszem elosztott brute force támadások

RÉSZ: A kéttényezős hitelesítés és hitelesítés szolgáltatók

Bizonyítványok veszélybe kerülhet, akár hasznosítja, jelszavakat írt le, és elveszett, laptopok kulcsokkal, hogy ellopják, vagy belépő felhasználókat bejelentkezések be adathalász oldalak. Bejelentkezések tovább lehet védeni a kéttényezős hitelesítést, amelyek használata out-of-band tényezők, mint például az egyszer használatos kód kapott egy telefonhívást, SMS, alkalmazás vagy dongle. Számos szolgáltató kéttényezős hitelesítési szolgáltatások.

A hitelesítés lehet teljesen delegált egy-sign-on szolgáltatás, ahol egy másik szolgáltató fogantyúk gyűjtő adatokat. Ez megnöveli a probléma, hogy egy megbízható harmadik félnek. A Google és a Twitter is nyújt szabványokon alapuló SSO szolgáltatásokat, míg a Facebook egy hasonló szabadalmaztatott megoldás.

Must-olvasni LINKEK Web hitelesítés

  1. OWASP útmutató Authentication / OWASP Authentication Cheat Sheet
  2. Dos és ne tegye a Client Authentication a weben (nagyon olvasható MIT kutatási papír)
  3. Wikipedia: HTTP cookie-
  4. Személyes tudás kérdése visszakapcsolási hitelesítés: A biztonsági kérdések a korszak Facebook (nagyon olvasható Berkeley kutatási papír)
Válaszolt 25/01/2009 12:27
a forrás felhasználó

szavazat
146

Először is, egy erős fenntartással, hogy ez a válasz nem a legmegfelelőbbek erre a pontos kérdést. Meg biztosan nem a legjobb válasz!

Megyek előre, és említést Mozilla javasolt BrowserID (vagy talán pontosabban, az Ellenőrzött e-mail jegyzőkönyv ) szellemében megállapító upgrade jobb megközelítések a hitelesítés a jövőben.

Majd összefoglalom ezt így:

  1. A Mozilla egy nonprofit az értékeket , amelyek illeszkednek jól találni jó megoldás erre a problémára.
  2. A valóság ma, hogy a legtöbb weboldal használja az űrlap alapú hitelesítés
  3. Forma-alapú hitelesítés van egy nagy hátránya, ami fokozott kockázata adathalászat . A felhasználók arra kérik, hogy érzékeny információt adjon át egy olyan területen, távirányítóval szervezet, hanem egy terület által ellenőrzött User Agent (böngésző).
  4. Mivel a böngészők implicit megbízható (az egész elképzelés a User Agent, hogy nevében eljárjon a felhasználó), akkor segíthet a helyzet javításában.
  5. Az elsődleges erő tartja vissza haladás itt telepítési holtpont . Megoldásokat kell bontani olyan lépést, amely némi járulékos előnye a saját.
  6. A legegyszerűbb decentralizált eljárás is azonosság van építve az internetes infrastruktúra a domain nevet.
  7. A második szinten kifejező identitás, mindegyik domén kezeli a saját, a számlák.
  8. Az űrlap „számla @domain” tömör és támogatja a széles körű protokollok és URI rendszereket. Egy ilyen azonosítót, persze, a legtöbb általánosan elismert e-mail címet.
  9. E-mail szolgáltatók már de facto elsődleges identitás szolgáltatók online. Jelenlegi jelszó visszaállítás flow általában hagyja, átveszi az irányítást egy fiókot, ha bizonyítani tudja, hogy ellenőrizzék, hogy a fiók társított e-mail címét.
  10. Az Ellenőrzött e-mail jegyzőkönyv javasolták, hogy egy biztonságos módszer alapján nyilvános kulcsú titkosítás, a folyamat egyszerűsítését annak bizonyítása, hogy a B domén, hogy van egy fiókot domain A.
  11. Mert böngészők nem támogatják a Verified Email jegyzőkönyvet (jelenleg mindet), Mozilla egy alátétet, amely végrehajtja a protokoll kliensoldali JavaScript kódot.
  12. Az e-mail szolgáltatások, amelyek nem támogatják a Verified Email jegyzőkönyvet, a protokoll lehetővé teszi a harmadik feleket, hogy a megbízható közvetítő, azt állítva, hogy ők már ellenőrizte a felhasználó tulajdonában egy fiókot. Ez nem kívánatos, hogy a nagy számú ilyen harmadik fél számára; ezt a képességet célja csak, hogy frissítési lehetőséget, és ez sokkal előnyösebb, ha az e-mail szolgáltatást nyújtanak ezen állítások magukat.
  13. Mozilla kínál saját szolgáltatási fellépni egy ilyen megbízható harmadik félnek. Szolgáltatók (azaz érintett felek) a végrehajtó Verified Email jegyzőkönyvet dönthet úgy, hogy megbízik a Mozilla állításaival, vagy sem. Mozilla szolgáltatás ellenőrzi a felhasználók fiók tulajdonjogát a hagyományos eszközök e-mailt küld egy megerősítő linket.
  14. Szolgáltatók természetesen kínál ez a protokoll, mint egy lehetőséget mellett bármilyen más módszer (ek) a hitelesítés ők kívánnak nyújtani.
  15. Egy nagy felhasználói felület előnye kérik itt a „identitás választó”. Amikor egy felhasználó egy olyan hely, és úgy dönt, hogy hitelesítse, a böngésző megjeleníti azokat a válogatott e-mail címét ( „személyes” a „munka”, „politikai aktivizmus”, stb) is használhatnak, hogy azonosítsák magukat az oldalon.
  16. A másik nagy előny felhasználói felület kérik ennek részeként erőfeszítés segíti a böngésző többet megtudni a felhasználói munkamenetet - kik vagy bejelentkezve jelenleg elsősorban - így lehet megjeleníteni, hogy a böngésző króm.
  17. Mivel a megosztott jellegű ez a rendszer, hogy elkerüli lock-in nagyobb oldalak, mint a Facebook, Twitter, Google, stb Minden egyén saját maguk domént, és ezért jár a saját identitását szolgáltatót.

Ez nem feltétlenül „űrlap alapú hitelesítést honlapok”. De annak érdekében, hogy átmenet a jelenlegi norma űrlap alapú hitelesítés valami biztonságosabb: böngésző által támogatott hitelesítési.

Válaszolt 08/08/2011 16:32
a forrás felhasználó

szavazat
71

Nem hiszem, hogy a fenti válasz „rossz”, de vannak nagy területek hitelesítés nem érintettük (vagy inkább a hangsúly a „hogyan hajtsák végre a cookie ülés”, nem pedig „milyen lehetőségek állnak rendelkezésre, és mik a kereskedelem off”.

Saját javasolt módosításokat / válaszok

  • A probléma inkább fiókbeállításnál mint jelszó ellenőrzése.
  • A használata két tényező authenitication sokkal biztonságosabb, mint a több okos eszközök jelszó titkosítás
  • Ne próbálja meg végre a saját bejelentkezési űrlap vagy adatbázis tárolására jelszavakat, kivéve, ha a tárolt adatok értéktelen a fiók létrehozását és saját előállítású (azaz, a web 2.0 stílusban, mint a Facebook, Flickr , stb)

    1. Digest Authentication egy szabványokon alapuló megközelítés támogatja az összes fontosabb böngészők és szerverek, hogy nem küld egy jelszót még egy biztonságos csatornán.

Ezzel elkerülhető, hogy szükség van „ülés”, vagy a cookie-kat a böngésző maga újratitkosításához kommunikáció minden egyes alkalommal. Ez a leginkább a „kis” fejlesztési megközelítés.

Azonban én nem ajánlom ezt, kivéve a nyilvános, kis értékű szolgáltatások. Ez olyan kérdés, néhány más választ a fenti - nem próbálja egy újbóli végrehajtásához szerver oldali authetication mechanizmusok - ez a probléma már megoldódott, és támogatja a legtöbb nagy böngészők. Ne használja a cookie-kat. Ne tárolja semmit a saját kézzel sodort tárol. Csak kérni, egy kérés, ha a kérés autheticated. Minden mást kell támogatni konfiguráció és megbízható külső szoftver.

Így ...

Először is összekeverik a kezdeti fiók létrehozása (jelszóval) az újbóli ellenőrzését a jelszót később. Ha én vagyok a Flickr és a webhely létrehozása az első alkalommal, az új felhasználó hozzáfér a nulla értéket (üres tárhely). Én tényleg nem érdekel, ha az ember a fiók létrehozásakor hazudott a nevüket. Ha hozok létre egy fiókot a kórház intranet / extranet, az értéke abban rejlik, hogy minden orvosi feljegyzések, és így nem törődnek a személyazonosságát (*) A számla alkotója.

Ez a nagyon-nagyon kemény rész. Az egyetlen tisztességes megoldás a bizalmi háló. Például, ha csatlakozik a kórház orvos. Létrehoz egy weboldalt üzemelteti valahol a fotódat, útlevélszámát és a nyilvános kulcsot, és a hash őket a privát kulcs. Ezután keresse fel a kórház és a rendszergazda nézi az útlevelét, látja, ha a fénykép megfelel neked, majd hash weboldal / fotó hash a kórház privát kulcs. Mostantól tudjuk biztonságosan bonyolíthatják kulcsok és zsetont. Ahogy az, aki bízik a kórházban (ott van a titkos szósz BTW). A rendszergazda is kapsz egy RSA dongle vagy más kéttényezős hitelesítést.

De ez egy csomó gond, és nem túl web 2.0. Azonban ez az egyetlen biztonságos módja annak, hogy hozzon létre új fiókokat, hogy hozzáférjenek az értékes információkat, hogy nem magától létre.

  1. Kerberos és SPNEGO - single sign on mechanizmusok egy megbízható harmadik fél - alapvetően a felhasználó ellenőrzi ellen egy megbízható harmadik félnek. (NB ez semmilyen módon nem az, hogy nem lehet megbízni OAuth )

  2. SRP - egyfajta okos jelszó hitelesítés nélkül egy megbízható harmadik fél. De itt van bekerülni a birodalmakban „biztonságosabb használata, a kétlépcsős azonosítással, még ha ez drágább”

  3. SSL kliens oldalon - így az ügyfelek a nyilvános kulcs tanúsítvány (támogatás az összes főbb böngészők - de számos kérdést vet fel több kliens gépen biztonság).

A végén ez egy kompromisszum - mi az ára a biztonság megsértése vs végrehajtásának költsége sokkal biztonságosabb megközelítés. Egy nap, lássuk a megfelelő PKI széles körben elfogadott és így nincs több saját hengerelt hitelesítési formák és adatbázisok. Egy nap...

Válaszolt 08/08/2011 17:29
a forrás felhasználó

szavazat
48

Amikor tördeljük, ne használja a gyors hash algoritmusok, mint például az MD5 (sok hardver implementáció létezik). Használnunk, mint például SHA-512. A jelszavak, lassabb hash jobbak.

Minél gyorsabban hozhat létre hash annál gyorsabb a brute force-ellenőrző működhet. Lassabb hash ezért lassul brute kényszerítve. A lassú hash algoritmus teszi brute kényszerítve praktikus hosszabb jelszavak (8 számjegy) +

Válaszolt 09/08/2011 00:07
a forrás felhasználó

szavazat
120

Csak gondoltam megosztani ezt a megoldást, hogy én találtam, hogy működik, csak finom.

Úgy hívom a Dummy Field (bár én még nem találták fel ezt így nem írja jóvá nekem).

Röviden: csak be kell helyeznie ezt be <form>, és ellenőrizze, hogy legyen üres a érvényesítésekor:

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

A trükk az, hogy bolond egy bot, és azt hiszik kell adatokat bevinni a kívánt területen, ezért is nevezték a bemenet „email”. Ha már van egy olyan területen, az úgynevezett e-mail, amit használ akkor próbáljon elnevezése a dummy területén valami mást, mint a „társaság”, „telefon” vagy „EMAILADDRESS”. Csak válassz valami tudod hogy nem kell, és mi úgy hangzik, mint amit az emberek általában megtalálják logikus, hogy töltse ki a webes formában. Most elrejteni a inputterületen CSS vagy JavaScript / jQuery - kedvedre legjobb - csak nem a bemeneti type, hogy hiddenkülönben a bot nem fog esni azt.

Ha érvényesítése formában (akár kliens vagy szerver oldalon) ellenőrizze, hogy a dummy mező került kitöltésre, hogy meghatározza, ha azt küldeni egy ember vagy egy bot.

Példa:

Abban az esetben, ember: A felhasználó nem fogja látni a dummy mező (esetemben neve „email”), és nem kísérli meg kitölteni. Tehát az érték a dummy területen kell még üres, ha a nyomtatványt küld.

Abban az esetben, bot: A bot megjelenik egy mező, amelynek típusa textés neve email(vagy akármi is nevezik), és logikusan megpróbálja kitölteni a megfelelő adatokat. Nem érdekel, ha stílusú beviteli formát néhány divatos CSS, web-fejlesztők csinálni egész idő alatt. Bármi legyen is az értéket a dummy mező, akkor nem érdekel, amíg ez nagyobb, mint a 0karakter.

Régebben ezt a módszert vendégkönyv kombinálva CAPTCHA , és én még nem láttam egyetlen spam hozzászólás óta. Én használt egy CAPTCHA-egyetlen megoldás előtt, de végül ez vezetett a mintegy öt spam hozzászólások óránként. Hozzáadjuk a dummy mező formájában leállt (legalábbis eddig) az összes spam megjelenését.

Azt hiszem, ez is lehet használni csak finom belépés / hitelesítés formában.

Figyelmeztetés : Természetesen ez a módszer nem 100% bolond bizonyíték. Botok lehet programozni, hogy figyelmen kívül hagyja beviteli mezők és a stílus display:nonevonatkoztatható. Azt is meg kell gondolni az emberek, akik valamilyen formában az automatikus kiegészítést (mint a legtöbb böngésző beépített!) Automatikus kitöltéséhez minden űrlapmezőket számukra. Lehet ugyanúgy vegye fel a dummy területen.

Azt is változhat ez egy kicsit hagyja a dummy mező látható, de határain kívül képernyőn, de ez teljesen rajtad múlik.

Légy kreatív!

Válaszolt 22/05/2012 13:11
a forrás felhasználó

szavazat
46

Egy jó cikk a reális jelszóerősségi becslés:

Dropbox Tech Blog »Blog Archive» zxcvbn: reális jelszóerősségi becslés

Válaszolt 08/11/2012 12:15
a forrás felhasználó

szavazat
41

A kedvenc szabálya tekintetében hitelesítési rendszerek: használja a jelszavak, a jelszavakat nem. Könnyen megjegyezhető, nehéz feltörni. További info: Coding Horror: A jelszavak vs. Pass kitételek

Válaszolt 24/11/2012 22:15
a forrás felhasználó

szavazat
10

Szeretném felvenni egy nagyon-fontos megjegyzés:

  • „A vállalati, intra- net beállítás,” a legtöbb, ha nem minden a fentiek esetleg nem érvényesek!

Számos vállalat telepíteni „belső használatra” honlapok, amelyek hatékonyan, „vállalati alkalmazások”, hogy ez megtörténjen hajtottak végre ekben. Ezek az URL-ek (állítólag ...) csak úgy lehet megoldani belül „a társaság belső hálózat.” (Ami a hálózati varázslatosan magában foglalja az összes VPN-kapcsolatban „utcai harcosok”.)

Amikor egy felhasználó kötelességtudóan kapcsolódik a fent említett hálózaton identitásukat ( „hitelesítés”) is [már ...] „meggyőzően ismert”, ahogy az ő engedélye ( „engedély”) , hogy bizonyos dolgokat ... mint például. .. „eléréséhez ezt a weboldalt.”

Ez a „hitelesítés + engedély” szolgáltatás nem vehető igénybe a különböző technológiák, mint például az LDAP (Microsoft OpenDirectory) , vagy a Kerberos.

A saját point-of-view, egyszerűen tudja: hogy bárki , aki jogosan szelek-up az Ön weboldalán kell kísérnie [környezet változó varázslatosan tartalmazó ...] a „token”. ( Azaz nincs ilyen jelképes kell lennie azonnali kizáró 404 Not Found.)

A token értéke nincs értelme akkor, de amennyiben igény mutatkozik rá, a „megfelelő eszközök álljanak rendelkezésre”, ami a web-site „[authoritatively] kérjen meg valakit, aki ismeri (LDAP, stb ...)” bármely és minden ( !) kérdést, hogy lehet. Más szóval, akkor nem élni magát olyan „saját nevelésű logika.” Ehelyett érdeklődik a hatóság és az implicit bízik a döntését.

Aha ... ez elég mentális kapcsolót a „vad-és gyapjas interneten.”

Válaszolt 29/04/2015 01:06
a forrás felhasználó

szavazat
20

Szeretnék adni egy javaslatot, amit használnak, amely a mélységi védelem. Nem kell, hogy ugyanazt a auth & auth rendszer adminisztrátorok rendszeres felhasználók. Tudod van egy külön bejelentkezési űrlap külön url végrehajtó külön kódot kéri, hogy megadja magas jogosultsággal. Ez lehet olyan döntéseket, hogy lenne egy teljes fájdalom az általános felhasználók számára. Az egyik ilyen, hogy már használt, hogy valóban zavarják a bejelentkezési URL-t rendszergazdai hozzáférést és e-mailben az admin az új URL-t. Leállítja brute force támadás rögtön mint az új URL lehet tetszőlegesen bonyolult (nagyon hosszú véletlen sorozatot), de az admin felhasználó egyetlen kellemetlenség követi a linket az e-mail. A támadó nem tudja, hogy hol, még POST.

Válaszolt 18/07/2015 01:18
a forrás felhasználó

szavazat
12

I Ne kövesse tudom, hogy ez volt a legjobb választ adni, hogy ez egy válasz, vagy megjegyzést. Azt választotta az első lehetőséget.

Ami a poing RÉSZ: Elfelejtett jelszó Funkcionalitás az első válasz, azt, hogy egy pont Timing támadások.

A Jegyezze meg jelszavát formák, a támadó esetleg ellenőrizze a teljes listája e-mailek és felismerni, amely regisztrálva van a rendszerben (lásd az alábbi linket).

Ami a elfelejtett jelszó Form, hozzátenném, hogy ez egy jó ötlet, hogy azonos idők közötti sikeres és unsucessful lekérdezések némi késéssel funkcióval.

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

Válaszolt 16/08/2015 17:31
a forrás felhasználó

szavazat
5

Használja OpenID Connect vagy a felhasználó által kezelt hozzáférés .

Mivel semmi sem hatékonyabb, mint a nem csinálja egyáltalán.

Válaszolt 10/08/2016 13:27
a forrás felhasználó

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more