Dneska dorazila otázka:
... Pak jsem se ale zacetl do ruznych doporuceni, napr http://cybercoyote.org/classes/wifi/wpa2.shtml a vsude se pise, ze nazev site ma byt nahodne generovanych 32 znaku a heslo 64 znaku ...
Due to the naive design of WPA2, the name of your network is the starting point for hackers. It is broadcast in the clear, and it's easy to look up your encryption key on widely available rainbow tables if your SSID is simple.
... Já jsem dosud žil v domění, že na názvu SSID záleží jen do tý míry, aby pokud možno neobsahovalo jméno firmy a tak nelákalo záškodníky. A že s 20znakovým heslem jsem v klidu. I když mám teda pocit, že jsem něco o vlivu dálky SSID taky nedávno čet. Ale když nad tím teď přemejšlím, tak mi není, jasný proč by to mělo mít vliv ...
Odpověď
To jsou mi zase rady. A nějaká teorie o jednoduchém SSID jak to jde pak strašně jednoduše krekovat pomocí rainbow-table.
Nezkoumal jsem to nějak moc do detailu, ale WPA a WPA2 údajně používají SHA-1 hash hesla zasoleného SSID (pairwise transient key (PTK)). To znamená, zjednodušeně, že se heš generuje z heslo+SSID. Tím se ten zahešovaný text prodlouží (obrazně řečeno, ono se to mixuje dohromady samozřejmě). Solí se to SSID aby nešlo poznat rovnou, že dvě sítě mají stejné heslo. Sůl je z definice soli známá a veřejná.
Pokud by útočník získal výslednou heš(heslo+SSID), tak z toho heslo přímo nedostane, od toho je tam ta hash. Může zkusit buď brute-force, nebo rainbow-table.
Aby to bylo lépe chráněné proti brute-force tak se ta SHA-1 hash zatočí ve skutečnosti 16388 krát, výpočet je tudíž poměrně pomalejší. Rychlost brute-force kreku pomocí https://hashcat.net a jedné GPU karty to krásně dokumentuje dole v tabulce. Zatímco to je schopné počítat pro SHA-1 celých 3 037 000 000 heší za sekundu, tak v případě WPA/WPA2 to dokáže pouze 142 000 heší za sekundu.
Jak dlouho by tedy trvalo kreknout WPA heslo z takto zahešovaného produktu? Řekněme heslo osm znaků, na každé pozici znaku cca 80 možných (26 malých, 26 velkých, 10 čísel a paušálně do 80 speciální znaky). Takových hesel na brute-force je 80^8 = 1 677 721 600 000 000. Děleno 142 000 za sekundu je 374 let.
Jak je na tom rainbow-table? Zaprvé si musíte uvědomit, že tu rainbow tabulku musí nejprve někdo napočítat, což by na tom jednom GPU trvalo přesně stejně, tzn. 374 let. Zadruhé to bude delší, protože rainbow tabulku musíte počítat pro osolená hesla. Takže v případě SSID délky 3 znaky a hesla pořád jen osmiznakového by to trvalo 80x80x80x374 let což je 192 milionů let. Možná trošku méně, protože do SSID si nedáváte speciální znaky.
A nejspíš ještě méně, protože každé dva roky se zdvojnásobuje výkon hardware, takže by se to postupem času zrychlovalo - až mě bude 90 let (je mi 36 let tzn. 2^27 krát rychlejší krek), tak to bude akorát hotovo.
Napočítat je pěkné. Ale taky musíte uvážit, že se ta tabulka musí někde uložit. Rainbow tabulka pro hesla osmiznaková má velikost 460 GB. Jenže tady při tříznakovém SSID máme heslo už jedenácti znakové. Taková tabulka by byla něco jako 10x10x10x460 GB (neroste to osmdesátkrát, rainbow-table jde komprimovat), což dělá pěkných 460 TB.
Takže až to ti borci z článku za 50 let napočítají, tak v té době už to asi moc místa žrát nebude :-)
Samozřejmě se dá spekulovat o tom, že bychom mohli počítač na více grafických kartách, ale to by zase stálo mnohem víc peněz. A to se tu bavíme o hesle osmiznakovém, což doufám každý už dávno ví, že osmiznaková hesla jsou obecně hodně špatně. Libovolné časy si vynásobte osmdesáti pro každý další znak v hesle.
A ani tak nemá útočník vyhráno. Má sice napočítanou rainbow-tabulku hodnot PTK. Jenže ono se to PTK nepřenáší jen tak samo, samozřejmě :-) To by se dal udělat reply útok. Každé ověření znovu ještě zasolí to PTK nějakým randomem.
Takže tu tabulku potom vezmete a opět netriviálně (ale už rychleji) přepočítáváte na jejím základě celou tu ověřovací transakci.
Naivní design?