Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Pavelko 15. 06. 2017, 22:51:15
-
Caute, akym sposobom hashujete hesla? Robim na jednej appke pre kamosa, a pozeral som na nete best practices, a dosiel som k dvom moznostiam implementaciam (pre info, vyvijam v .NETe).
Postup je v oboch identicky. Vygeneruje sa SALT, a spolu s heslom sa zahashuju pomocou nejakeho algoritmu, napr AES. Nasledne sa do tabulky v DB ulozi hash a vygenerovany salt, spravne?
A spat k sposobom na ktore sa pytam, prvy bol generovanie saltu a hashovanie hesla na strane aplikacie, druhy sposob na strane SQL Servera. Ktory vyuzivate vy, respektive ktory mi odporucate? Dik.
-
Postup je správně. Microsoft má ukázku pro ASP.NET (http://"https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/consumer-apis/password-hashing"). Pro extra bezpečnost lze použít SCRAM (http://"Salted Challenge Response Authentication Mechanism"), kde heslo nikdy neopouští počítač uživatele, ale je to trochu těžší na implementaci.
AES není hashovací, ale šifrovací algoritmus. Hashovací algoritmus je třeba SHA-2.
Generovat hash vždy na straně aplikace, SQL by nikdy nemělo vidět nehashované heslo, protože když dojde třeba ke fluktuaci zátěže disku, mohlo by skončit ve slow logu.
-
Argon2, vítěz https://password-hashing.net/. Když ne ten, tak scrypt. Když ani ten nejde, bcrypt. Přinejhorším PBKDF2. Rozhodně si nevytvářej vlastní ukládací schéma.
-
V ideálním případě by hash hesla měl vzniknout už u klienta a server by se nehashované heslo neměl nikdy dozvědět. Ale budu řešit současný reálný stav, kdy se na bezpečnost kašle.
Sůl bych raději generoval v aplikaci, máte pak víc pod kontrolou její parametry, např. jak bude náhodná. Také omezíte prostředí, kde se heslo vyskytuje jen v otevřeném tvaru (bude to jen vaše aplikace, databáze otevřené heslo nikdy neuvidí).
Dále, když chcete hesla zabezpečovat tímhle způsobem, bych doporučil kombinovat dvě soli – jednu náhodnou individuální pro každé heslo (která bude uložená spolu s tím heslem), a druhou globální, která vůbec nebude uložená v databázi. Pokud by pak došlo k úniku dat z databáze, nemůže útočník hádat heslo ani jednoho vybraného uživatele, protože mu bude chybět ta globální sůl. (Samozřejmě to není všespásné, pokud útočník získá administrátorská práva na serveru, kde běží aplikace i databáze, získá jak databázi tak globální sůl. Ale bohužel jsou překvapivě časté úniky, kdy útočník získá jen data z databáze.)
Také bych doporučoval ukládat si k heslu a soli i ID „algoritmu“, kterým jste to vytvořil (klidně jen pořadové číslo verze). To vám umožní v budoucnosti plynule změnit třeba hashovací algoritmus, globální hash nebo prostě celý způsob, jak „hesla“ ukládáte.
-
http://gigi.nullneuron.net/gigilabs/secure-authentication-with-bcrypt/
-
Dále, když chcete hesla zabezpečovat tímhle způsobem, bych doporučil kombinovat dvě soli – jednu náhodnou individuální pro každé heslo (která bude uložená spolu s tím heslem), a druhou globální, která vůbec nebude uložená v databázi.
Tady se trochu bojím, že je to zbytečná práce navíc. Pokud má někdo na to, aby vykradl databázi a vůbec začal smysluplně luštit hesla, stejně s největší pravděpodobností začne právě u klienta, kterého rozebere na součástky a začne si dělat představu, co tím chtěl básník říct a co může očekávat. Takže taková globální hardcoded sůl v klientovi pravděpodobně sofistikovaný útok nezastaví, ani výrazně neztíží. Pomohlo by to snad jen v případě, že se taková databáze někde záhadně objeví, bez jakékoliv informace, co je to zač a odkud to pochází. To by navíc nesmělo být patrné ani z té databáze samotné. A to se mi zdá lehce mimo představa...
-
Pokud má někdo na to, aby vykradl databázi a vůbec začal smysluplně luštit hesla, stejně s největší pravděpodobností začne právě u klienta, kterého rozebere na součástky a začne si dělat představu, co tím chtěl básník říct a co může očekávat.
Pokud se ke klientovi dostane. Dnes se velice často používají webové aplikace, kde je klientem databáze webový server – a už bylo velmi mnoho úniků dat z databáze, kdy útočník nic jiného než data z databáze neměl.
Samozřejmě, pokud by to byla klient-server aplikace, kdy uživatelská aplikace přímo přistupuje k SQL databázi, to je něco jiného, tam nemá smysl globální hash do klienta ukládat. Ale u takové aplikace je otázka, zda má vůbec smysl řešit zabezpečení na takové úrovni, že se budou solit a hashovat hesla.