it-swarm-eu.dev

Jaké osvědčené postupy by měly být použity v přihlašovacím skriptu PHP?

Chci přepsat své přihlašovací skripty pro webové stránky klientů, aby byly bezpečnější. Chci vědět, jaké osvědčené postupy do toho mohu implementovat. Ovládací panely chráněné heslem jsou v hojnosti, ale jen velmi málo z nich implikuje osvědčené postupy, pokud jde o psaní kódu, rychlost a bezpečnost.

Budu používat PHP a databázi MYSQL).

Použil jsem md5, ale vidím, že sha256 nebo sha512 by byly lepší (spolu se zabezpečeným hashem a solí).

Některé přihlašovací skripty zaznamenávají IP adresu během relace nebo dokonce uživatelského agenta, ale chci se tomu vyhnout, protože není kompatibilní s proxy servery.

Také jsem trochu za osvědčeným postupem při používání relací v PHP 5 (naposledy jsem si přečetl, byl PHP 4)), takže některé doporučené postupy s tím by buď nápomocný.

Dík.

27
baritoneuk

Nejlepší nápad je neobnovit kolo. Ale chápu, že ve světě PHP PHP) může být obtížné najít vysoce kvalitní komponentu, která to již dělá (i když jsem si docela jistý, že rámce implementují takové věci a jejich implementace jsou již testovány , solidní, s kontrolou kódu atd.)

Pokud z nějakých důvodů nemůžete použít rámec, zde je několik návrhů:

Návrhy týkající se zabezpečení

  • Použijte PBKDF2 nebo Bcrypt, pokud můžete . Je to hotovo.

    Odůvodnění: oba algoritmy mohou proces hašování libovolně zpomalit, což je přesně to, co chcete, když hashovací hesla (rychlejší alternativy znamenají snazší hrubou sílu). V ideálním případě byste měli upravit parametry tak, aby se proces v průběhu času zpomalil a zpomalil na stejném hardwaru, zatímco bude vydán nový, rychlejší hardware.

  • Pokud nemůžete, alespoň nepoužívejte MD5/SHA1. Nikdy. Zapomeň na to . Místo toho použijte například SHA512. Použijte také sůl.

    Odůvodnění: MD5 a SHA1 jsou příliš rychlé. Pokud má útočník přístup k vaší databázi obsahující hash a má (a to zejména) výkonný stroj, je vynucení hesla rychlé a snadné. Pokud neexistují žádné soli, zvyšuje se šance, že útočník najde skutečné heslo (což by mohlo způsobit další poškození, pokud by bylo heslo znovu použito někde jinde).

  • V PHP 5.5.0 a novější, použijte password_hash a password_verify .

    Odůvodnění: vyvolání funkce poskytované rámcem je snadné, takže se snižuje riziko chyby. U těchto dvou funkcí nemusíte přemýšlet o různých parametrech, jako je hash. První funkce vrací řetězec single, který lze poté uložit do databáze. Druhá funkce používá tento řetězec k ověření hesla.

  • Chraňte se před hrubou silou . Pokud uživatel odešle nesprávné heslo, když už před 0,01 sekundami zaslalo další nesprávné heslo, je to dobrý důvod, proč jej zablokovat. Zatímco lidé mohou psát rychle, pravděpodobně nemohou být rychle to rychle.

    Další ochranou by bylo stanovení limitu poruch za hodinu. Pokud uživatel zadal 3600 nesprávných hesel za hodinu, 1 heslo za sekundu, je těžké uvěřit, že se jedná o oprávněného uživatele.

    Odůvodnění: Pokud jsou vaše hesla hašována nezabezpečeným způsobem, hrubá síla může být velmi účinná. Pokud jsou hesla uložena bezpečně, hrubá síla stále ztrácí prostředky serveru a šířku pásma sítě, což legitimním uživatelům způsobuje nižší výkon. Brute force detekce není snadné vyvinout a napravit, ale pro každý, ale malý systém, to stojí za to.

  • Nežádejte své uživatele, aby měnili své heslo každé čtyři týdny. To je velmi nepříjemné a se snižuje zabezpečení, protože podporuje post-it zabezpečení.

    Odůvodnění: myšlenka, že nutit hesla ke změně každých n týdnů chrání systém před hrubou silou, je chybná. Útoky hrubou silou jsou obvykle úspěšné během několika sekund, minut, hodin nebo dnů, takže měsíční změny hesla nejsou relevantní. Na druhé straně si uživatelé špatně pamatují hesla. Pokud je navíc budou muset změnit, pokusí se použít velmi jednoduchá hesla nebo si pouze poznamenají svá hesla na post-it.

  • Auditujte všechno pokaždé. Ukládejte přihlašovací údaje, ale nikdy neukládejte hesla do protokolu auditu. Ujistěte se, že protokol auditu nelze změnit (tj. Můžete přidat data na konci, ale neměnit stávající data). Ujistěte se, že protokoly auditu jsou pravidelně zálohovány. V ideálním případě by protokoly měly být uloženy na dedikovaném serveru s velmi omezujícími přístupy: pokud je napaden jiný server, útočník nebude schopen vymazat protokoly, aby skryl svou přítomnost (a cestu, kterou během útoku provedla).

  • Nepamatujte si pověření uživatele v souborech cookie, pokud to uživatel nepožádá (zaškrtávací políčko „Pamatovat si mě“ musí být ve výchozím nastavení nezaškrtnuto, aby se předešlo lidským chybám).

Snadné návrhy použití

  • Nechte uživatele zapamatovat si heslo , pokud chce, i když většina prohlížečů tuto funkci již používá.
  • Nepoužívejte přístup Google, když je místo požadavku na uživatelské jméno a heslo uživatel někdy požádán pouze o heslo , uživatelské jméno je již zobrazeno v a <span/>. Prohlížeče nemohou v tomto případě vyplnit pole pro heslo (alespoň Firefox to nemůže udělat), takže se musí odhlásit, poté se přihlásit pomocí běžného formuláře vyplněného prohlížečem.
  • Nepoužívejte vyskakovací okna povolená skriptem pro přihlášení. Rozbije prohlížeče pomocí funkcí pro zapamatování hesla (a ve všech případech saje).
  • Nechte uživatele zadat buď své uživatelské jméno, nebo její e-mailovou adresu . Když se zaregistruji, někdy se uživatelské jméno, které chci zadat, již vezme, takže si musím vymyslet nové. Mám všechny šance zapomenout na toto jméno za dvě hodiny.
  • U přihlašovacího formuláře vždy udržujte odkaz na funkci „Zapomněl jsem heslo“ . Nezobrazovat je pouze v případě, že se uživatel nepřihlásil: uživatel, který si vůbec nepamatuje své heslo, netuší, že musí podat nesprávné heslo, aby viděl odkaz „Zapomněl jsem heslo“.
  • Nepoužívejte zabezpečení post-it .
  • Nevytvářejte hloupá pravidla týkající se hesla, aby bylo slabší . Příklad: „Vaše heslo musí začínat malým písmenem.“; "Vaše heslo nesmí obsahovat mezery."
21
  1. Váš web by měl používat HTTPS. V žádném případě byste neměli prezentovat přihlašovací stránku nebo přijímat přihlášení z nešifrovaného připojení.
  2. Vaše soubory cookie by měly být omezeny pouze na HTTP a na zabezpečená připojení, pokud používáte HTTPS.
  3. Proces přihlášení by neměl trvat méně než 2 sekundy (1, pokud si myslíte, že 2 sekundy jsou příliš dlouhé). Používejte bezpečné hash při ukládání a ověřování hesel, a použijte sůl, která je těžší uhodnout. Pokud je to možné, použijte bcrypt. V opačném případě použijte jiný iterovaný hash.
  4. Nikdy nikdy nevytvářejte databázové dotazy žádným způsobem, který vyžaduje použití funkcí, jako je mysql_real_escape_string. Nikdy nepoužívejte řetězové zřetězení k vytvoření vašeho dotazu. Používejte připravené, parametrizované dotazy. Většina, pokud ne všechny, ovladače DB pro PHP jej podporují. Pokud nemáte ' Nevím, jak to udělat, trávit nějaký čas učením, jak prepare, bind a execute pomocí jakékoli DB, kterou používáte. Je to pouze jistý způsob, jak se chránit před SQL injekcí. PDO to podporuje.
  5. Vyzvěte své uživatele, aby nepoužívali stejné heslo, jaké používají pro svůj e-mail. Připomeňte jim, že pokud je váš web ohrožen a pokud na obou místech používají stejné heslo, může někdo zneužít jeho e-mail.
6
greyfade
  • Nikdy nepoužívejte algoritmy hashování MD5 nebo SHA1. Vždy se držte novějších, jako je SHA512
  • Vždy používejte silnou náhodně generovanou sůl
  • Nikdy neposílejte svým uživatelům e-mailová hesla, a to ani v případě zapomenutého hesla
  • Nikdy nepoužívejte funkce mysql_ *. Jsou odepisovány dlouho. Držte se CHOP
  • Nikdy neukládejte hesla v relacích nebo cookies
1
Robin Thomas

Použijte solený jednosměrný hash (nejlépe SHA512 pomocí http://au2.php.net/manual/en/function.hash.php ) ... tímto způsobem, pokud někdo prolomí vaši databázi , i když znají sůl, nemohou extrahovat hesla (bez tabulky Rainbow, což by bylo pro SHA512 looong).

Použijte HTTPS.

Neposílejte potvrzení e-mailem uživatelské jméno/heslo e-mailem zpět uživateli při registraci.

Pokud povolíte soubory cookie pro „zapamatovat si mě“ - přidejte další přihlašovací údaje pro přístup k funkcím správy a úprav profilu.

Pokud uživatel dostane heslo špatně, neříkej, že dostal heslo špatně (řekněme, že dostal 'uživatelské jméno nebo heslo špatně' za všech okolností) - tedy méně stop o tom, jaká platná uživatelská jména jsou platná.

Vyzkoušejte a implementujte přezdívku versus přihlašování - tak méně uživatelů zobrazí přihlašovací jméno v seznamech uživatelů.

1
HorusKol

Zde je několik rad: ujistěte se, že k souborům cookie nelze přistupovat pomocí JS, abyste zabránili krádeži, viz Ochrana vašich souborů cookie: HttpOnly článek od Jeffa Atwooda

... Díky chytré konstrukci se špatně tvarovaná adresa URL podaří vyplazit kolem sanitizéru. Konečný vykreslený kód při prohlížení v prohlížeči načte a provede skript z tohoto vzdáleného serveru.

... kdokoli načte tuto stránku profilu uživatele s vloženým skriptem, právě nevědomky přenesl své soubory cookie prohlížeče na zlý vzdálený server!

Jak jsme již zjistili, jakmile někdo má soubory cookie vašeho prohlížeče pro daný web, mají v zásadě klíče od království pro vaši identitu ...

0
James