Tajemství
Školení, která pořádám 
Aplikace se snažím navrhovat tak, aby pokud možno nevadilo, když se útočník dostane ke zdrojovým kódům nebo uloženým datům. Je dobré si představit, že útočníkem se stane programátor, který vám aplikaci vytvářel, nebo správce, který vám spravuje zálohy databáze. Tento jednoduchý přístup se promítá do mnoha oblastí návrhu aplikace.
Security through obscurity
Obvyklou amatérskou chybou je se v aplikaci spoléhat na nějaký nestandardní algoritmus. Co když bychom třeba hesla ukládali jako substr(sha1($password), 0, 32)? Zvenku to bude vypadat jako výsledek MD5, takže se útočníkovi haš nepodaří prolomit. Cha, chá, to jsme ho ale přechytračili! Většinou ho takovýmto postupem maximálně trochu zdržíte. Navíc hrozí, že nevhodně sestavený algoritmus bezpečnost řádově zhorší. Moje doporučení zní: Používejte prověřené algoritmy a hrdě se k tomu hlaste.
Hesla
Při ukládání hesel se princip nespoléhání se na tajemství dodržuje asi nejčastěji. V plaintextu si hesla dovolí ukládat jen ten největší ignorant. Ale ani běžné hašovací funkce bohužel už dávno nestačí, protože kvůli současnému výkonu počítačů lze velmi rychle prolomit i poměrně dlouhá hesla. V PHP je vhodné použít funkci password_hash, která používá pomalou hašovací funkci (a navíc přikládá salt). Při použití vhodné hašovací funkce pak uživatele ani nemusíme týrat požadavky na dlouhá a složitá hesla. Trochu kontroverzní je myšlenka pomalost hašovací funkce (parametr cost) přizpůsobit délce a složitosti hesla. Sice tím útočníkovi prozradíme sílu hesla jednotlivých uživatelů, ale zároveň tím uživatelům dovolíme používat krátká (třeba šestiznaká) hesla a přitom si nezpůsobíme DoS u uživatelů používajících hesla dlouhá. Podle mého názoru je takováto transparentnost v pořádku.
Session data
Play Framework session data ukládá do cookie podepsané tajným klíčem uloženým na serveru. To je v přímém rozporu s tím, jak se snažím aplikace navrhovat já. Pokud se útočník k tomuto klíči dostane, tak si může vygenerovat jaká session data chce. Správné řešení je session data ukládat na serveru a klientovi jen poslat náhodný session identifikátor. Tak to dělá PHP.
Session identifikátor
PHP ve výchozím nastavení ukládá na serveru session data do souborů pojmenovaných podle session identifikátoru. Je to úplně zbytečné. Poté, co session identifikátor vygenerujeme a pošleme klientovi, už ho na nic nepotřebujeme. Stačí si uložit jaho haš a když nám klient session identifikátor pošle, tak ho zahašovat znovu.
Token pro vygenerování zapomenutého hesla
Běžný postup při zapomenutí hesla je vygenerovat náhodný token, poslat ho uživateli na dříve registrovanou e-mailovou adresu a na jeho základě dovolit uživateli zadat heslo nové. Token si na serveru samozřejmě někde musíme uložit, ale stejně jako u session identifikátoru stačí uložit jaho haš. Kromě toho je vhodné tokenu omezit platnost a dovolit ho uživateli smazat bez změny hesla, případně ho automaticky smazat po běžném přihlášení.
CSRF tokeny
Co když se útočník dostane k CSRF tokenům uloženým v session proměnných na straně serveru? Bránit se tomu můžeme tím, že pro každou akci vygenerujeme token nový a na serveru si opět uložíme pouze jeho haš. Problém s tímto přístupem je v tom, že tokenů rychle přibývá a pokud nesáhneme k nějakému kompromisu (výrazné zkrácení platnosti nebo omezení počtu předchozích tokenů, které ještě půjde použít), tak za chvíli nebude pro samé tokeny kam šlápnout. Takováto řešení zhoršují použitelnost aplikace – já si třeba s oblibou otevřu nějaký formulář do vedlejšího okna a vrátím se k němu až po delší době a několika akcích v hlavním okně. Možné řešení je platnost tokenů omezit třeba na hodinu a z každého otevřeného okna aplikace si před jeho vypršením nechat JavaScriptem vygenerovat token nový.
Tajná URL
Neexistují! Obzvlášť v případě, kdy je napíšete do robots.txt.
Uživatelská jména
Řada přihlašovacích formulářů vám při zadání neplatných údajů řekne „Neplatné uživatelské jméno nebo heslo“. Pokud uživatelské jméno existuje, tak je to celkem správná hláška – uživatel si může pamatovat svoje heslo, ale jeho obvyklý login byl při registraci zabraný, takže si musel vybrat jiný. Pokud ale uživatelské jméno neexistuje, tak tím uživatele jen zbytečně mateme. Pokud uživatelské jméno tvoří e-mailová adresa, tak je tato hláška matoucí vždy. Existenci uživatelského jména si stejně může uživatel ověřit v registračním formuláři.
Hesla k databázi
Přístupové údaje ke zdrojům, ke kterým se z aplikace přihlašujeme, někde uložené být musí. Klíčové je, aby s těmito údaji nebyl databázový server přístupný odnikud jinud než z webového serveru a aby uživatel měl jen minimální možná práva. Např. Memcache ani žádné heslo nepoužívá.
Systémy třetích stran
Co když z vaší aplikace potřebujete jménem uživatelů přistupovat do systémů třetích stran? Heslo si v takovém případě přece někam uložit musíte, ne? Ne. Správným řešením je v takovéto situaci použít OAuth, který vaší aplikaci dovolí dělat jen omezené množství akcí bez toho, aniž byste od uživatele museli požadovat jeho heslo.
Všechna data
V první řadě se snažíme zabezpečit data, pomocí kterých můžeme k aplikaci získat přístup – hesla, session identifikátory, tokeny. Další úrovní je zabezpečit všechna data, ke kterým má mít přístup pouze uživatel. Jak by vypadal zcela bezpečný systém třeba pro posílání zpráv? Při registraci uživateli (nejlépe v jeho prohlížeči) vygenerujeme soukromý klíč a z něj odvozený veřejný klíč si uložíme na serveru. Když uživateli přijde zpráva, tak ji zašifrujeme jeho veřejným klíčem (pokud to jde, tak ještě v prohlížeči odesílatele). Když si uživatel chce zprávu přečíst, tak mu ji zašifrovanou pošleme do prohlížeče, kde si ji svým soukromým klíčem teprve rozšifruje. Takto navržený systém má řadu nevýhod, např. nelze zprávy na serveru prohledávat. Ale když za provozovatelem serveru přijde vyšetřovatel, že by potřeboval přístup ke zprávám nějakého uživatele, tak mu provozovatel může leda doporučit, ať napíše uživateli zprávu, ve které ho o ně požádá.
Závěr
Zkuste si u každého řádku zdrojového kódu a u každého kousku uložených dat rozmyslet, jestli by něčemu vadilo, když by je útočník získal. Pokud ano, tak asi máte aplikaci navrženou špatně. Máte pocit, že to v některých případech jinak nejde? Podělte se o ně v diskusi.
Přijďte si o tomto tématu popovídat na školení Bezpečnost PHP aplikací.
Diskuse
Jan33:
Zkrácení hash "bezpečné" funkce nezpůsobí ztrátu bezpečnosti! Zvýší jen pravděpodobnost kolize, ale všechny ostatní parametry zůstanou zachovány!Ale ve výčtu chybí jedna důležitá věc a to jsou certifikáty a klíče k nim. Certifikát určitě patří do key storu, ale heslo k němu musí být v otevřené podobě na serveru zachované. Byť jej jde natáhnout z konfiguračního souboru a ten zabezpečit na úrovni oprávnění operačního systému, jde o kritické místo pro bezpečnost.
Jakub Vrana 
:
Zvýšení pravděpodobnosti kolize je přece to hlavní, co nás zajímá. Znamená to, že útočník může použít jiné heslo než jaké uživatel skutečně má. Ale souhlasím, že v tomto případě je to spíše teoretický problém. V článku ani netvrdím, že tohle konkrétně řádově zhoršuje bezpečnost, ale že na koleně postavené bezpečnostní postupy tím často trpí. Viz např. http://www.zdrojak.cz/clanky/autentizace-…#comment-24945, kde kritizuji postup, že z JavaScriptu dostupný hash hesla má stejnou sílu jako heslo samotné, takže útočník se o získání hesla ani nepotřebuje snažit.
Nejcitlivější soukromé klíče je vhodné ukládat do hardwarového zařízení, které nemá API na jejich získání, ale pouze na jejich použití. Pokud by je někdo tedy chtěl získat, musel by získat fyzický přístup k těmto zařízením a rozebrat je.
Jakub Vrana : v6ak:
K té kolizi: Mimochodem, nedávno jsem řešil bezpečnost OpenPGP key ID. Teoreticky jsem odhadnul a dogooglil se, že 32b ID není bezpečně, protože kolize se dá najít během pár hodin. Chtěl jsem i prakticky realizovat, narazil jsem na jednu zradu (počítal jsem se starým formátem, který ale dává výhradně lichá ID, takže jsem kolizi ani najít nemohl) a zatím jsem nenašel čas to dodělat. Na druhou stranu, s novou verzí ty kolize mohou jít rychleji.
A 64b ID dnes může vypadat bezpečně, protože s 10 G/s je "poločas rozpadu" skoro 60 let. Pokud ale započítáme Mooreův zákon, dostaneme se pod deset let. Se začátkem na 80 G/s se, tuším, dostáváme už na zajímavě rychlý čas.
Jan33:
> Zvýšení pravděpodobnosti kolize je přece to hlavní, co nás zajímáDovolím si s tím nesouhlasit. Prosím uvědomme si, že zde nejde o aplikaci elektronického podpisu. Tam pokud najdete kolizi, můžete vydávat druhý dokument za "také podepsaný" a honba za bezkolizností je skutečná priorita. Ale ověřování hesel má úplně jinou prioritu a tou je časová složitost nalezené hash. A ta zůstává pro substr(sha1(password)) stejná, jako pro sha1(password). Takže zkrácení hashe neutrpí žádný ze sledovaných parametrů. Maximálně by se mohlo zjistit, že Franta se může přihlásit stejným heslem jako má Pepa (a pokud se poctivě solí, tak nenůžeme tvrdit ani to).
> že na koleně postavené bezpečnostní postupy tím často trpí
S tím není možné nesouhlasit.
> vhodné ukládat do hardwarového zařízení
Máte nějakou zkušenost s konkrétním zařízením a přístupem z PHP?
Jakub Vrána :
Tak si to doveďme do extrému. Jak asi bude složité prolomit substr(sha1($password), 0, 1)?
Konkrétní zkušenost s HW zařízením bohužel nemám, natož z PHP.
Jakub Vrána : Jan33:
> Tak si to doveďme do extrému. Jak asi bude složité prolomit substr(sha1($password), 0, 1)?Právě kvůli použití sha1 docela dlouho (vztáhněte to prosím k délce hashe 4 bitů). Hash funkce mají jednu podstatnou vlastnost a tou je jednosměrnost. Vy na základě znalosti výstupu (hashe) nemůžete nic říct o vstupu. Tedy jste, ať chcete nebo ne, stále nucen počítat sha1. V tomto konkrétním příkladě se mapuje 61 hesel (z prostoru a-Z0-9) na 16 možných kombinací hashe. A to je docela slušný výsledek.
Jakub Vrana :
Ne. Řekněme, že jsme hacker, který v databázi našel výsledek substr(sha1($password), 0, 1), třeba "f". Jak heslo prolomí?
<?php
for ($i = 1; ; $i++) {
if (substr(sha1($i), 0, 1) == "f") {
echo "$i\n";
break;
}
}
?>
Zabere to přesně osm pokusů.
Jakub Vrana : Michal:
K poslednímu odstavci - věta je patrně špatně formulovaná. V zásadě u jakýchkoliv uživatelských dat vadí, pokud je útočník získá. Počínaje třeba e-mailem.
Výjimku z toho pravidla jsou údaje veřejně dostupné. Takže třeba pokud známe uživatelovo jméno a to se zobrazuje dejme tomu ve všech komentářích, které jsou veřejné, pak jeho únik "nevadí". Pokud se však zobrazuje jen někomu, pak už by vadilo, kdyby jej útočník získal.
Jakub Vrana :
Souhlasím. To je svatý grál, ke kterému bychom měli směřovat. Proč ukládáme e-mailovou adresu? Třeba proto, abychom na ni mohli rozesílat obchodní sdělení. V tom případě ji můžeme zašifrovat a správce při rozesílání mailů bude muset zadat heslo pro jejich rozšifrování. Nebo adresu používáme pro poslání tokenu pro změnu zapomenutého hesla? V tom případě si stačí uložit její haš a v případě zapomenutí uživatele použádat o jeho adresu znovu.
Ale v mnoha případech to vede k šíleným komplikacím, takže řešení v praxi je spíše to, že se zašifrují všechna data a soukromý klíč k jejich rozšifrování se dá někam daleko od nich. Což ale samozřejmě neodpovídá myšlence článku.
Jakub Vrana : Sharkodlak:
Jaké výhody má použití funkce password_hash, která zdá se hashuje rekurzivně vstupní text v závislosti na parametru cost? Zbytečně se tím mrhá výkonem počítače a zvyšuje se riziko kolizí. Podle mě je lepší použít pouze jeden průchod hašovací funkcí a poté zavolat sleep(random time).Rozhodně nedoporučuji měnit cost (nebo jajékoliv snadno dostupná data, např. salt) v závislosti na složitosti hesla. Jakmile by útočník věděl, která hesla jsou slabší, mohl by se na ně zaměřit.
Jan33:
Pomalé hash algoritmy jsou tu pro to, aby útočníkovi, který má neomezený přístup k hash hesla (například ukradl celou databázi), zabránili v rychlém zkoušení uhodnutí hesla hrubou silou. Např. takovýto kód for(var ch = 'a':'zzzzz') break if md5(ch) == hash poběží u úročníka 30 vteřin, ale s pomalou hash funkcí třeba půl dne.Co se týká zvýšení rizika kolizí, tak budete muset být konkrétnější. V čem podle vás dochází k zvýšení rizika?
Jakub Vrana :
password_hash() nepoužívá nějaký tupý postup typu md5(md5(md5(md5(md5(md5(md5(md5(md5(md5($password)))))))))), kde by skutečně mohly vznikat cykly a tím by se zvýšilo riziko kolizí. Používá Bcrypt, který je k tomuto použití přímo navržen.
Použití sleep() je k ničemu. Zdá se, že zpomalí útočníka, který nemá přístup k hašům a zkouší se prolomit přímo přes přihlašovací formulář. Nic mu ale nebrání zkoušet víc hesel paralelně. Jeho to nic nestojí a nám akorát dřív dojdou otevřená spojení. Mnohem lepší obrana proti tomuto útoku je omezit počet pokusů o přihlášení za nějakou dobu, klidně velkoryse (např. 10 za minutu). Navíc jak píše Jan33, tak nás to nijak neochrání proti útočníkovi, který získá samotné haše, což je hlavní moto článku.
K čemu útočníkovi bude, že se zaměří na slabá hesla? Podívá se do databáze a zjistí: „Aha, tak tohle heslo je slabé a kvůli vysokému parametru cost ho budu prolamovat průměrně 21 let. A tohle heslo je silné a budu ho prolamovat taky 21 let.“
Jakub Vrana : mila antonin:
kdyz se na vas nekdo zameri tak neni uniku aby nezískal hesla i jmena staci se zamerit na telefoni cislo ktery je pausalni a ten dotycny kde a kdy se kdo narodil a zneuzije druhymu identitu to se me stalo+stahoval mujkredit a nikdo nezjistil kdo to dela ani statni organy to nevystopovali.
hacafrakus:
Znova bych zde zdůraznil problém s šifrováním čísel kreditních karet, který je podle mne nemožné vyřešit tak, aby to bylo naprosto bezpečné. Pokud zašifruji číslo kreditní karty klíčem a ten si ponechám ne v databázi, ale u aplikace, je to zase pouze Security through obscurity. Snad leda použít v komentáři výše uvedený key store (nebo něco na ten způsob) a dobře jej od aplikace odstínit (aby v případě prolomení bezpečnosti zůstaly klíče k dešifrování nedostupné).
hacafrakus: Jakub Vrana :
V první řadě je potřeba zdůraznit, že kreditní karty jen tak halabala ukládat nelze, je potřeba dodržet regule PCI: https://www.pcisecuritystandards.org/.
Já jsem o ukládání kreditních karet kdysi psal: http://php.vrana.cz/ukladani-citlivych-informaci.php#openssl. Postup je ten, že při ukládání použiji veřejný klíč a při načítání soukromý klíč chráněný heslem, které není nikde uloženo. To heslo může mít buď administrátor – v situaci, kdy kreditní karta slouží jako jistina, např. při objednání ubytování, kdy se číslo použije jen pokud host nedorazí, jinak platí přes normální terminál v hotelu. Nebo heslo může mít sám uživatel – pokud ho ukládáme proto, aby se zjednodušily další platby. V tom případě po něm budeme chtít při platbě heslo vždy znovu zadat, což je celkem pochopitelný a kladně vnímaný požadavek.
Jakub Vrana : hacafrakus:
Díky, s tímto zkušenost zatím nemám, vždycky jsem platby realizoval skrze brány, ale je co studovat :)
Líbí se mi hlavně ta možnost, která je zmíněna níže - API k zabezpečenému serveru.
hacafrakus: 
v6ak :
Tak čísla karet mohou být na jiném stroji, který je nebude ochoten vydat a bude odmítat skoro jakékoli spojení vyjma pár vyjmenovaných. Bude mít API na uložení, smazání a zaplacení. Útočník by ještě mohl zneužít to API k zaplacení, ale to by došlo na účet firmy. Takže jednak k tomu nemá takovou motivaci a jednak to firma může vrátit uživateli zpět.
Když to teda nepůjde nějak lépe, jak psal Jakub Vrána. (Navíc můj a Jakubův přístup se dají kombinovat.) Hádám, že takto nějak to bude mít Google, protože ten to nemůže mít zašifrované heslem (které po mě nepožaduje) ani ničím jiným, co by neměl Google sám k dispozici.
v6ak : Jakub Vrana :
Bez požadování hesla v momentě použití karty by to mohlo být takhle:
1. Při přihlášení vygeneruji náhodný session identifikátor. Pošlu ho klientovi a sám si uložím jeho haš. Číslo karty zašifrované heslem rozšifruji a uložím ho vedle zašifrované session identifikátorem.
2. Když potřebuji číslo karty použít, tak ho rozšifruji session identifikátorem, který nikde na serveru uložený není.
Jakub Vrana : Michal Špaček:
Toto by šlo použít jen ve chvíli, kdy nějaká session vůbec existuje. A to není pokaždé, viz třeba automatické platby (auto-renew), díky kterým spousta firem po zákaznících kreditky vůbec chce :-) V tu chvíli není známé ani session id, ani heslo. Značně by taky vzrostla zátěž úložiště kreditních karet, ne každý chce hned po přihlášení platit kartou, bohužel. Z toho samého důvodu se karty nešifrují ani uživatelovo heslem, protože to ve chvíli, kdy se má platit taky server nezná a uživatel spí a není přihlášen.
Jakub Vrána :
Na to podle mě nabízí API rovnou payment processoři. Řekneš jim: z téhle karty si každý měsíc berte tu a tu částku a oni to dělají, dokud jim ty nebo klient neřekne jinak. Takže potom číslo karty můžeš zahodit.
Ale to je jen můj pocit, přímou zkušenost s tím nemám.
Jakub Vrána : Michal Špaček:
Automatické platby nemusí být závislé jen na čase, ale mohou se spouštět v podstatě kdykoliv. Např. v případě Skype, když během hovoru dochází kredit, tak se automaticky spustí platba, která kredit dobije, bez přerušení hovoru.
Takže ačkoliv i toto by šlo řešit bez uložených karet, resp. s údaji o kartách uložených u providera a na API posílat jen nějaké id karty, tak automatické platby nejsou jediným důvodem, proč obchodníci údaje o kartách uchovávají sami.
Ty se uchovávají z mnoha dalších důvodů jako např. nižší poplatky za transakci, možnost dynamického routování plateb, aniž by majitel karty musel zadávat znovu číslo karty nebo heslo (pošleme platbu na providera X, protože má levnější zpracování karet X nebo rozsahů X-Y, případně má ten druhej výpadek apod., nebo najednou přestal přijímat karty X), ale důležitá je i fraud analýza a to nejenom nad jednotlivými kartami, ale třeba nad celými rozsahy. Těch důvodů bude asi víc a pro každého obchodníka mohou být jiné, nicméně tyhle si tak nějak pamatuju z dob, kdy jsme stavěli "PCI DSS-compliant" platební systém ve Skype.
Jakub Vrana :
Díky za doplnění zajímavých informací.
Při hovoru jsme taky uvnitř nějaké session, takže postup pro rozšifrování kreditky pomocí session-specifické informace by měl být taky možný. Je nějaká situace, kdy tohle nejde?
Jakub Vrana : Michal Špaček:
Velmi by to asi ztížilo třeba přidání karty dlouho po startu takové session, např. dlouho po přihlášení nebo po zahájení hovoru nebo více takových sessions běžících naráz, tj. více přihlášení z různých zařízení nebo prohlížečů. To by asi všechno šlo řešit vyžádáním hesla před přidáním karty a následném zašifrováním dané karty i pomocí údajů všech souběžně běžících sessions. Uživatelé navíc mohou mít uloženo více karet, úložiště karet by tedy muselo být jednou z nejvýkonnějších komponent.
Problém by ale asi nastal v případě přihlašování pomocí více různých způsobů naráz nebo obecně pomocí třetích stran (kromě hesla např. pomocí Facebooku nebo Microsoft Accountu), nejsem si jistý, že by se v tom případě dalo dostat k údajům karty zašifrovaným uživatelským heslem. Resp. jsem si celkem jistý, že by to nešlo :-) Údaje karty by se musely zašifrovat nejenom heslem, ale i nějakým id nebo tokenem, ale to už pravděpodobně bude na serveru uloženo, kvůli párování s lokálními uživateli. Tím by to celé ztratilo smysl.
v6ak :
K tomu Play!: Tam byla prý důvodem škálovatelnost. Nelíbí se mi to ale hlavně z jiných důvodů, zejména tu v principu nelze řešit replay attack.
v6ak : David Pavlík:
Jakube, díky za článek.Můžu se zeptat, jak bys bezpečně řešil ukládání hesel pro systém třetí strany, když nepodporuje OAuth? Potřebuji se do toho systému přes PHP přihlašovat cronem každý den.
Jakub Vrána :
Co je to přesně za systém? Dá se v něm nastavit, aby se k němu dalo přistupovat třeba jen z určité IP adresy? Pokud ano, tak bych si s tím moc nelámal hlavu. Pokud ne, tak bych heslo rozdělil na co nejvíc míst – třeba uložit do databáze zašifrované klíčem, jehož půlka je ve zdrojácích a druhá půlka ve filesystému. Ale to principy popsané v článku samozřejmě stále porušuje.
Jakub Vrána : David Pavlík:
Děkuji za odpověď.Omezení přístupu pouze z určitých IP adres se bohužel omezit nedá. Asi to udělám, jak píšeš — zašifruji je a klíč se pokusím uložit na co nejvíce míst.
v6ak :
Z nějakého důvodu jsem si znovu prošel článek a narazil jsem na jednu věc, kde nemohu souhlasit, totiž, že by se cost mělo přizpůsobovat např. délce hesla. Působí to na mě tak, že Tě to napadlo při psaní článku, ale nepoužil jsi to. Nebo to používáš a přišel jsi na nějaký geniální detail, který mi uniká.
Jak by se to mělo přizpůsobit?
a) Aby prolomit slabé heslo bylo stejně těžké jako silné heslo? Pak by ale se zkracováním hesla exponenciálně rostl čas na hashování. Je to opravdu únosné?
b) Nějak mírněji, aby tu nebyl ten exponenciální nárůst. Pak mi ale přijde, že upozorníme útočníka na slabá hesla, aniž bychom získali něco podstatného.
Ještě víc to zhoršuje dnešní realizace Mooreova zákona, kdy výkon roste částečně díky paralelizaci. Toho může využít snadno útočník (bruteforce patří obecně do kategorie embarrasingly parallel), ale ne my, nebo možná omezeně.
v6ak : 
David Grudl :
Zřejmě bylo motivací zabránit Dos útoku při použití moc dlouhého hesla (viz https://www.djangoproject.com/weblog/2013/sep/15/security/). Což se ale funkce password_hash() a jediného algoritmu PASSWORD_BCRYPT netýká, protože délka hesla, nepřekročí-li půl megabajtu (sic!), nemá na rychlost výpočtu prakticky vliv.
David Grudl : Jakub Vrana :
Nepoužívám to a opravdu mě to napadlo při psaní článku. Sice by nás to lépe ochránilo proti brute-force útokům, ale hůř proti slovníkovým. Takže je to asi blbost.
Jakub Vrana : Michal Špaček:
Parametr cost je obecně dobré měnit jen v čase, zjednodušeně řečeno, čím je výkon hardware vyšší, tím větší by měl "cost" být.
Díky tomu, že cost je uložen přímo ve výsledku volání password_hash(), tak tyto "staré" hashe s nižším "cost" budou fungovat i v případě, že "cost" zvýšíme pro generování nových hashů.
ic :
Měl bych dotaz k poslednímu budu 'Všechna data'. Pro mě je to rozhodně velmi zajímavá novinka, ale jak je to s praktickou realizací? Existuje už na asymetrickou kryptografie v prohlížeči nějaká javascriptová knihovna/funkce , nebo je to psáno v teoretické rovině?
: Diskuse je zrušena z důvodu spamu.
© 2005-2024 