Podpora :: RAR Support

2021-05-12 09:13:48
Tom
Rychlost prolamování hesla

Dobrý den,

chtěl bych se zeptat ohledně prolamování hesel u RARu.
U celkem hodně SW je doporučeno nepoužívat RAR5, protože jde prolamovat rychleji jak RAR4.
Sám jsem si to zkusil a rozdíl je až 30-40% vyšší rychlost u RAR5.
Myslel jsem, že RAR5 bude bezpečnější.

Předpokládám, že to bude touhle vlastností, kterou RAR4 neobsahuje:

b) speciální kontrolní číslo pro heslo umožňuje ve většině případů odhalit špatné heslo bez nutnosti rozbalení celého archivu. Ovšem ne zas tak rychle, aby to zásadním způsobem urychlilo hledání hesla tzv. hrubou sílou.
2021-05-12 09:33:11
Ľubomír Mlích
Re: Rychlost prolamování hesla

Dobrý den,

rychlost prolamování se odvíjí od délky vámi zvoleného hesla. Když zvolíte 30 znaků, tak ne těch 30-40 procentech nezáleží.

S pozdravem,

Ľubomír Mlích

2021-06-06 10:11:01
Tom
Re: Rychlost prolamování hesla

Je to už oficiální - ani jeden prolamovací SW nedoporučuje použití RAR5 a šifrování.
Zde je např. porovnání: https://blog.elcomsoft.com/2021/04/breaking-rar5-and-7zip-passwords/

Kolik uživatelů používá heslo o 30 znacích? Myslím, že jich mnoho nebude.
Lepší je už použití RAR4.
Z tohoto důvodu jsem nucen RAR5 nepoužívat.

2021-06-06 19:59:30
Ľubomír Mlích
Re: Rychlost prolamování hesla

Dobrý den,

pěkný článek, zajímavé je, že autoři neuvádí, proč naměřili 3x rychlejší zkoušení hesel.

Doporučuji podívat se například sem:

https://www.password-depot.de/en/know-how/brute-force-attacks.htm

Když máte 8 znakové heslo, vyzkoušet všechny hesla lze zhruba za tři dny.

Když máte 9 znakové heslo, bavíme se o 9 letech.

Když máte 12 znakové heslo, bavíme se o 17 milionech letech.

S tím třicetiznakovým heslem jsem to přehnal, ale když si zvolíte 12 znakové heslo, myslím si, že váš archiv bude v bezpečí dokud někdo nevymyslí jak zlomit použitou šifru nebo dokud se k hledání hesla nezačnou používat kvantové počítače.

Můj osobní názor je, že uživatelské heslo do nějakého systému nepotřebuje mít velké a malé písmena a speciální znaky. Útočník koneckonců nemůže vědět, jestli je používate. Délka hesla určuje jeho zlomitelnost hrubou silou. Pak je tu druhá věc - slovníkové útoky, tj. vaše heslo by nemělo být ve slovníku 100 000 nejčastěji používaných hesel (s přidaným číslem na konci, velkým písmenem na začátku).

S pozdravem,

Ľubomír Mlích

2021-06-07 18:22:59
Tom
Re: Rychlost prolamování hesla

> zajímavé je, že autoři neuvádí, proč naměřili 3x rychlejší zkoušení hesel.

WinRAR now stores a password hash within the compressed archive, checking the password before attempting the extraction. The design goal was speeding up the extraction. The developers mentioned that the chosen hash function was intentionally slow and based on PBKDF2 to slow down the attacks. However, this is still much faster and mush easier than extracting a file and calculating the checksum the way it was done in the RAR4 format. In the end, we’ve been able to build an attack that works significantly faster on the new RAR5 format compared to the older RAR4.

Článek, na který odkazujete je z roku 2012. Dnes jsou rychlosti mnohem vyšší.
Dále tabulka zobrazuje celkový čas potřebný pro vyzkoušení všech kombinací hesel. Pokud je uvažováno o útoku hrubou silou a heslo (např. o 10 znacích) bude začínat číslicí, je pravděpodobné, že bude uhodnuto dříve jak heslo o stejné délce začínající "z".

2021-06-07 20:10:09
Ľubomír Mlích
Re: Rychlost prolamování hesla

> Článek, na který odkazujete je z roku 2012. Dnes jsou rychlosti mnohem vyšší.

To je pravda, ale princip se nemění. Pro útoky hrubou silou je důležitá délka hesla a složitost stoupá exponenciálně. Jestli je to třikrát méně nebo více ten princip neovlivní.

Navíc můj názor je, že útoky hrubou silou ani moc praktické nejsou. Slovníkový útok bývá účinnější. A nejúčinnější metoda je dostat se k heslu jinak. Proč bych měl pronajímat superpočítač nebo botnet, aby vyzkoušel všechny možnosti, když si můžu vzít pistoli a přiložit ji k hlavě někomu, kdo to heslo zná?

Útok hrubou silou je velmi nepraktický, předám informaci dál ER, že jste se na to ptal a navrhnu přidat tří sekundové čekání při zadání špatného hesla, jako opatření. Ale zároveň si myslím, že toto opatření akorát dopadne na obyčejné uživatele, kteří to heslo zadají špatně a pak budou muset ty tři vteřiny čekat až to budou moct zkusit znova.
 

2021-06-07 20:19:43
Ľubomír Mlích
Re: Rychlost prolamování hesla

Rozmyslel jsem si to, nic psát nebudu.

Když tam bude prodleva, tak to nic neřeší, prostě se hádání jenom pustí paralelně.

Nejlepší obrana proti tomuto je používat dostatečně dlouhé heslo. Myslím si, že není velký problém toto heslo mít někde uložené (zašifrované), takže se k němu dostanete jenom vy. Myslím, že pokud na to používáte skript, tak to heslo musí být tomu skriptu dostupné a musíte ho mít někde uložené tak jako tak. Myslím si, že používat 30 znakové heslo je naprosto reálné.

2021-06-07 22:08:12
Tom
Re: Rychlost prolamování hesla

Umělou prodlevu jde odmazat např. z unRARu, kde jsou dostupné zdrojáky.

Když jsme u těch hesel, koukněte na tento obrázek: https://uloz.to/file/gVzG7WVkuQMB/1-png
Takhle to vidí správce procesů na linuxu.
Řekněte, co je podle Vás špatně. Příkaz byl dokončen, ale něco tam vadí.

2021-06-08 20:04:05
Ľubomír Mlích
Re: Rychlost prolamování hesla

Na první pohled bych tipnul, že "Tohle je heslo" by mělo být v uvozovkách aby bylo bráno jako jeden parametr

2021-06-08 20:40:58
Tom
Re: Rychlost prolamování hesla

Původně to bylo v uvozovkách, tohle se jenom takhle zobrazilo.

Dokázal jste přečíst heslo, které bylo použito pro archivaci. Tohle dokáže udělat i jiný proces.
Má to být takhle: https://uloz.to/file/GtWYS0UecxWR/2-png

2021-06-08 21:05:51
Ľubomír Mlích
Re: Rychlost prolamování hesla

Pokud vím pro řešení tohoto problému se dá použít například příkaz:

rar a -p`cat .soubor_s_heslem` nazev_archivu.rar soubory k archivaci

.soubor_s_heslem by měl mít nastavené práva 400, aby se k jeho obsahu dostalo co nejméně lidí.

Řeší se to například zde: https://stackoverflow.com/questions/3830823/hiding-secret-from-command-line -parameter-on-unix