Hoj,
při nastavování mého MC serveru a házení všech dat do databáze jsem
narazil na šifrování whirlpool. Co to je, a dá se do toho nějak zašifrovat
text v php?
se solí jsou ale podle mě neprolomitelné ne? kdy mám třeba nick a
heslo.
heslo "osolím" (mě to vždy rozesměje ) nickem a to už je docela dost
bezpečný ne?
Trochu jsme se odchýlili od původní otázky, je to hashovací algoritmus,
což znamená, že už ze své podstaty nejde zpětně rozšifrovat, hashe se
používají pro kontrolní součty, ukládání hesel apod... proto je pro
předání zprávy nepoužitelný
Já v tom nevidím problém... Mám uživatele, jeho heslo je uložený jako
hash, kde je heslo, a jako sůl mám nick... Mám tedy nějaký hash...
Uživatel si změní nick... Na "potvrzení", že je účet jeho zadá i
heslo... Pochopitelně zjistím jestli je heslo platné, a pokud ano, přepíšu
mu nick. A jelikož vím jak nick, tak heslo, můžu mu vytvořit i nový
hash.
Ale tak dál to tu řešit nebudem, diskuze neni o tomhle neni
A co je špatného na tom, že při změně nicku musíš zadat heslo? Hesla
budou ve větším bezpečí díky originální soli u každého a uživatel
bude mít pocit (a podle mě právoplatný), že mu to jen tak nikdo
nezmění...
tak pokud to chceš mí über-super-mega-ultimate-bezpečný, tak jako sůl
dáš hash spojení: "nick+mail+datum_registrace+text(třeba název
stránky)+id_uživatele"... To už ti přijde dostatečně bezpečné?
Vlastnosti objektů by neměly být veřejné. A to ani prostřednictvím getterů/setterů.
Člen
:15.12.2013 17:55
Takto. Jde mi o to, že autorizační plugin ukládá hesla "zašifrovaná"
(hrozně rád tomu tak říkám) právě whirlpoolem. A já se na webu
potřebuju přes to, co uložil plugin přihlásit do webu.
sdraco: já vím že ne, ale prostě tomu tak říkám...
Co je chybně? Pokud jsou v databázi uloženy sůl i hash, musíš záznam
nejprve načíst, abys byl vůbec schopen ze zadaného hesla hash spočítat.
Jakmile je záznam už jednou načtený, je zbytečné se znovu dotazovat
databáze a testovat shodu.
Pokud je uživatelské jméno neplatné, předejte se zbytečným
výpočtům.
Souhlasím s sdracem, že používat jako sůl ID nebo jméno uživatele
způsobuje problémy. Nevidím v tom žádnou výhodu, jen nevýhody.
Nemusíš načítat vůbec nic. Stačí jediný SELECT, jehož výsledkem je
id a další atributy hráče. Heslo ani sůl z databáze tahat nepotřebuji.
Pokud heslo nesedí, nedostanu žádný výsledek, ušetřím tedy
komunikaci.
<?php$auth = $pdo->prepare("SELECT id FROM user WHERE name=? AND password=SHA1(CONCAT(?, salt))");
$auth->execute($_POST["user"], $_POST["pass"]);
if ($dotaz->rowCount() == 0)
thrownew Exception("Chybné jméno nebo heslo");
$user = $auth->fetch(PDO::FETCH_ASSOC);
Díky za příklad. Myslím, že algoritmus je stejný jako v článku, pouze
jsi přesunul logiku do databáze. To samozřejmě udělat lze a někdy to
může být i výhodné.
Článek byl míněn obecně a nepředpokládá použití databáze
MySQL.
Nedávno jsem byl na přednášce o php a tam týpek ukazoval program který
za dvě sekundy rozšifroval md5 heslo z malých a velkých písmen o min
velikosti 5 takže nevidím
tady nikde to, že by to nešlo rozšifrovat + povídal o tom, že takové heslo
ještě se solí se dá taky docela rychle, že ted už je jak md5 tak sha512
rozšifrovatelne během chvíle. Nyní by se mělo používat bcrypt nebo tak
něco
Tu nejde o slabé heslo, tu jde o to že ta rychlost rozšifrování je
vysoká když zadá min. 5 čísel a z malých a velkých písmen. mělo to
něco přes 20M slov za sekundu. Jako ano, pokud má člověk slabě heslo tak
jo, je to hned. Ale právě ukazoval na tom příkladu to, že md5 ani sha512
už se nedoporučuje z toho duvodu, že byly prolomeny a že pokud fakt bude
někdo chtít bezpečný system bez děr, měl by používat něco, co ještě
nebylo.
Je hrozně zavádějící označovat md5 jako šifru. Nahlížej na to
raději podobně jako na kontrolní součet. Když si budu myslet
tři čísla od 0 do 9 a oznámím ti jejich součet, poměrně málo
pokusů ti stačí na to, abys odhalil, jaká čísla jsem si myslel.
Když ti ale oznámím součet padesáti čísel, budeš mít mnohem
větší problém. Ale pořád to půjde, když tě nechám dělat tolik
pokusů, kolik budeš chtít. Když ti ale dám jen tři pokusy,
prakticky nebudeš mít šanci. A právě v tomto smyslu se md5
používají. K rychlému ověření shody. Pokud ti nějaký člověk
ukázal, že heslo o pěti znacích rychle prolomí, je to proto,
že měl libovolně mnoho pokusů. Nic víc.
najlepsie je pouzivat hashovacie algoritmy, ktore su narocne na
vypocty(bcrypt). Mozno spomalia prihlasovanie uzivatela, ale v pripade uniknutia
DB (hashov) takmer znemoznia desifrovanie. Samozrejme pouzivanie SALTu tiez sa v
tomto pripade silno odporuca
Asymptoticky je to sice stejné, ale prakticky to trvá mnohem, mnohem déle,
když zvolíš konstantu v řádu stovek a útočníkovi velmi znepříjemníš
život. Sehnat 300x výkonnější procesor přeci jen není tak snadné.
Časovou složitost bcrypt neznám.
Zásadní rozdíl je v tom, že amatérismus do security
nepatří
sehnat 300x výkonnější procesor je snadné
představy amatérů se liší od představ specialistů
znalosti amatérů se liší od znalostí specialistů
bcrypt je navržený profesionály, aby byl bezpečný
Dále existuje několik předpokladů:
útočník je váš nejlepší kamarád a ví minimálně to, co vy
útočník má přístup k 3000x rychlejšímu hardwaru
útočník je geniální matematik a kryptoanalytik
Libovolné řešení, které navrhnete, viz SHA512(for 0..1000
MD5(salt(pswd))) je stejně bezpečné jako základní řešení
SHA512(salt(pswd)) z toho důvodu, že už SHA512 bylo navrženo jako
bezpečné. Laický názor je, že když smícháme dvě bezpečná řešení,
dostaneme bezpečné řešení na druhou, ale opak je pravdou.
Sorry, že to tak musím říct, ale v tomhle vláknu je spousta blábolů.
Viz TomBenovo vysvětlení "kontrolní součtu" - mně by na jeho příklad
stačil jeden tip a budu vědět řešení (a dokonce i optimální), protože
jsem matematik. Nebo Snorlax, který si plete pojmy o dojmy a plácá pátou
přes devátou.
Ze základů hashovacích funkcí:
hledáme jednosměrnou funkci F(x) = H
funkce musí být prostá
funkce by měla být na
range funkce je 2^K, kde K je zvolená konstanta
nesmí existovat postup, který vede ke snížení K
Například MD5 a SHA1 byly zkompromitovány, nebyly
rozbity. Rozdíl je v tom, že existuje důkaz pro porušení
pravidel (b) a (e), ale není známý postup pro nalezení řešení
jednosměrné funkce v čase lepším než O(2^x). V případě MD5 se povedlo
drasticky snížit K a zmenšit doménu hledaných hodnot.
Jakákoliv vaše snaha o "vylepšení" takové funkce F vede
zpravidla k porušení některého z pravidel. Všechny kryptografické
algoritmy se navrhují s těmito ohledy a pečlivě se testují celé měsíce,
než se dojde k uspokojivému výsledku.
Pokud použijete SHA(salt(heslo)), budete mít nejvyšší úroveň
bezpečnosti, jakou sami dokážete dosáhnout.
Máš samozřejmě pravdu. Netvrdil jsem, že se zvýší bezpečnost toho
hashe, ale doba jeho prolomení. Docela by mě zajímala časová složitost
lepších algoritmů, jejichž implementace jsou běžně k použití.
Ani doba "prolomeni" se nezvysi, protoze funkce je jednosmerna a prolomit ji
neumime. Jak jsem psal, dulezita je velikost range a domeny funkce a tenhle
postup je nezvetsuje, pouze aplikuje urcitou transformaci. Takovy cyklus se uz
deje uvnitr SHA a povazuje se za bezpecny, takze neni duvod ho jeste pridavat
"ven". Pokud se najde postup pro rozbiti vnitrniho cyklu, pak vnejsi cyklus
ztrati take na vyznamu.
Tady jde o situaci, když ti někdo ukradne celý backend a začne dělat
dictionary attacky na jednotlivá hesla. Obrany jsou dvě, hlavní je mít u
každého hesla jinou sůl. Tím pádem pro zjištění n hesel musí začínat
n krát od nuly. A tou druhou je docílit toho, aby takový útok trval co
možná nejdéle. Když bude hash trvat pod milisekundy, tak to má velmi
rychle. Jakým způsobem bys toto tedy řešil?
SHA dle security specifikaci, zadna vlastni vylepseni
vetsinou dojde ke kradezi zaloh spise nez backendu, jeste casteji to byvaji
primo zamestnanci, takze programatori nesmi byt admini, admini nesmi mit pristup
ke zdrojakum
Mimochodem, pokud by se útočníkovi podařilo projít všemi kroky, které
popisuji výše, tak už je to ztracené a nemá smysl řešit hesla. V tuhle
chvíli je volný přístup k libovolné (i šifrované) informaci v systému,
jako jsou čísla kreditek, sociálního pojištění, bankovních účtů,
atd.
V tom případě bych raději používal termín bezkolizní
(collission-free). Mohl bys prosím uvést zdroj, v kterém se hovoří o
kryptograficky prostých funkcích?
Proč jsi zvolil zrovna tuhle kombinaci?
Je sice špatně, ale mě víc zajímá důvod. To s tím dokazováním
je dost podivná věta. Skoro ses trefil. Kdybys trefil úplně,
klidně to přiznám. Dokazovat nepotřebuji nic, pokud ty
něco takového potřebuješ, můžem pokus zopakovat na jiných
číslech a já je někam uložím. Nicméně mi to přijde trapné.
Čísla byla správná, jen v jiném pořadí. Ovšem do pomyslného
trezoru by ses nedostal. Takže mám jen jeden dotaz.
Proč sis myslel, že je to optimální tip?
Koukám, že to bereš osobně Já mluvil v kontextu hashování.
Můj odkaz, že to nemůžeš dokázat vůbec není podivný, to je princip
hashování. Jakmile jednou uděláš hash a uložíš ho, přijdeš o zdrojová
data. Smyslem hashe je, abys nemohl prozradit to, co neznáš. Do trezoru jsem
se dostal díky tomu, že součet mám správně, ne proto, že mám původní
data a tím pádem nezáleží na tom, jestli něco přiznáš nebo ne. Nepleť
si šifrování a hashování.
Můj tip je optimální, protože ho dokážu vytvořit rychleji, než jsi ty
generoval hash.
Je docela těžké držet s tebou stejné téma. To, co tu všude okolo
píšeš je pravda, ale ten způsob, jak s tím zacházíš ve slovním projevu,
je zvláštní. V pokusu i dále jsme se zjevně minuli pochopením sebe
navzájem a vzhledem k tomu, že rozdíl mezi hashem a šifrou chápu a chápal
jsem už předtím, zřejmě nemělo smysl to vůbec dělat. Jako už i dřív
to prostě vypadalo, že popíráš něco zcela zjevně pravdivého, ale byl to
jen ten tvůj způsob vyjadřování, který mě čímsi mate.
Banky a další instituce, pro které je bezpečnost opravdu důležitá,
používají speciální (a také velmi drahý) hardware tzv. Hardware Security
Module (HSM).
To se ale už bavíme o úplně jiném světě, než je provozování
vlastního Minecraft serveru.
Vždy je třeba nejprve zvážit dopady případného útoku a
protiopatření.
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.