Ověření hashovaného hesla (DB, SHA-256)

On ten článek není kdovíjak dobrý, autor doporučuje použití rychlé funkce SHA-256 a nezmiňuje použití soli.
V dnešní době bych řekl, že je chybou použít cokoli jiného než funkce password_hash a password_verify.

Musíš vědět, jakým způsobem byl ten hash v databázi vypočítán. Pak stačí provést přesně tu samou posloupnost operací, jaká byla provedena při registraci.
V případě těch funkcí password_hash a password_verify se používají při generování hashe náhodná čísla, která se ukládají spolu s hashem, proto je pro ověření hesla nutná odlišná funkce než pro vytvoření hashe.

jakre:
Budu předpokládat, že je to funkce z článku pro SHA-256; pak je to:

A takto pro password_verify

jakre:
Funkce password_hash se o vše postará, všimni si výstupu té funkce (dvakrát zahashované heslo 123456):
2y udává algoritmus hashe; ten vlastně vybíráš pomocí toho parametru PASSWORD_DEFAULT (ano, máš použít tento parametr)
10 udává sílu hashe - jde o nějaký interní parametr použitého algoritmu
22 znaků za $ - náhodná sůl, která byla použita při hashování
zbytek - samotný hash hesla

Tedy funkce password_verify zná všechny podrobnosti proto, aby mohla hash z hesla vypočítat za stejných okolností (použít stejný algorithmus, stejnou sílu, stejnou sůl).

jakre:
„Chtěl bych se také zeptat, jestli byste mi doporučili přidat tzv. solení hesla.“
Ano. Ovšem, jak už juriad ukázal, už to děláš aniž bys o tom věděl. V tom je právě kása funkcí password_*, jsou vytvořeny tak, aby je bylo lehké použít a pokud je necháš v plně automatickém módu, jsou dostatečně bezpečné. Dokonce se předpokládá, že se jejich vnitřek bude časem měnit s tím, jak se postupně vyvíjejí algoritmy a bezpečnostní best practices. Bez zásahu do kódu, jen změnou PHP verze se mohou nové hashe vytvářet už novou bezpečnější metodou.

jakre:
„Znamená to, že i v případě úniku hashovaných hesel z databáze bude náročné dostat se k původnímu heslu?“
To záleží na použitém hashovacím algoritmu.
A na tom, jak bezpečné heslo uživatel má.

Dokud nemá bezpečnostní díru ten hashovací algoritmus, útočník nemá moc jiných možností, než hrubou sílu: Vytvářet hashe pro různá hesla a doufat, že se trefí.

Samozřejmě pokud by uživatel měl heslo 123456, útočník ho odhadne možná už na první pokus.

Sůl sice zabrání alespoň tomu, aby si útočník z databáze mohl jednoduše vytáhnout uživatele s triviálním heslem, ale pokud se útočník zaměří na jednoho uživatele s triviálním heslem, pochopitelně to heslo uhodne.

To samozřejmě možné je.

Na straně serveru se to riziko dá minimalizovat použitím HTTPS.

Pro ještě paranoidnější zabezpečení existují postupy, kdy se samotné heslo mezi klientem a serverem vůbec neposílá.

Joker:
Můžeš nastínit tyto postupy?

Viz challenge-response authentication.

Je tam ale nevýhoda, že de facto musí server znát otevřené heslo, resp. většinou je v databázi sice hash, ale jako heslo se používá ten hash (tj. útočníkovi teoreticky stačí znát hash hesla).
Funguje to tak, že při přihlášení server vytvoří nějaký jednorázový (pokaždé jiný) text, zapamatuje si ho a pošle klientovi. Na klientovi uživatel zadá heslo, to se použije jako klíč pro zašifrování serverem zaslaného textu a výsledek (text zašifrovaný heslem) se pošle zpátky na server.
Server vezme původní text, zašifruje ho skutečným uživatelovým heslem z databáze a podívá se, jestli se výsledek shoduje.

Je to odolné proti odposlechu, ale zase zranitelné na ukradení databáze. Při použití hashe (na serveru je hash, klient nejdřív udělá hash zadaného hesla a tím pak zašifruje text ze serveru) sice útočník nezjistí skutečné uživatelovo heslo, ale k přihlášení na server mu stačí i ten hash (na klientovi vynechá fázi hashování a podstrčí rovnou hash z databáze pro zašifrování toho textu).

Zdokonalit by to šlo použitím asymetrického šifrování, pak by to už byly normální digitální podpisy.
Uživatel by musel mít soukromý klíč a server by znal jeho veřejný klíč.
Přihlášení by fungovalo tak, že by server pošle nějaký jednorázový text a řekne „podepiš mi tohle“. Uživatel ten text digitálně podepíše a pošle zpátky na server. Ten pomocí jeho veřejného klíče ověří podpis a přihlásí uživatele.

Útočníkovi nepomůže odposlech (získá jen ten jednorázový text) ani krádež databáze (získá jen veřejný klíč), akorát uživatel se musí přihlašovat soukromým klíčem, což je složitější, než jen zadat heslo.

jakre:
„použiju pouze hashování hesla a HTTPS“
To jsou 2 rozdílné věci. Pokud by útočník odposlechnul hash toho hesla, mohl by se s ním přihlásit. A pokud tomu odposlechnutí má zabránit HTTPS, pak můžeš rovnou posílat nehashované heslo když tomu tak věříš.

V důsledku jde tedy o to, že pokud se útočníkovi povede odposlechnout ať už heslo, nebo jeho hash, může se jimi také přihlásit. Jediný důvod, proč by bylo lepší posílat jen hash hesla je ochrana lidí, kteří používají stejné heslo pro více služeb. Pokud by pro každou službu používali jiné heslo, bylo by úplně jedno, zda by se posílalo heslo nebo jeho hash.

Jinak ani HTTPS není ve 100% případů bezpečné. I proti němu existuje celá řada útoků. Pokud tě bezpečnost zajímá, mohu doporučit stránky Michala Špačka který se různými druhy bezpečnosti zabývá a hlavně o tom umí srozumitelně přednášet.

jakre:
„Nedovedu si představit obtížnost takového napadení databáze nebo odposlechu.“

To je silně závislé na konkrétní situaci. U databáze jaké máte heslo, jak zabezpečený je hosting, kde se skladují zálohy, kdo všechno k nim má přístup, apod.

Odposlech záleží jaký a koho.
Např. na frekventovaném místě udělat WiFi hotspot s názvem *nějaká firma v okolí* free WiFi a sledovat provoz těch, kdo se přes něj připojí, je celkem triviální.
S trochou sociálního inženýrství by takhle asi šlo zaměřit i konkrétní oběť.

jakre:
To je podobná otázka jako jestli má smysl používat zámek na dveřích, když ho lze překonat.

Bezpečnost není vlastnost. Nemůžeš o něčem říct, že to bezpečné je nebo není. Je o tom potřeba přemýšlet jako o míře. S dostatečnými prostředky můžeš prolomit jakoukoli ochranu. V důsledku jde tedy jen o to zda hodnota získaných věcí/informací je pro útočníka větší než hodnota prostředků, které by musel vynaložit na jejich získání.
Pak je tu druhá strana, cena, jakou jsi ochoten zaplatit, aby jsi ochránil své věci/informace.

Když to převedeme do reálného světa, tak zloděj nebude organizovat loupež, která ho bude stát 100 000$ na prolomení zámku sejfu, když v něm bude 10$.

A naopak, pokud budeš mít 200$, nebudeš si kupovat sejf za 50 000$ na jejich ochranu. Levněji tě vyjde si těch 200$ nechat párkrát ukradnout.

Lze tedy doporučit použít vše, co si můžeš dovolit nebo co tě nic nestojí. HTTPS si nejspíše budeš moct dovolit.

Keeehi:
„Jinak ani HTTPS není ve 100% případů bezpečné. I proti němu existuje celá řada útoků.“
To je trochu zjednodušující pohled. Pokud jako provozovatel neuděláš žádnou chybu v konfiguraci (což není tak náročné) a také infrastruktura, která k šifrování poskytla klíče nebo ta, která ho provádí není nějak kompromitována (což většinou lze předpokládat), dá se přenos v HTTPS vrstvě považovat za 100% bezpečný, respektive jeho překonání není reálné žádnými ani hypotetickými prostředky.

Martin2
HTTPS není neprorazitelné při tom, jak se běžné používá. Uživatelům stačí zelený zámeček, málokdo kontroluje samotný certifikát. Stačí tedy jedna kompromitovaná certifikační autorita, která je nastavena jako důvěryhodná a problém je na světě. Vybavuju si aféru některých notebooků Dell, kdy byl v instalaci i privátní klíč k certifikační autoritě od Dellu, které byla nastavena jako důvěryhodná, něco podobného snad mělo i Lenovo. Man-in-the-middle má celkem slušnou šanci vylákat z uživatele heslo (nebo hash, podle toho, co se posílá). Dá se tomu bránit (HPKP, DANE mělo-li by podporu v prohlížečích), ale většinou to nebývá nastavené.
Určitě je dobrý nápad HTTPS používat, ale brát ho jako 100% záruku už ne.

TomášK
Je to transportní zabezpečení. Nikdo se netváří, že by HTTPS chránilo zeleninu v lednici proti plísni. A co se týče malwaru v koncových stanicích (i když tomu tak Dell a výrobci „bezpečnostních“ softwarů asi neříkají), to se jako MITM neoznačuje (i když používá podobné techniky).

Martin2:
Z toho, co jsi napsal, jsem nabyl dojmu, že heslo poslané přes HTTPS je v podstatě neukradnutelné. Což podle mě není pravda, MITM pravděpodobně heslo dokáže ukrást. Důvěryhodné CA v koncových stanicích jsou příklad, jak může jednoduše podvrhnout certifikát serveru, což se při útoku MITM hodí. HTTPS jako protokol bezpečný je, nicméně typický uživatel ho bezpečně nepoužívá.

TomášK:
„heslo poslané přes HTTPS je v podstatě neukradnutelné“
Ano, po trase je neukradnutelné.

„MITM pravděpodobně heslo dokáže ukrást.“
Ne, nedokáže. Útoku MITM brání podpisy kořenových certifikačních autorit – ty jsou u nekompromitovaného počítače pro útočníka nepřekonatelnou zárukou bezpečnosti.

Martin2:
ty jsou u nekompromitovaného počítače ...
Tu je to, v čem se neshodnem. Já nepovažuju seznam certifikačních autorit, které má běžný uživatel nastavené, za důvěryhodný, ty ano.

Myslím, že můžeme diskuzi ukončit, asi nejde rozhodnout, kdo má pravdu. Nechť je každý paranoidní dle svého uvážení :)

TomášK:
„Já nepovažuju seznam certifikačních autorit, které má běžný uživatel nastavené, za důvěryhodný“
Na tom ovšem stojí veškerá zabezpečená komunikace světa. Banky, platby, elektronické podpisy, certifikace softwaru… Tomuto systému je možné buď důvěřovat, nebo žít v pralese.

Martin2:
Problém toho systému je, že jakákoliv certifikační autorita může vydat certifikát pro jakýkoliv web. Certifikační autorita výrobce zařízení nebo nějaké čínské firmy jde použít k vydání certifikátu na stránky banky a uživatel si toho nevšimne. Pro věci, kde o něco jde, se používá 2-faktorová autentizace (platby, banky) nebo se kontroluje, zda je certifikát podepsaný konkrétní CA, nikoliv jakoukoliv ze seznamu, který někdo dodal.
Kolik uživatelů postřehlo, že na ně Avast provádí (nebo prováděl) MITM? Když je na serveru nastavené HTTPS, dá se spolehnout na to, že komunikace mezi uživatelem a serverem není odposlouchaná. Ale už se nedá spolehnout na to, že uživatel zjistí, že komunikuje s někým jiným, kdo se za server vydává.

Martin2:
„Pokud jako provozovatel neuděláš žádnou chybu v konfiguraci (což není tak náročné)“
„Na tom ovšem stojí veškerá zabezpečená komunikace světa. Banky, platby, elektronické podpisy, certifikace softwaru.“
No s bankami to zas tak slavné není. Kdyby všechny měly tu bezpečnou konfiguraci, nemusel Špaček provádět každý měsíc jejich skenování nastavení https.

Je jasné, že louskat RSA může louskat jen málokdo. Je klidně i možné, že to provést nelze. Největší problém https však je že, se ho útočník může pokusit zbavit. A je úplně jedno, jak jako administrátor nastavíš tvůj server, pokud bude útočník od začátku sedět na komunikaci mezi tebou a uživatelem, může mu měnit jeho požadavky v případě, že napíše doménu do adresního řádku. Jediná obrana proti tomu zatím je být na seznamu, který je vestavěn v prohlížečích a říká pro které domény má být použito rovnou https.