Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Používáte pro ukládání uživatelských hesel funkce jako MD5 nebo SHA-1 a chtěli byste to změnit na třeba bcrypt? A chcete to udělat pořádně, aby byla chráněna všechna hesla ve vaší databázi? Michal Špaček v článku Změna hashování existujících hesel na svých stránkách ukazuje, jak to udělat.
Tiskni
Sdílej:
nejhorší způsob, kterým by se to rozhodně dělat nemělo.Čím to můžete podložit?
Filipe, díky za komentář, jen škoda, že jste neodpověděl na mou otázkuJestli se nemýlím, otázka zněla: „Jak byste to bez otravování uživatelů udělal lépe, prosím?“ Moje odpověď měla několik částí:
„Bez otravování uživatelů“ reprezentuje váš názor, se kterým nesouhlasím, proto odpovím na obecnější otázku „Jak bych to udělal lépe“."Bez otravování uživatelů" není můj názor, je to požadavek. Bezpečnost jde ruku v ruce s použitelností, slovy Aviho Douglena: Bezpečnost na úkor použitelnosti jde na úkor bezpečnosti. Nelze zbytečně zatěžovat uživatele pokud to není vysloveně nutné. A při změně hashování to potřeba opravdu není.
Použil bych „pepř“, který zvyšuje bezpečnost zásadně,Můžete mě prosím odkázat na nějaký reálný výzkum, který by Vaši domněnku potvrdil? Všimněte si prosím, že žádné funkce na hashování hesel "pepř" nepodporují. Pokud "pepř", tedy nějaký globální statický řetězec, přimícháte před hashováním, tak můžete poškodit původní algoritmus, protože ho změníte. Jako příklad snad postačí použití "pepře" v PrestaShopu, ve kterém díky tomu byla všechna hesla uměle zkrácena na 16 znaků. Také by bylo dobré zmínit, že "pepř" nepoužívá ani třeba Facebook, ani Dropbox, ačkoliv ten tvrdí že ano, ale jen "pepřem" nazývá šifrovací klíč, což skutečně není "pepř". Navíc v realistickém modelu hrozeb by měla být možnost použití útoku SQL Injection k získání obsahu např. konfiguračních souborů, tedy i onoho "pepře". Tím se sníží bezpečnost takového řešení jena na "hash a případná sůl" a závisí tedy opět na použitém hashi. Bylo by tedy nutné použít nějaké HSM, nicméně pořád zůstává problém změněného algoritmu. V článku píšu, že pro dosažení podobného efektu se dá použít šifrování hashů, používají se tedy pouze algoritmy, které k daným účelům byly navržené.
na rozdíl od „pomalých“ hashovacích funkcí nebo rychlých paralelních výpočtů, které mění výpočetní složitost pouze o několik málo řádů.Mezi použitím nevhodných hashů (např. MD5) a hashů pro ukládání hesel (např. bcrypt s cost=10) je rozdíl 8 řádů, při použití vyššího costu i více. Může se to zdát málo, ale převedeno na čísla to znamená, že jde o generování kandidátů rychlostí 30 miliard pokusů za vteřinu vs. 650 pokusů za vteřinu. V praxi to znamená, že z dat Ashley Madison (bcrypt cost=12) šlo za 5 dní cracknout jen 4000 velmi předvídatelných hesel. Po objevení dalších hashů, což bylo několik různých variant MD5, které by se daly zjednodušeně popsat jako "MD5 se solí" a "MD5 se solí a pepřem" bylo cracknuto 2,6 milionu hesel za pár hodin a 11,2 milionu hesel za 10 dní.
Při přehashování přes starou funkci bych si stanovil termín, po kterém se staré hashe resetují.Je to samozřejmě možnost, je lepší hesla nemít než mít
Uvědomil bych si, že to, co řeším teď, budu za pár let řešit znova, takže bych se na to připravil.Velmi pravděpodobně to za pár let dělat nebudete. Problémem je, pokud vývojáři používají hashovací funkce, které nejsou určené k ukládání hesel, tedy např. SHA-1 a MD5, pak je potřeba takováhle spartakiáda s přehashováváním. Když se používají doporučené funkce, tak stačí transparentně po přihlášení přehashovávat, hesla jsou stále dobře chráněna i při použití třeba onoho bcryptu s costem 10. Pokud byste přidal asymetrické šifrování hesel, tak do systému přidáte nutnost bezpečného úložiště, správy klíčů a přidáte proces na správu hesel v čitelné podobě, čímž velmi pravděpodobně bezpečnost hesel ve finále snížíte. Toto by bylo možné provést maximálně ve velkých organizacích, které tyto procesy dokáží zaručit, ale ve ani ty nemají důvod k uchovávání hesel v zašifrované podobě. Tohle jsou důvody, proč jste nejenže neodpověděl na mou otázku "Jak byste to bez otravování uživatelů udělal lépe, prosím?", ale neodpověděl jste ani na otázku "Jak byste to udělal lépe". Vaše odpověď je pouze na otázku "jak byste to udělal", ale přesto Vám za odpovědi děkuji.
Pokud "pepř", tedy nějaký globální statický řetězec, přimícháte před hashováním, tak můžete poškodit původní algoritmus, protože ho změníte
Popravdě, to se mi zdá krajně nepravděpodobného, protože: a) to by byl opravdu velmi debilní hash, který by se nechal rozhodit "prodloužením" hesla, b) přidání pepře je z hlediska hashe to samé jako přidání (delší) soli.
Po objevení dalších hashů, což bylo několik různých variant MD5, které by se daly zjednodušeně popsat jako "MD5 se solí" a "MD5 se solí a pepřem" bylo cracknuto 2,6 milionu hesel za pár hodin a 11,2 milionu hesel za 10 dní.
1) ano, MD5 není považováno za bezpečné už pěkně dlouho, takže tohle není moc fér argumentace. 2) jediná funkce soli/pepře je ochrana proti předpočítanými nebo částečně předpočítanými hashi, proti hrubé síle pochopitelně nefunguje, ale to neznamená, že by to bylo k ničemu.
Popravdě, to se mi zdá krajně nepravděpodobného, protože: a) to by byl opravdu velmi debilní hash, který by se nechal rozhodit "prodloužením" heslaJakkoliv nepravděpodobné se to může zdát, tak je to bohužel reálné. Viz mnou odkazovaný bug v PrestaShopu, ve kterém použití "pepře" s bcryptem ořezalo hesla na 16 znaků.
b) přidání pepře je z hlediska hashe to samé jako přidání (delší) soli.Není, podívejte se prosím jak se solí pracují algoritmy, které ji podporují, např. bcrypt. Ten sůl jenom nepřipojuje, ale postupně přimíchává. Algoritmy jako MD5 a SHA-1 salt nepodporují, proto se sůl často jen "simuluje" připojením k heslu.
MD5 není považováno za bezpečné už pěkně dlouho, takže tohle není moc fér argumentace.Hesla jsou tak trochu jiný sport. Náhodně vygenerovaná a unikátní hesla dlouhá cca 16 a více znaků jsou bezpečně uložená i když se použije nesolená MD5. Nicméně to bylo jen doplnění kontextu a čísel k domněnce "pepř je lepší než pomalé hashování".
2) jediná funkce soli/pepře je ochrana proti předpočítanými nebo částečně předpočítanými hashi, proti hrubé síle pochopitelně nefunguje, ale to neznamená, že by to bylo k ničemu.To je pravda. Jen teda funkcí "pepře" není ochrana proti předpočítaným hashům, to je funkce "soli" (která má tedy ještě chránit proti tzv. narozeninovým útokům, které by se s přimhouřením jednoho oka daly také považovat předpočítané hashe). Pepř má sloužit k tomu, aby bez jeho znalosti nešlo hesla crackovat a vzhledem k tomu, že se neukládá do databáze, tak nelze získat únikem databáze. Nedovolil bych si tvrdit, že salt je k ničemu, diskuze byla o důležitosti "pepře" pro znemožnění crackování.
Jakkoliv nepravděpodobné se to může zdát, tak je to bohužel reálné. Viz mnou odkazovaný bug v PrestaShopu, ve kterém použití "pepře" s bcryptem ořezalo hesla na 16 znaků.
Aha, bcrypt hešuje z hesla jenom prvních 72 znaků. Takže jednoznačně debilní heš. Omezování hesla je jen koledování si o průser a 72 znaků je teda sakryš málo. Jen si představte, co se stane, když nějaká aplikace bcryptu nedopatřením předá heslo kódované jako UCS-4...
Ale díky, že jste mě na to upozornil, bcrypt mi od této chvíle "do domu" nesmí. Zlaté MD5...
"Bez otravování uživatelů" není můj názor, je to požadavek. Bezpečnost jde ruku v ruce s použitelností, slovy Aviho Douglena: Bezpečnost na úkor použitelnosti jde na úkor bezpečnosti. Nelze zbytečně zatěžovat uživatele pokud to není vysloveně nutné. A při změně hashování to potřeba opravdu není.Bezpečnost závisí na použitelnosti, ve svém komentáři jsem to jen naznačil, nepředpokládal jsem, že je nutné to explicitně popisovat. Co jsem naopak výslovně napsal, je to, že v případě pouhé výměny hashovací funkce za silnější bych hesla resetoval až po několika letech (pokud se uživatel mezitím nepřihlásil). Reálné otravování uživatelů by tedy bylo minimální, pokud vůbec nějaké – a nesrovnatelně menší třeba v porovnání s tím, že uživatele vůbec nutím vytvářet nějaký účet, místo aby se mohl přihlásit nějakým externím účtem (OpenID, Facebook, Google apod.).
Můžete mě prosím odkázat na nějaký reálný výzkum, který by Vaši domněnku potvrdil?Ta domněnka mi připadá natolik samozřejmá, že jsem po nějakém výzkumu nikdy nepátral. Máte vy nějaký reálný výzkum, který by ji vyvracel?
Všimněte si prosím, že žádné funkce na hashování hesel "pepř" nepodporují.A taky ty funkce pro hashování hesel očekávají na vstupu heslo v otevřeném tvaru. Což ovšem vůbec neznamená, že poskytování hesla serveru v otevřeném tvaru je dobrý nápad. Připomněl bych, že se tady celou dobu bavíme o workaroundu pro vážnou bezpečnostní chybu webových prohlížečů (nepodporují pořádně přihlašování metodou challenge–response) a bezpečnostní nedostatek protokolu HTTP (který neřeší vytváření a změnu hesel, a HTTP Digest s MD5 taky není úplně moderní) – takže argument, že se něco běžně používá, rozhodně neberu jako důkaz, že je to bezpečné.
Pokud "pepř", tedy nějaký globální statický řetězec, přimícháte před hashováním, tak můžete poškodit původní algoritmus, protože ho změníte.Stejně jako ten algoritmus změníte, pokud před hashováním heslo zahashujete stejným nebo jiným algoritmem. Rozdíl je v tom, že to „předhashování“ prokazatelně snižuje kryptografickou bezpečnost celé operace, zatímco přimíchání pepře (pokud se neudělá špatně) by mělo být z kryptografického hlediska neutrální (samozřejmě pokud se nenajde slabina té hashovací funkce, která by zrovna to přimíchání uměla zneužít).
Jako příklad snad postačí použití "pepře" v PrestaShopu, ve kterém díky tomu byla všechna hesla uměle zkrácena na 16 znaků.Tohle není žádný argument, zkazit lze cokoli. Pokud někde jako vstup do „heslovací“ funkce bcrypt použili omylem délku hesla místo samotného hesla, odepíšete jako nepoužitelnou i funkci bcrypt?
Navíc v realistickém modelu hrozeb by měla být možnost použití útoku SQL Injection k získání obsahu např. konfiguračních souborů, tedy i onoho "pepře".To asi záleží na tom, jak kde – já se nepohybuju ve světě PHP aplikací, takže SQL Injection je pro mne něco, o co se musí programátor dost snažit, aby to vyrobil. A napsat tu aplikaci tak, aby šlo přes SQL injection získat konfigurační soubor, to už by byla opravdu výzva. Navíc pokud má někdo v aplikaci SQL Injection, je únik hesel ten nejmenší problém. Dále, jestli se nepletu, medializované úniky v poslední době nebyly získané útokem přes aplikaci, ale útočník získal samotná data – buď nějaké zálohy nebo jiného dumpu databáze. Proti takovým únikům chrání pepř velmi dobře. Ostatně, představte si ten současný únik Mall.cz – kdyby byl použit bcrypt, nějaká hesla by se podařilo stejně získat. Kdyby byl použit pepř (rozumně), počet získaných hesel by byl přesně 0.
Tím se sníží bezpečnost takového řešení jena na "hash a případná sůl" a závisí tedy opět na použitém hashi.Ano, pokud útočník zná pepř, dostáváme se na původní úroveň bezpečnosti „hash soleného hesla“. Jenže s tím už se nedá nic dělat, protože heslo potřebujeme ověřit v okamžiku, kdy se uživatel přihlašuje, takže to nemůže trvat moc dlouho („Bezpečnost na úkor použitelnosti jde na úkor bezpečnosti.“). A útočník má možnost heslo louskat o několik řádů rychleji a ještě na to má na dost času. Navíc úspěšnost louskání hrubou silou závisí především na kvalitě hesla samotného. Takže zpomalování hashování je dobré leda tak pro dobrý pocit, při zabezpečení hesel je mnoho důležitějších kroků.
Mezi použitím nevhodných hashů (např. MD5) a hashů pro ukládání hesel (např. bcrypt s cost=10) je rozdíl 8 řádů, při použití vyššího costu i více. Může se to zdát málo, ale převedeno na čísla to znamená, že jde o generování kandidátů rychlostí 30 miliard pokusů za vteřinu vs. 650 pokusů za vteřinu.Ono se to nezdá málo, ono to je málo. Šest řádů smažete použitím botnetu místo jediného počítače. Pět řádů smažete tím, že na výsledek nebudete čekat jednu vteřinu, ale počkáte si „celý“ den. Více než 8 řádů umažu použitím pouhého 32bitového pepře (snad nikdo nebude takový šílenec, aby použil něco tak krátkého). Osm řádů vymaže uživatel tím, že přidá k heslu další čtyři znaky. Nějaké řády se umažou rozvojem techniky mezi dobou, kdy byl zprovozněn daný způsob ukládání hesel, a dobou, kdy je útočník začne louskat – jenom tohle (rozvoj techniky) a nic jiného stojí za tím, proč je dnes MD5 pro hesla slabá. Nejpozději za dvacet let budou bcrypt nebo Argon2 stejně slabé, jako dnes MD5 – ale pravděpodobně mnohem dřív (i kdyby to byly dobré hashovací funkce). Mimochodem, můžete odkázat na nějaký reálný výzkum, který by zkoumal kryptografickou bezpečnost bcrypt nebo Argon2? Protože přijít na to, že špatné použití pepře zkracuje hesla na 16 znaků, to je triviální. Přijít na to, že je něco špatně v kryptografické hashovací funkci, to je úplně jiná liga. A mně jímá hrůza pokaždé, když se někdo rozhodne, že nějakou ověřenou kryptografickou funkci „vylepší“.
Velmi pravděpodobně to za pár let dělat nebudete.Budu. Celou dobu řešíte, kolik zbyde hesel, u kterých nikdy k přehashování nedojde, protože se uživatel znovu nepřihlásí. A já fakt nemíním mít ještě za deset let v databázi hesla, která budou závislá na síle MD5 – protože mi nikdo nezaručí, že se za těch deset let neobjeví ještě nějaká pořádná díra v MD5.
Problémem je, pokud vývojáři používají hashovací funkce, které nejsou určené k ukládání hesel, tedy např. SHA-1 a MD5, pak je potřeba takováhle spartakiáda s přehashováváním. Když se používají doporučené funkce, tak stačí transparentně po přihlášení přehashovávat, hesla jsou stále dobře chráněna i při použití třeba onoho bcryptu s costem 10.Pro mne je důležité, že ty hashovací funkce, které nejsou primárně určené k ukládání hesel (dnes aspoň SHA-2), jsou experty prověřené kryptografické hashovací funkce. Za spartakiádu naopak považuju bcrypt a podobné.
Toto by bylo možné provést maximálně ve velkých organizacích, které tyto procesy dokáží zaručit, ale ve ani ty nemají důvod k uchovávání hesel v zašifrované podobě.Důvod je je velmi jednoduchý – předpoklad, že v budoucnosti bude potřeba použít jiný hashovací algoritmus, například vynucený protokolem. Třeba když někdo provozuje webmail a rozhodne se přidat podporu pro SMTP+IMAP, jsou mu jeho bcryptem zahashovaná hesla k ničemu, protože SMTP a IMAP používají jiné hashe.
Tohle jsou důvody, proč jste nejenže neodpověděl na mou otázku "Jak byste to bez otravování uživatelů udělal lépe, prosím?", ale neodpověděl jste ani na otázku "Jak byste to udělal lépe". Vaše odpověď je pouze na otázku "jak byste to udělal", ale přesto Vám za odpovědi děkuji.To, že vy si myslíte, že to není „lépe“, neznamená, že to není odpověď na uvedenou otázku. I kdyby to byla špatná odpověď, pořád to může být „odpovídající“ odpověď.
Šest řádů smažete použitím botnetu místo jediného počítače.Botnet s milionem počítačů, v každém z nich nevyužitá "lámací" grafická karta? Tady bych řekl, že máte velmi optimistický odhad.
daly zjednodušeně popsat jako "MD5 se solí" a "MD5 se solí a pepřem"
Jeminkote! S předem známým pepřem!