Definitivní průvodce k ověřování webových stránek založeným na formulářích

hlasů
4k

ověřováním založeným na formulářích pro webové stránky

Jsme přesvědčeni, že přetečení zásobníku by neměl být zdrojem informací pro velmi specifické technické otázky, ale také pro obecné pokyny, jak řešit variací na společných problémů. „Autentizace Form založený na webových stránkách“ by měl být v pořádku téma pro takový experiment.

Mělo by zahrnovat témata, jako jsou:

  • Jak se přihlásit
  • Jak se odhlásit
  • Jak zůstat přihlášen
  • Správa cookies (včetně doporučených nastavení)
  • SSL / HTTPS šifrování
  • Jak se ukládání hesel
  • Pomocí tajné otázky
  • Forgotten username funkčnost / password
  • Použití nonces , aby se zabránilo cross-site požadavek padělání (CSRF)
  • OpenID
  • checkbox „Pamatuj si mě“
  • Browser automatického dokončení uživatelských jmen a hesel
  • Tajné adresy (public URL chráněné digest)
  • Kontrola sílu hesla
  • Ověření E-mail
  • a mnohem více o autentizaci na bázi formuláře ...

To by nemělo zahrnovat věci jako:

  • Rolí a oprávnění
  • základní ověřování HTTP

Prosím, pomozte nám:

  1. navrhovat podtémat
  2. Předkládání dobrých článků o tomto tématu
  3. Úprava oficiální odpověď
Položena 02/08/2008 v 20:51
zdroj uživatelem
V jiných jazycích...                            


12 odpovědí

hlasů
3k

ČÁST I: jak se přihlásit

Budeme předpokládat, že jste již víte, jak vytvořit přihlašovací heslo + HTML formulář, který vysílá hodnoty na skript na straně serveru pro autentizaci. Následující sekce se bude zabývat vzory pro zvukovou praktické Díla, a jak se vyhnout nejběžnější bezpečnostní úskalí.

HTTPS nebo ne HTTPS?

Není-li spojení je již bezpečný (to znamená, tunelového přes HTTPS pomocí SSL / TLS), budou vaše hodnoty přihlašovacího formuláře se zasílají v podobě prostého textu, který umožňuje někdo odposlouchávání na trati mezi prohlížečem a webovým serverem budou moci číst přihlašovacích údajů při jejich průchodu přes. Tento typ odposlechů provádí rutinně vládami, ale obecně nebudeme zabývat ‚vlastněna‘ jiné vodiče než říci toto: Pokud jste něco důležitého chránit pomocí HTTPS.

V podstatě jediný praktický způsob, jak se chránit před odposlech / paket čichání během přihlašování je pomocí HTTPS nebo jiný certifikát založený na šifrovací systém (například TLS ), nebo osvědčený a testovaný systém výzva-odpověď (například Diffie-Hellman založené SRP). Jakákoliv jiná metoda může být snadno obejít pomocí odposlechu útočníkem.

Samozřejmě, pokud jste ochotni se dostat trochu nepraktické, můžete také využívat nějakou formu systému dvoufaktorová autentizace (například Google Authenticator, fyzickou ‚studená válka styl‘ číselník, nebo identifikovat generátor dongle RSA). Při správném použití, mohlo by to fungovat i pomocí nezabezpečeného připojení, ale je těžké si představit, že dev by byl ochoten realizovat dvoufaktorové auth, ale ne SSL.

(Ne) Roll-your-own šifrování JavaScript / zatřiďování

Vzhledem k nenulové náklady a vnímanou technickou obtížnost nastavení SSL certifikát na svých webových stránkách, někteří vývojáři jsou v pokušení vrátit své vlastní in-prohlížeči hash nebo šifrovací programy, aby se zabránilo průchodu cleartextových přihlášení přes nezabezpečenou drátem.

I když to je ušlechtilá myšlenka, že je v podstatě k ničemu (a může být bezpečnostní chyba ), pokud je v kombinaci s jedním z výše uvedených - to znamená, že buď zajištění řádek s silného šifrování nebo pomocí ověřené a testovány výzva-odpověď mechanismus (pokud nevíte, co to je, jen vím, že je to jeden z nejvíce obtížné dokázat, nejvíce obtížné navrhnout a nejobtížněji implementovat koncepty v oblasti digitální bezpečnosti).

I když je pravda, že hash hesla mohou být účinné proti vyzrazení hesla , to je náchylné k přehrání útoky typu man-in-the-middle útoky / únosy (v případě, že útočník může aplikovat několik bajtů do nezajištěného HTML stránky, než se dostanou k Vašemu browser, mohou jednoduše komentář mimo zatřiďování v JavaScriptu), nebo brute-force útoky (protože jste podal útočník jak uživatelské jméno, sůl a hash hesla).

Kryptogramy proti lidskosti

Kryptogramy jsou určeny mařit jeden konkrétní kategorii útoku: automatické slovníku / hrubou silou pokusů a chyb, bez lidské obsluhy. Není pochyb o tom, že se jedná o skutečnou hrozbou, ale existují způsoby, jak se vypořádat s tím, že hladce nevyžadují CAPTCHA, konkrétně řádně navržené straně serveru schémat login škrticí - budeme diskutovat o těch později.

Vím, že CAPTCHA implementace nejsou vytvořeny stejně; často nejsou lidé, řešitelné, většina z nich jsou ve skutečnosti neúčinné proti botům, všechny z nich jsou neúčinné proti levného třetího světa práce (podle OWASP , aktuální rychlost manufaktura je $ 12 za 500 testů), a některé implementace může být technicky nezákonný v některých zemích (viz OWASP Authentication tahák ). Pokud je nutné použít CAPTCHA pomocí Google reCAPTCHA , protože je OCR tvrdý ze své podstaty (protože už OCR-chybně knižní prověřování používá) a snaží velmi těžké být uživatelsky příjemný.

Osobně se přikláním k vyhledání kryptogramy nepříjemné, a použít je pouze jako poslední možnost v případě, že uživatel se nepodařilo přihlásit několikrát a škrticích zpoždění je maxxed ven. To se stane dost zřídka, aby byly přijatelné, a to posiluje systém jako celek.

Uložení hesla / Ověření přihlášení

To může nakonec být obecně známo, po všech těch vysoce medializované hacky a úniky dat uživatelů jsme viděli v posledních letech, ale je třeba říci: Neukládejte hesla do prostého textu v databázi. uživatelských databází jsou stále hacknut, unikly nebo shromážděné prostřednictvím SQL injection, a pokud jste ukládání raw, otevřený text hesla, která je okamžitý konec hry pro vaše přihlašovací bezpečnost.

Takže pokud nemůžete uložit heslo, jak si zkontrolovat, zda je login + heslo kombinace účtovány z přihlašovacího formuláře je správná? Odpověď je hash pomocí klíčovou funkci derivační . Kdykoliv je vytvořen nový uživatel nebo heslo se změní, budete mít heslo a spusťte jej přes KDF, jako je Argon2, bcrypt, scrypt nebo PBKDF2, otáčením cleartextových heslo ( „correcthorsebatterystaple“) do dlouhé, náhodné vypadající řetězce , což je mnohem bezpečnější pro uložení v databázi. K ověření přihlášení, můžete spustit stejnou funkci hash na zadané heslo, tentokrát předáním soli a porovnat výsledný hash řetězec s hodnotou uloženou v databázi. Argon2, bcrypt a scrypt sklad soli s datovým obsahem již. Podívejte se na tento článek na sec.stackexchange pro podrobnější informace.

Důvod, proč se používá sůl, protože hash samo o sobě nestačí - budete chtít přidat takzvaný ‚sůl‘ na ochranu proti hash duha tabulek . Sůl účinně brání dvě hesla, které přesně odpovídají byly ukládány jako stejnou hodnotu hash, brání celá databáze snímané v jednom běhu, pokud útočník se spuštěním heslo tipovací útok.

Kryptografický hash by neměly být používány pro ukládání hesel, protože uživatel vybral hesla nejsou dostatečně silné (tj obvykle neobsahují dostatek entropie) a útok heslem hádání by mohla být dokončena v relativně krátkém čase útočník s přístupem k hash. To je důvod, proč se používá KDF - to účinně „protáhnout klíč“ , což znamená, že každý heslo uhodnout útočníkovi umožňuje zahrnuje iterací na hash algoritmu vícekrát, například 10.000 krát, takže útočníka heslo hádání 10.000 krát pomalejší.

Data Session - „Jste přihlášen jako Spiderman69“

Jakmile server ověřil přihlašovací jméno a heslo proti vaší databázi uživatelů a našli shodu, systém potřebuje způsob, jak si uvědomit, že prohlížeč byl ověřen. Tento fakt by měl být vždy jen uložen na straně serveru v datech relace.

Pokud jste obeznámeni s daty relace, tady je návod, jak to funguje: Jeden náhodně generovaný řetězec je uložen v propadlého cookie a použít k odkazu na sběr dat - dat relace - který je uložen na serveru. Pokud používáte rámce MVC, to je bezpochyby ovládal již.

Pokud je to možné, ujistěte se, že cookie relace má zabezpečené a HTTP pouze příznaky nastavené, když poslal do prohlížeče. Vlajka HttpOnly poskytuje určitou ochranu proti cookie být čteno útoku XSS. Bezpečný příznak zaručuje, že cookie je odeslán zpět pouze přes HTTPS, a proto chrání před síťovými útoky šňupání. Hodnota cookie nesmí být předvídatelné. Tam, kde je uveden cookie odkazování na neexistující relace, musí být jeho hodnota ihned vyměnit, aby se zabránilo fixaci relace .

Část II: Jak zůstat přihlášen - Neslavný „Remember Me“ checkbox

Přetrvávající Přihlásit Cookies ( „zapamatovat“ funkcí) jsou nebezpečném prostoru; Na jedné straně jsou zcela stejně bezpečná jako konvenční přihlašovacích údajů, když uživatelé pochopili, jak s nimi nakládat; a na druhé straně jsou obrovské bezpečnostní riziko v rukou neopatrných uživatelů, kteří mohou použít na veřejných počítačích a zapomenete odhlásit, a kteří nemusí vědět, jaký prohlížeč cookies nebo jak je odstranit.

Osobně jsem rád trvalé přihlášení na webových stránkách navštěvuji pravidelně, ale vím, jak s nimi pracovat bezpečně. Pokud jste si jisti, že uživatelé vědí stejné, můžete použít trvalé přihlášení s čistým svědomím. Pokud tomu tak není - dobře, pak můžete přihlásit k filozofii, že uživatelé, kteří jsou neopatrní s jejich přihlašovacích údajů ji přivedl na sebe v případě, že si pirát. Není to, jako bychom jít domů naše uživatele a strhnout všechny ty facepalm vyvolávající Post-It s hesly, které jsou už nastoupené na hraně svých monitorů, a to buď poznamenává.

Samozřejmě, že některé systémy si nemohou dovolit mít žádné účty napadeny; pro takové systémy, není tam žádný způsob, jak můžete ospravedlnit má trvalé přihlášení.

Pokud se rozhodnete pro realizaci trvalé přihlašovací soubory cookie, je to, jak to udělat:

  1. Za prvé, vzít nějaký čas na čtení článku Paragon Initiative na toto téma. Budete se muset dostat spoustu prvků pravých a článek dělá skvělou práci vysvětlovat každý.

  2. A jen proto, aby zopakoval jedno z nejčastějších úskalí, NESKLADUJTE přetrvávající přihlašovací cookie (token) v databázi, pouze hash IT! Přihlašovací Token je Password Equivalent, takže v případě, že útočník sebral své ruce na databázi, by se mohlo využívat žetony k přihlášení na jiný účet, stejně jako by se jednalo o cleartextových kombinace login-password. Proto použít hash (podle https://security.stackexchange.com/a/63438/5002 slabé hash bude stačit pro tento účel) při ukládání trvalé přihlášení tokeny.

ČÁST III: pomocí tajného otázky

Neprovádějí ‚tajné otázky‘ . Funkce ‚tajnou otázky‘ je bezpečnostní anti-vzor. Číst noviny z odkazu číslo 4 ze seznamu must-číst. Můžete požádat Sarah Palin o tom druhém, po jejím Yahoo! E-mailový účet dostal hacknutý během předchozí prezidentské kampaně, protože odpověď na její bezpečnostní otázku bylo ... „Wasilla High School“!

I s uživatelem zadaných otázek, je velmi pravděpodobné, že většina uživatelů si zvolí buď:

  • A ‚standard‘ tajná otázka, stejně jako jméno za svobodna matky nebo oblíbené zvířátko

  • Jednoduchý kus trivia, že by někdo mohl zvednout ze svého blogu, LinkedIn profil nebo podobný

  • Veškeré otázky, které je snazší odpovědět, než hádání své heslo. Které jsou pro každé slušné heslo, je každá otázka můžete představit

Závěrem lze říci, bezpečnostní otázky jsou ze své podstaty nebezpečné prakticky ve všech svých podobách a variacích, a neměl by být použit v režimu autentizace z jakéhokoli důvodu.

Skutečným důvodem, proč bezpečnostní otázky ani existovat ve volné přírodě je, že pohodlně ušetřit náklady na několik telefonní hovory od uživatelů, kteří nemají přístup k jejich e-maily se dostat k reaktivaci kódu. To na úkor bezpečnosti a Sarah Palinové pověst. Stojí za to? Asi ne.

ČÁST IV: Zapomenuté heslo Funkčnost

Už jsem zmínil, proč byste nikdy neměli používat bezpečnostní otázky pro manipulaci zapomenutých / ztracených uživatelských hesel; to také samozřejmé, že byste nikdy neměli na e-mailu uživatelům jejich skutečné hesla. Existují nejméně další dva až příliš časté úskalí, aby se zabránilo v této oblasti:

  1. Nenechte obnovit zapomenuté heslo k automatickým generováním silným heslem - taková hesla jsou notoricky těžké si vzpomenout, což znamená, že uživatel musí buď změnit, nebo si ho poznamenejte - řekněme, na zářivě žluté Post-It na okraji svého monitoru. Namísto stanovení nové heslo, stačí nechat uživatele vybrat novou hned - což je to, co chtějí dělat tak jako tak.

  2. Vždy hash ztraceného hesla kód / žeton v databázi. OPĚT , tento kód je dalším příkladem hesla ekvivalent, takže to musí být hash v případě, že útočník sebral své ruce na vaší databázi. Když je požadováno ztracen kód hesla, odeslat textovou kód na e-mailovou adresu uživatele, pak hash, uložte hash v databázi - a zahodit originál . Stejně jako hesla nebo trvalého přihlášení tokenu.

Poslední poznámka: Vždy zkontrolujte, zda je rozhraní pro vstup do ‚ztracenou kód heslem‘ je přinejmenším stejně bezpečný jako přihlašovací formulář sám, nebo útočník bude jednoduše použít tento přístup místo. Ujistit generovat velmi dlouho ‚ztratil kódy heslem‘ (například 16 malých a velkých písmen alfanumerických znaků) je dobrý začátek, ale za přidání stejného škrtící schéma, které děláte pro přihlašovacího formuláře samotného.

ČÁST V: Kontrola Síla hesla

Za prvé, budete chtít přečíst tento malý článek pro realitou: Těchto 500 Mezi nejčastější hesla

Dobře, tak možná v seznamu není kanonický seznam nejčastějších hesel na jakémkoli systému kdekoliv vůbec , ale je to dobré znamení toho, jak špatně si lidé budou vybírat svá hesla, pokud není prosazována politika na svém místě. Navíc seznam vypadá nebezpečně blízko k domovu, když porovnat jej veřejně dostupných analýz nedávno ukradených hesel.

Takže: Bez minimálních požadavků na sílu hesla, 2% uživatelů používá jeden z top 20 nejčastějších hesel. Význam: pokud by se útočník dostane pouhých 20 pokusů, bude 1 z 50 účtů na své webové stránky být crackable.

Mařit to vyžaduje výpočet entropie hesla a pak aplikovat práh. National Institute of Standards and Technology (NIST) Special Publication 800-63 má řadu velmi dobrých návrhů. , Která v kombinaci s analýzou slovníku a rozložení klávesnice (například ‚qwertyuiop‘ je špatné heslo), může odmítnout 99% všech špatně vybraných hesel na úrovni 18 bitů entropie. Jednoduše výpočtu sílu hesla a ukazovat vizuální ukazatel síly k uživateli je dobrá, ale nedostatečná. Pokud není vynucena, mnoho uživatelů bude s největší pravděpodobností ignorovat.

A na osvěžující vzít na uživatelské přívětivosti vysoce-entropie hesel, Randall Munroe je Síla hesla XKCD je vysoce doporučeno.

ČÁST VI: Much More - Nebo: Prevence Rapid-Fire pokusů o přihlášení

Za prvé, podívejte se na číslech: Rychlosti Password Recovery - Jak dlouho bude vaše heslo vstát

Pokud nechcete mít čas podívat se do tabulek v tomto odkazu, tady je jejich seznam:

  1. To trvá téměř žádný čas bezva slabé heslo, i když jste praskání to s počítadlem

  2. To trvá téměř žádný čas na crack alfanumerický 9-znakové heslo, pokud je malá a velká písmena

  3. To trvá téměř žádný čas rozlousknout složitý, symboly-and-dopisy-and-čísla, horní-and-malá písmena heslo, pokud je méně než 8 znaků (stolní PC mohou prohledávat celý keyspace až 7 znaků v otázkou několika dní nebo dokonce hodin)

  4. Bylo by však trvat nadměrné množství času rozlousknout i hesla 6 znaků, pokud jste byly omezeny na jeden pokus za sekundu!

Takže to, co se můžeme naučit z těchto čísel? No, hodně, ale můžeme se soustředit na nejdůležitější část: skutečnost, že brání velké množství rapid-fire po sobě jdoucích pokusů o přihlášení (tj. Hrubá síla útoku) ve skutečnosti není tak těžké. Ale brání mu pravdu , není tak jednoduché, jak se zdá.

Obecně řečeno, máte tři možnosti, které jsou všechny účinné proti brute-force útoky (a slovníkové útoky, ale protože jste již s použitím silného hesla politiky, neměly by být problém) :

  • Předloží CAPTCHA po N neúspěšných pokusech (otravné jako peklo a často neúčinné - ale já opakuji zde)

  • Uzamykání účtů a vyžaduje ověření e-mailem poté, co N neúspěšných pokusech (to je DoS útok jednou dojde)

  • A konečně, login škrcení : to znamená, že nastavení časového zpoždění mezi pokusy po N neúspěšných pokusech (ano, DoS útoky jsou stále možné, ale alespoň jsou mnohem méně pravděpodobné, že i mnohem složitější se rozjet).

Best practice # 1: Krátká časová prodleva, která se zvyšuje s počtem neúspěšných pokusů, jako jsou:

  • 1 neúspěšný pokus = žádné zpoždění
  • 2 neúspěšných pokusů o = 2 s zpoždění
  • 3 neúspěšných pokusů o = 4 sec zpoždění
  • 4 neúspěšných pokusů o = 8 s zpoždění
  • 5 neúspěšných pokusů o = 16 s prodleva
  • atd.

DoS útoku toto schéma by bylo velmi nepraktické, protože výsledný čas uzamčení je o něco větší, než je součet předchozích časech uzamčení.

K objasnění: Zpoždění je to zpoždění, než se vrátí odpověď na prohlížeči. Je to spíš jako časový limit nebo žáruvzdorného období, během něhož se pokusy o přihlášení k určitému účtu nebo z konkrétní IP adresy nebudou přijaty nebo hodnoceny vůbec. To znamená, že správná pověření nevrátí v úspěšném přihlášení a nesprávná pověření nepovede ke zvýšení zpoždění.

Nejlepší postup # 2: Časová prodleva střední délky, která jde do účinku po N neúspěšných pokusech, jako je:

  • 1-4 neúspěšných pokusů = žádné zpoždění
  • 5 neúspěšných pokusů o = 15-30 min prodleva

DoS útoku toto schéma by bylo docela nepraktické, ale rozhodně uskutečnitelný. Také by mohlo být důležité si uvědomit, že toto zpoždění může být velmi nepříjemné pro oprávněného uživatele. Zapomnětlivý uživatelé nemají rádi vás.

Nejlepší postup # 3: Kombinace těchto dvou přístupů - buď pevné, krátká doba zpoždění, která jde do účinku po N neúspěšných pokusech, jako je:

  • 1-4 neúspěšných pokusů = žádné zpoždění
  • 5+ neúspěšných pokusů o = 20 sec zpoždění

Nebo rostoucí zpoždění s pevnou horní hranici, jako jsou:

  • 1 neúspěšný pokus = 5 sec zpoždění
  • 2 neúspěšných pokusech = 15 s prodleva
  • 3+ neúspěšných pokusů o = 45 sekund prodleva

Tento konečný režim byl převzat z osvědčených postupů a podnětů OWASP (odkaz 1 ze seznamu must-číst), a měly by být považovány za osvědčené postupy, a to i v případě, že je sice na restriktivní straně.

Jako pravidlo však, řekl bych: čím silnější vaše politika je heslo, tím méně budete muset uživatelům chyb se zpožděním. Pokud budete potřebovat silné (alfanumerické case-citlivý + požadovaná čísla a symboly) 9+ znaků hesla, mohl byste dát uživatelům 2-4 pokusy non-opožděné hesel před aktivací škrcení.

DoS útoku toto konečné schéma login škrtící by bylo velmi nepraktické. A jako poslední krok, vždy povolit trvalé (cookie) loginy (a / nebo přihlašovací formulář captcha-ověřeno) projít, takže legitimní uživatelé nebudou ani se zpožděním , zatímco útok probíhá . Tímto způsobem je velmi nepraktické DoS útok se stává velmi nepraktické útok.

Navíc, to dává smysl, aby se více agresivní škrcení na administrátorských účtů, protože ty jsou nejatraktivnější vstupní body

ČÁST VII: Distribuované Útoky hrubou silou

Stejně jako stranou, bude vyspělejší útočníci se snaží obejít přihlašovací škrcení by ‚rozšíření své činnosti‘:

  • Distribuci pokusy na botnetu, aby se zabránilo IP adresy základě hlášení

  • Spíše než výběrem jednoho uživatele a snaží se 50.000 nejčastější hesla (které nemohou, protože naše škrcení), budou vybírat z nejběžnějších heslo a zkuste to proti 50.000 uživatelů místo. Tak, a to nejen se jim dostat kolem maximálního pokusy opatření, jako kryptogramy a přihlášení škrcení, jejich šance na úspěch zvyšuje také, protože číslo 1 nejčastějším heslem je mnohem pravděpodobnější než počet 49.995

  • Rozteč přihlašovací požadavky pro každý uživatelský účet, řekněme, na rozdíl 30 vteřin, propašovat pod radarem

Zde je nejlepší praxe by přihlášení počet neúspěšných přihlášení, celý systém , a za použití klouzavý průměr ze špatně přihlášení frekvenci vašeho webu jako základ pro horní hranici, kterou pak ukládají na všechny uživatele.

Příliš abstraktní? Dovolte mi zopakovat:

Řekněme, že vaše webové stránky má v průměru 120 špatných přihlášení denně v průběhu posledních 3 měsících. Pomocí této (klouzavý průměr), váš systém by mohl nastavit globální limit 3 krát, že - tzn. 360 neúspěšných pokusů o více než 24 hodin. Potom, pokud je celkový počet neúspěšných pokusů u všech účtů převyšuje tento počet v jednom dni (nebo ještě lépe, sledovat rychlost akcelerace a spoušť na vypočtené limitní hodnoty), aktivuje celý systém přihlašovací škrcení - to znamená krátké zpoždění pro všechny uživatele (stále, s výjimkou cukroví přihlášení a / nebo záložní CAPTCHA přihlášení).

Také jsem vyslán na otázku další podrobnosti a opravdu dobrou diskusi o tom, jak se vyhnout záludné pitfals v odrážet distribuovaných útoku hrubou silou

Část VIII: dva faktory ověřování a ověřování Poskytovatelé

Pověření může být ohrožena, ať využije, hesla jsou sepsány a ztratil, notebooky s klíči odcizení nebo uživatelé zadáním přihlašovacích údajů do phishingových stránek. Přihlášení může být dále chráněn dvoufaktorové autentizace, které používají out-of-band faktory, jako jsou kódy na jedno použití přijatých od telefonního hovoru, SMS zprávy, aplikace, nebo hardwarový klíč. Několik poskytovatelé nabízejí služby dvoufaktorové autentizace.

Autentizace může být zcela přeneseny na single-sign-on služby, pokud úchyty jiného poskytovatele sběrné pověření. To tlačí problém do důvěryhodné třetí strany. Google a Twitter oba poskytují SSO služeb založených na standardech, zatímco Facebook má podobnou proprietární řešení.

Must-číst ODKAZY O web autentizace

  1. OWASP průvodce k ověřování / OWASP Authentication Cheat Sheet
  2. Dos a nedělat z Ověření klienta na webu (velmi čitelný MIT výzkum papír)
  3. Wikipedia: HTTP cookie
  4. Osobní znalost otázek pro nouzovou ověřování: Bezpečnostní otázky v éře Facebooku (velmi čitelný Berkeley výzkum papír)
Odpovězeno 25/01/2009 v 12:27
zdroj uživatelem

hlasů
382

definitivní článek

odesílání pověření

Jediný praktický způsob, jak poslat pověřovací 100% bezpečně je pomocí SSL . Pomocí JavaScriptu k hash heslo není bezpečné. Společné nástrahy na straně klienta hesla hash:

  • V případě, že spojení mezi klientem a serverem není šifrován, vše, co udělat, je zranitelný vůči útokům man-in-the-middle . Útočník by mohl nahradit příchozí javascript prolomit zatřiďování nebo poslat všechny přihlašovací údaje k jejich serveru, mohli poslouchat reakce klientů a vydávat se za uživatele dokonale, atd. Atd. SSL s důvěryhodných certifikačních autorit je navržen tak, aby se zabránilo útokům MITM.
  • Zakódovaných heslo přijaté serverem je méně bezpečné , pokud nechcete provést další, nadbytečné práce na serveru.

Je tu další bezpečná metoda zvaná SRP , ale je patentována (ačkoli to je svobodně licencované ) a existuje několik dobrých implementací k dispozici.

ukládání hesel

Nikdy ukládat hesla jako prostý text v databázi. Ani pokud nechcete starat o bezpečnost vašich vlastních stránek. Předpokládáme, že někteří z vašich uživatelů bude znovu použít heslo svého on-line bankovního účtu. Takže uložení hash hesla, a zahodit originál. A ujistěte se, že heslo neukáže v přístupových protokolech nebo protokoly aplikací. OWASP doporučuje používat Argon2 jako první volbou pro nové aplikace. Pokud toto není k dispozici, nebo PBKDF2 scrypt by měla být použita místo. A konečně, pokud žádná z výše uvedených jsou k dispozici, použijte bcrypt.

Hash samy o sobě rovněž nejistá. Například identické hesla znamenají shodné hodnoty hash - toto dělá hash vyhledávacích tabulek efektivní způsob, jak praskání spoustu hesel najednou. Místo toho uložit solené hash. Sůl je řetězec připojen na heslo před hash - pomocí jiné (náhodné) soli na jednoho uživatele. Sůl je veřejná hodnota, takže si můžete uložit s hash v databázi. Viz zde pro více informací o tomto.

To znamená, že nemůžete poslat uživateli svých zapomenutých hesel (protože máte jen hash). Neresetujte heslo uživatele, pokud jste ověření uživatele (uživatelé se musí prokázat, že jsou schopni číst e-maily odeslané na uloženou (a ověřeným) e-mailovou adresu).

Bezpečnostní otázka

Bezpečnostní otázky jsou nejisté - vyhnout se jejich použití. Proč? Cokoliv bezpečnostní otázku ano, heslo dělá lépe. Přečtěte si Část III: pomocí tajného otázky v @Jens Roland odpovědět tady v této wiki.

Cookies

Poté, co uživatel přihlásí, server pošle uživatel session cookie. Server může získat uživatelské jméno nebo id ze souboru cookie, ale nikdo jiný nemůže generovat takové cookie (TODO vysvětlit mechanismy).

Cookies mohou být unesen : oni jsou jen tak bezpečné jako zbytek stroji klienta a dalších komunikací. Ty lze přečíst z disku, přičichl v síťovém provozu, zvedl pomocí cross-site scripting útoku, phishingu z otrávené DNS, takže klient pošle své soubory cookie ke špatným servery. Neposílejte trvalé cookies. Cookies měla vypršet na konci relace klienta (prohlížeč zavřít nebo opustili své domény).

Chcete-li AutoLogin uživatelům můžete nastavit trvalý cookie, ale mělo by to být odlišný od cookie na plný relace. Můžete nastavit další příznak, který má uživatel automatické přihlášení, a je třeba se přihlásit k reálné pro citlivé operace. To je oblíbený u obchodních míst, které chtějí, aby vám bezproblémové, personalizovaný zážitek z nakupování, ale stále chránit své finanční údaje. Například, když se vrátíte k návštěvě Amazon, které vám ukázat stránku, která vypadá, jako jste přihlášeni, ale když jdete na objednávku (nebo změnit dodací adresu, kreditní karty atd), které vás požádá o potvrzení vaše heslo.

Finanční webové stránky, jako jsou banky a kreditní karty, na druhé straně, mají jen citlivé údaje a neměl by umožnit automatické přihlášení nebo režim nízké zabezpečení.

Seznam externích zdrojů

Odpovězeno 02/08/2008 v 21:40
zdroj uživatelem

hlasů
146

Za prvé, silné varování, že tato odpověď není nejvhodnější pro tento přesný dotaz. To by rozhodně neměl být nejlepší odpověď!

Půjdu napřed a zmínit Mozilla navrhované BrowserID (nebo snad přesněji Ověřená Email Protocol ) v duchu nalezení cesty pro upgrade na lepší přístupy na ověřování v budoucnu.

Budu to shrnout takto:

  1. Mozilla je nezisková s hodnotami , které sladit dobře při hledání dobrých řešení tohoto problému.
  2. Realitou dneška je, že většina webových stránek používá ověřování formulářů na bázi
  3. Ověřování forma bázi má velkou nevýhodu, která je zvýšené riziko výskytu phishingu . Uživatelé jsou vyzváni k zadání citlivých informací do prostoru ovládaného vzdálené entity, spíše než jen prostor pod kontrolou svého uživatelského agenta (prohlížeče).
  4. Vzhledem k tomu, prohlížeče jsou implicitně důvěryhodný (celá myšlenka User Agent je jednat jménem Uživatele), mohou přispět ke zlepšení této situace.
  5. Primární síla brzdí pokrok je zde nasazení zablokování . Řešení musí být rozložen do kroků, které poskytují určitý přírůstkový přínos na vlastní pěst.
  6. Nejjednodušší decentralizovaný způsob vyjadřování identity, která je integrována do internetové infrastruktury je název domény.
  7. Jako druhý stupeň vyjadřující identitu, každou doménu spravuje vlastní sadu účtů.
  8. Forma „účet @doména“ je stručné a podporován širokou škálu protokolů a schémat URI. Takový identifikátor, samozřejmě, nejvíce všeobecně uznávána jako e-mailovou adresu.
  9. poskytovatelé e-mailu jsou již de facto poskytovatelé primární identity online. Proudový reset hesla toky obvykle vám umožní převzít kontrolu nad účtem, jestli můžete dokázat, že jste kontrolu tohoto účtu přidružený e-mailovou adresu.
  10. Ověřený Email Protokol byl navržen poskytnout bezpečný způsob, založený na kryptografii veřejného klíče, pro zjednodušení procesu ukázala doméně B, že máte účet na doméně A.
  11. Pro prohlížeče, které nepodporují ověřených e-mailových protokolu (v současné době všichni), Mozilla poskytuje podložku, která implementuje protokol v na straně klienta JavaScript kód.
  12. U e-mailových služeb, které nepodporují ověřených e-mailových protokol, protokol umožňuje třetím stranám jednat jako důvěryhodný zprostředkovatel, tvrdit, že jste ověřili vlastnictví uživatele konta. Není žádoucí, aby se velké množství těchto třetích stran; Tato možnost je určena pouze umožnit cestu pro upgrade, a to je mnohem raději, že e-mailové služby poskytují tyto samotné tvrzení.
  13. Mozilla nabízí své vlastní služby, aby působil jako takovou důvěryhodnou třetí stranou. Poskytovatelé služeb (to znamená, že Spoléhání se strany), kterým se provádí ověřených e-mailových protokolu může zvolit důvěřovat Mozilly tvrzení nebo ne. Mozilla služba ověřuje účtu vlastnictví uživatelů pomocí obvyklých způsobů zasláním e-mailu s potvrzovací odkaz.
  14. Poskytovatelé služeb mohou samozřejmě nabízet tento protokol jako jedna z možností vedle jakýmkoli jiným způsobem (y) ověřování by mohly přát nabídnout.
  15. Velkým přínosem uživatelské rozhraní je zde požadován, je „volič identity“. Když uživatel navštíví web a rozhodne se ověřit, ukazuje jim, že jejich prohlížeč výběr e-mailových adres ( „osobní“, „práce“, „politický aktivismus“, etc.), mohou používat k ztotožnit se na stránky.
  16. Dalším velkým přínosem uživatelské rozhraní je vyhledáváno jakožto součást tohoto úsilí je pomáhat prohlížeč vědět více o relace uživatele - pro koho byla podepsána v jak v současné době, a to především - proto se může zobrazit, že v prohlížeči Chrome.
  17. Vzhledem k distribuované povaze tohoto systému, se vyhýbá lock-in na významných lokalit, jako je Facebook, Twitter, Google, atd Každý jedinec může vlastnit svou vlastní doménu, a proto působí jako své vlastní poskytovatele identity.

To není striktně „ověřováním založeným na formulářích pro webové stránky“. Ale je to snaha o přechod ze současného normou ověřováním založeným na formulářích něco bezpečnější: ověření prohlížeč podporován.

Odpovězeno 08/08/2011 v 16:32
zdroj uživatelem

hlasů
120

Jen jsem myslel, že toto řešení, které jsem našel, že můžeme spolupracovat v pohodě sdílet.

Nazval jsem to Dummy pole (i když jsem si to vymyslel to tak mě nemají úvěr).

Stručně řečeno: stačí vložit do vašeho <form>a zkontrolujte, že je prázdný při při ověřování:

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

Trik je oklamat bot, aby si mysleli, že má vložit data do požadovaného pole, to je důvod, proč jsem pojmenoval vstupní „e-mailu“. Pokud již máte pole s názvem e-mail, který používáte, měli byste zkusit pojmenovat fiktivní pole něco jako „společnost“, „telefon“ nebo „EMAILADDRESS“. Stačí si vybrat něco, co víte, že nepotřebujete, a to, co zní jako něco, co lidé by za normálních okolností najít logické vyplnit do webového formuláře. Nyní skrýt inputpole pomocí CSS nebo JavaScript / jQuery - ať vám vyhovuje nejlépe - prostě nemají nastavit vstup typedo hiddenjinak bot nebude padat na to.

Když ověřujete formulář (buď klienta nebo na straně serveru) Zkontrolujte, zda byl váš dummy pole byla vyplněna pro určení, zda to bylo poslat člověka nebo bot.

Příklad:

V případě člověka: uživatel nebude vidět fiktivní pole (v mém případě s názvem „e-mail“) a nebude se snažit, aby ji naplnit. Takže hodnota fiktivní pole by měl být stále prázdná, kdy bylo odeslání formuláře.

V případě bot: Bot uvidíte pole, jehož typ je texta jméno email(nebo co to je, co to nazval) a bude logicky pokusí se jej naplnit příslušnými údaji. Je jedno, jestli jste navrhl vstupní formulář s některými efektní CSS, web-vývojáři to po celou dobu. Bez ohledu na hodnotu v fiktivní pole je, že je to jedno, pokud je větší než 0znaků.

Použil jsem tuto metodu v knize návštěv v kombinaci s CAPTCHA , a já jsem od té doby neviděl jedinou spam příspěvek. Já použil CAPTCHA pouze řešení dřív, ale nakonec to skončilo asi pět spam příspěvků každou hodinu. Přidání figuríny pole v podobě přestal (alespoň doposud) veškeré nevyžádané pošty z objevit.

Věřím, že to může být také použit v pohodě s formou na login / ověření.

Varování : Samozřejmě tato metoda není 100% blázen důkaz. Roboty mohou být naprogramovány tak, aby ignorovat vstupní pole se stylem display:nonepůsobící na něj. Musíte také myslet na lidi, kteří používají nějakou formu auto-dokončení (jako většina prohlížečů mají vestavěný-in!) Do automatického vyplňování všech formulářových polí pro ně. Mohou stejně dobře vyzvednout fiktivní pole.

Můžete také měnit to se trochu tím, že opustí fiktivní pole viditelné, ale mimo hranice obrazovky, ale to je zcela na vás.

Být kreativní!

Odpovězeno 22/05/2012 v 13:11
zdroj uživatelem

hlasů
71

Nemyslím si, že výše uvedená odpověď je „špatné“, ale tam jsou velké plochy autentizace, které nejsou zmíněny (nebo spíše důraz je kladen na „jak implementovat cookie relací“, nikoli na „jaké možnosti jsou k dispozici a jaké jsou obchodní offs“.

Moje doporučené úpravy / odpovědi

  • Problém spočívá spíše v nastavení účtu, než v kontrole hesla.
  • Použití dvoufaktorové authenitication je mnohem bezpečnější než více chytrých pomocí šifrování hesel
  • Nesnažte se implementovat vlastní formulář pro přihlášení nebo skladování databáze hesel, pokud data jsou uložena, je bezcenný na vytvoření účtu a automaticky generovaný (to znamená, že web 2.0 styl, jako jsou Facebook, Flickr , atd)

    1. Digest Authentication je přístup na standardech založené podporována ve všech hlavních prohlížečích a servery, které nebudou posílat hesla i prostřednictvím zabezpečeného kanálu.

Tímto způsobem se vyhneme potřebě mít „sezení“, nebo soubory cookie jako prohlížeč sám se znovu šifrovaného spojení pokaždé. To je nejvíce „lehký“ vývoj přístup.

Nicméně, já nedoporučuji to, s výjimkou veřejných služeb, nízké hodnoty. Toto je problém s některými z dalších odpovědí výše - nesnažte server-side authetication mechanismy re-implementovat - tento problém byl vyřešen a je podporován většinou hlavních prohlížečů. Nepoužíváme cookies. Neskladovat nic ve své vlastní ručně válcované databázi. Jen se zeptejte, na vyžádání, pokud je žádost autheticated. Všechno ostatní by mělo být podpořeno konfigurace a třetích stran důvěryhodný software.

Tak ...

Za prvé, jsme matoucí počáteční vytvoření účtu (s heslem) s opakovanému ověření hesla později. Mám-li Flickr a vytvářet své stránky poprvé, nový uživatel má přístup k nulové hodnotě (prázdný webový prostor). Já opravdu jedno, jestli osoba vytváří účet lže o svém názvu. Budu-li vytvořit účet na nemocniční intranet / extranet, hodnota spočívá ve všech lékařských záznamech, a tak jsem se starat o identitě (*) na účet tvůrce.

To je velice těžká část. Pouze slušné řešení je síť důvěry. Například připojit k nemocnici jako lékař. Můžete vytvořit webovou stránku někde hostované s fotografií, své číslo pasu a veřejným klíčem, a hash je všechny pomocí soukromého klíče. Potom navštívit nemocnici a správce systému se dívá na svého pasu, vidí-li fotografii, kterou odpovídá, a pak hash na webové stránky / foto hash se soukromým klíčem nemocnice. Od této chvíle můžeme bezpečnou výměnu klíčů a tokeny. Jak může někdo, kdo důvěřuje nemocnici (tam je tajný recept BTW). Správce systému může také vám RSA dongle nebo jiný dvoufaktorové autentizace.

Ale to je hodně zmatků a nepříliš web 2.0. Nicméně, to je jediný bezpečný způsob, jak vytvářet nové účty, které mají přístup k cenným informacím, který není sám o sobě vytvořil.

  1. Kerberos a SPNEGO - single sign mechanismy s důvěryhodnou třetí stranou - v podstatě se uživatel ověřuje vůči důvěryhodné třetí strany. (NB to není žádným způsobem nedá věřit OAuth )

  2. SRP - druh chytré ověření hesla bez důvěryhodné třetí strany. Ale tady se dostáváme do říše „je bezpečnější použít dvě ověřování faktor, a to i v případě, že je nákladnější“

  3. SSL na straně klienta - poskytuje klientům klíčovou certifikát veřejné (podpora na všech hlavních prohlížečů - ale vyvolává otázky nad bezpečností klientském počítači).

V závěru je to kompromis - jaké jsou náklady na narušení zabezpečení vs náklady na realizaci více bezpečných přístupů. Jednoho dne, můžeme vidět správné PKI široce přijímaný, takže nic víc vlastní válcované ověřování formulářů a databází. Jednoho dne...

Odpovězeno 08/08/2011 v 17:29
zdroj uživatelem

hlasů
48

Když zatřiďování nepoužívají rychlé hash algoritmy jako je MD5 (existuje mnoho implementací hardware). Použít něco jako SHA-512. Hesel, pomalejší hashes jsou lepší.

Čím rychleji si můžete vytvořit hash, tím rychleji se některý brute force checker může fungovat. Pomalejší hashes proto zpomalí brutální nutit. Pomalý hash algoritmu bude hovado nutí nepraktické pro delší hesla (8 míst +)

Odpovězeno 09/08/2011 v 00:07
zdroj uživatelem

hlasů
46

Dobrý článek o realistický odhad pevnosti heslo je:

Dropbox Tech Blog »Blog Archive» zxcvbn: realistický odhad hesla síla

Odpovězeno 08/11/2012 v 12:15
zdroj uživatelem

hlasů
41

Můj oblíbený pravidlo v souvislosti s ověřováním systému: použít frázi, nikoliv hesel. Snadno zapamatovatelné, těžko bezva. Více info: Kódování Hrůza: Hesla vs. průsmyku vět

Odpovězeno 24/11/2012 v 22:15
zdroj uživatelem

hlasů
20

Chtěl bych přidat jeden návrh jsem použil, na základě hloubkové ochrany. Nemusíte mít stejný auth-auth systém pro administrátory jako běžní uživatelé. Můžete mít samostatný formulář pro přihlášení na samostatném URL vykonávající samostatnou kód pro požadavky, které se udělují vysoké privilegia. To lze učinit rozhodnutí, která by byla celková bolest běžným uživatelům. Jedním z takových, které jsem použil, je vlastně vyškrábat přihlašovací adresu URL pro přístup administrátora a e-mailu admin novou adresu URL. Přestanou pokusit útokem hrubou silou hned jak nová adresa URL může být libovolně obtížná (velmi dlouhý náhodný řetězec), ale svého administrátora o autorovi jen nepříjemnosti sleduje na odkaz v jejich e-mailu. Útočník již ví, kde dokonce poštou na adresu.

Odpovězeno 18/07/2015 v 01:18
zdroj uživatelem

hlasů
12

I dont't vědět, zda je to nejlepší odpověď na tuto jako odpověď nebo komentář. Jsem se rozhodla pro první možnost.

Pokud jde o Poing ČÁST IV: Zapomenuté heslo Funkčnost v první odpovědi bych dělat bod o načasování útoků.

V zapamatování hesla formulářů, útočník by mohly zjistit úplný seznam e-mailů a zjišťovat, které jsou registrovány v systému (viz odkaz níže).

Co se týče zapomenutého hesla formulář, bych dodal, že je to dobrý nápad, aby se rovnala časy mezi úspěšnými a unsucessful dotazů s nějakou funkcí zpoždění.

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

Odpovězeno 16/08/2015 v 17:31
zdroj uživatelem

hlasů
10

Chtěl bych přidat jeden velmi-důležitou poznámku:

  • „V podnikovém, uvnitř čisté prostředí,“ většina, ne-li všechny výše uvedené úvahy nemusí platit!

Mnohé společnosti nasadit „vnitřní použití pouze“ webové stránky, které jsou efektivně, „firemní aplikace“, které se dějí, aby byly realizovány prostřednictvím URL. Tyto adresy URL lze (prý ...) být vyřešen pouze v rámci „interní firemní sítě.“ (Což síť magicky zahrnuje všechny VPN-připojený ‚silniční válečníci.‘)

Když uživatel je poslušně připojené k výše uvedené sítě, jejich totožnost ( „autentizace“) je [již ...] „přesvědčivě známo“, jak je jejich povolení ( „oprávnění“), dělat určité věci ..., jako je. .. „přístup k této webové stránky.“

Tato služba „autentizační + autorizace“ může být několik různých technologií, jako jsou LDAP (Microsoft Open Directory) nebo Kerberos.

Z vašeho point-of-view, stačí vědět toto: že každý, kdo legitimně vine-up na vašich stránkách musí . „Token“ být doprovázen [prostředí variabilní magicky obsahující ...] ( Tj Absence takového tokenu musí být okamžité důvody 404 Not Found).

Hodnota tokenu je nemá smysl na vás, ale v případě potřeby, „vhodnými prostředky existují“, kterou vaše webové stránky mohou „[autoritativně] požádejte někoho, kdo ví (LDAP ... atd)“ o všech a každý ( !), otázka, kterou může mít. Jinými slovy, vy ne využít sami jakékoliv „home-pěstované logiku.“ Namísto toho se dotázat Úřad a bezvýhradně věřit svůj verdikt.

Hm ... je to docela duševní spínač z „divokého-and-vlněný internet.“

Odpovězeno 29/04/2015 v 01:06
zdroj uživatelem

hlasů
5

Použít OpenID Connect nebo uživatelem řízený přístup .

Jako nic je účinnější než to dělat vůbec.

Odpovězeno 10/08/2016 v 13:27
zdroj uživatelem

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