it-swarm-eu.dev

Zabezpečení heslem v databázích - dnes stále nejlepší praxe?

Možný duplikát:
Jakou metodu hashování heslem mám použít?

Existuje mnoho skvělých příspěvků o zabezpečení heslem v databázích o přetečení zásobníku a na jiných webech, a protože jsem v tomto zcela nový, strávil jsem docela dost hodin pokusem se o něm v posledních dnech dozvědět více. Existuje však tolik různých návrhů a osvědčených postupů, že jsem stále velmi zmatený ...

Také existuje stále mnoho starších příspěvků z let 2007–2010 atd. Když jsem viděl, jak rychle se věci mění, nejsem si jistý, zda je stále běžné používat je tak, jak to navrhují. Takže jsem chtěl shrnout, co jsem našel v příspěvcích, a pak se zeptat, jestli tato metoda, kterou jsem našel, byla osvědčeným postupem ...

Nejde tedy o průvodce, ale o shrnutí, vím, že je to velmi základní a pokud se vyskytnou chyby, opravte mě!

  1. Stačí zmínit: nikdy byste neměli ukládat hesla prostého textu :)
  2. „Jednosměrná“ hashovací hesla, takže nikdo nemůže vidět prostý text. Když uživatel zadá heslo, hash to stejným způsobem a porovnat s hashed pass v databázi.
  3. Kromě hash hesla byste měli také sůl. Sůl přidáte do prostého řetězce hesel a hash nový řetězec. Pokud je prosté heslo slabé, přidáním soli je delší a silnější.
  4. Sůl by měla být navíc náhodná (četl jsem, že pojem „sůl“ znamená, že je stejně náhodný, jinak se nazýval „klíč“?). Je to proto, aby se zabránilo útokům tabulky Rainbow, protože by útočník musel pro každou sůl vytvořit jednu tabulku, která je časově mnohem nákladnější atd. Také pokud dva uživatelé mají stejné heslo, nebudete je rozpoznávat, pokud použijete náhodné soli.
  5. Sůl není tajemstvím! Ukládá se do databáze vedle hesla hashed. Pravděpodobně však nebude nejlepší použít časové razítko, e-mailovou adresu uživatele nebo cokoli jiného, ​​co je s uživatelem spojeno, jako náhodná sůl. Jako důvod je to např. uvedl, že uživatelé mají tendenci používat stejná hesla na více webech/službách. Takže sůl by měla být náhodný řetězec, nejlépe jsem četl, bylo 64-bitové?
  6. Dalším krokem je přidání iterace k hašovacímu procesu (1000 nebo více smyček), takže sůl je přidána k heslu a pak jsou hash znovu a znovu, což znamená, že pro přihlášení čeká pouze zlomek sekundy in, ale shrnuje, pokud máte v databázi asi 10 000 záznamů.
  7. Pokud přidáte klíč webu, uložený např. jako globální var kromě soli. Vždy byste však měli předpokládat, že útočníci mají také přístup k vašemu systému souborů.
  8. Hašovací algoritmy: Zjistil jsem, že už není bezpečné používat MD5, SHA1 a další slabé metody ...

Takže existují různé názory na to, kdo bude používat SHA256, SHA512? Pokud použijete hash_hmac? Někteří říkají ano: ( http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/ ) Někteří říkají, že používání knihoven je jediné bezpečným způsobem ... a pak jednou nebo dvakrát v příspěvku jsem četl, že nepoužívám knihovny jako brypt nebo bublinové ryby?

Je opravdu nutné použít knihovnu nebo je např. metoda takhle dost:

function hash_password($password, $nonce) {

  for ($i = 0; $i < 5000; $i++) {
    $hashed_pass = hash_hmac('sha512', $hashed_pass . $nonce . $password, $site_key);
    }
  return $hashed_pass;
}

Mnoho lidí říká, že nevymýšlejte své vlastní algo, takže jsem trochu vystrašený, abych použil něco vynalezeného.

Dokážu si představit, že je těžké předvídat, ale jak dlouho lze metodu používanou dnes považovat za dostatečně bezpečnou?

AKTUALIZACE: Děkuji vám za vaši skvělou zpětnou vazbu. Jak vidím, jeden hlavní bod chybí: mnozí z vás řekli: zabezpečení heslem, což znamená, že silné heslo je základní. Myslím, že jsem dostal zprávu, ještě jednou děkuji! :)

UPDATE 2: Jen pro dokončení jsem našel následující kód na http://www.lateralcode.com/creating-a-random-string-with-php/ , který používám pro generování náhodných solí :

function Rand_string( $length ) {
    $chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!§$%&/().-:;_#+*[]{}="; 

    $size = strlen( $chars );
    for( $i = 0; $i < $length; $i++ ) {
        $str .= $chars[ Rand( 0, $size - 1 ) ];
    }

    return $str;
}

$random_salt= Rand_string(20);
47
Chris

Obecné informace:

Pěkná otázka, ale vše, co mohu říci, je, že to zcela záleží na použití. Pokud jej použijete pouze pro malé webové stránky, existuje velká šance, že vás navštíví pouze „skriptové děti“, v tom případě stačí dnes i prostá SHA1 se solí. V tomto případě je 5-8-10 let nebo možná i více zcela v pořádku, děti do skriptů se do toho opravdu nedostanou, pokud uvidí, že se nemohou snadno vloupat. Pokud bude váš web z nějakého důvodu napaden - peněžní, atd., Měli byste použít nejnovější dostupné funkce. V tomto případě bych dokonce „riskoval“ použití neoficiální, ale již přenesené funkce. Právě teď existuje soutěž SHA3, pro webové stránky, které v nich budou mít vysoké peníze, bych použil jednoho z 5 konkurentů těchto.

Body, které říkám, jsou důležité:

1. použijte náhodnou sůl, možná i 20 znaků. Prolomení hesel je mnohem těžší, ai když jsou rozbitná, stojí to příliš dlouho, než to stojí za to.
2. použijte SHA-1, SHA-2 nebo WHIRLPOOL. S dobrou solí je MD5 v pořádku, ale přesto to navrhuji.
. můžete použít libovolnou skvělou kryptografii, pokud jsou hesla uživatelů triviální. Musíte se ujistit, že používají neslovníky, dlouhá hesla s velkými písmeny, malými písmeny, čísly a symboly, jinak je snadno rozbitné hrubou silou. Možná se domníváte, že by mohli být nuceni každý rok měnit heslo.

Do kódu:

Opakování mnohokrát by mohlo být užitečné, ale nemyslím si, že je potřeba 5000. 3 pro normální bezpečnost je dobrá, nebo 100, možná 1000 by mohlo fungovat, ale myslím, že 5000 je prostě příliš mnoho. SHA-256 je dobrý, ale můžete použít algoritmus speciálně vyvinutý pro tento účel, viz komentáře.

2
axiomer

Zapomněl jsi na jednu maličkost:

Síla hesla.

Pouze 2 slova, která nadváží celé vaše skvělé téma.

Stackoverflow skutečně obsahuje stovky témat, která vám říkají, abyste použili tento algoritmus hashování a náhodné soli.
A jen velmi málo vysvětluje, že se slabým heslem bude vaše osmimístná ochrana seznamu, všechny mimořádně bezpečné hashovací hmac-chmak-bumblemak s 2048 bajty dlouhou solí budou během několika sekund zlomeny.

Pokud jde o chudé uživatele, kteří si nepamatují $#%H4df84a$%#R hesla - stačí, aby nepoužívali heslo, ale a passphrase.

Is it a good day today, Winkie? Používá různá písmena a heslo s doporučenou složitostí, ale mnohem snadněji zapamatovatelné.

Fráze by samozřejmě neměla být tak běžná jako běžná hesla jako „Joe“ nebo „123“.
"Dobré ráno", "Ach můj bože! Zabili Kennyho!" fráze by se neměly vyhýbat.
Ale přidáním nějaké osobnosti by bylo v pořádku:
Oh My God! They moved Cthulhu! vypadá docela dost

Další věcí, kterou je třeba zmínit, je zabezpečená komunikace mezi serverem a prohlížečem
Bez něj lze jednoduché heslo snadno „čichat“ na kterémkoli ze směrovačů zapojených do komunikace.

SSH nebo implementace autorizace Digest není o nic méně zásadní.

10

Hašovací funkce obecného účelu (MD5, SHA1, SHA256) s dobrým hashem může být vzhledem k aktuálnímu výpočetnímu výkonu dostatečně bezpečná pro většinu menších webů. Mooreův zákon však zajistí, že i dobrá hesla budou v blízké budoucnosti vystavena útokům hrubou silou. Problém je v tom, že hašovací funkce lze vypočítat příliš rychle. Nejlepší řešení je použít bcrypt nebo PBKDF2 s velkým počtem iterací. Bcrypt vs PBKDF2 bylo diskutováno na http://security.stackexchange.com .

Někteří lidé si mohou myslet, že je to pro většinu webů nadměrné, ale pamatujte, že hesla jsou stále znovu používána a že heslo je obvykle něco, co se nezmění, dokud nedojde k problému.

Doporučení:

  1. Použijte bcrypt nebo PBKDF2. NEPOUŽÍVEJTE kandidáty na SHA3. Mohou obsahovat bezpečnostní díry, které dosud nebyly objeveny.
  2. Použijte náhodnou sůl k ochraně před útoky na stůl Rainbow.
  3. Vynutit uživatelům výběr přístupového hesla.

Více informací

5
tony

Funkce hash_hmac() by byla dobrá volba, může dokonce překonat problémy slabšího algoritmu hash. Jediným problémem je, že je příliš rychlý. To znamená, že při dostatečném výkonu procesoru (cloud) je možné vytvářet různé tabulky Rainbow, což je důvod pro iteraci. Pokud potřebujete tuto vysokou bezpečnost, můžete změřit čas, který iterace potřebují, a pak vypočítat počet iterací potřebných pro daný čas.

Upravit:

Iterací lze tento problém vyřešit, mělo by být provedeno tak, aby bylo možné počet iterací později zvýšit, aniž by se stávající hash zneplatnil. Toto je nutné přizpůsobit se novému budoucímu hardwaru, ale vyžaduje uložení parametrů hashování společně s hashem.

Algoritmus bcrypt hash byl navržen tak, aby splňoval tyto požadavky, napsal jsem malý příklad, jak používat bcrypt with PHP 5. , snažil jsem se to komentovat, takže je možné pochopit, co se děje.

2
martinstoeckli