"Saját fejlesztésű, md5-szintű kriptofüggvény"

Nemrég került a kezem ügyébe véleményezendő anyagként egy webes rendszer architekturális terve. Egészen meglepő volt, hogy a rendszer biztonsági funkcióinak felsorolásakor egyetlen érdemi, ám annál érdekesebb elem szerepelt a listában, ez pedig a "feltörhetetlen, titkosított formában történő jelszótárolás saját fejlesztésű, md5-tel egyenértékű kriptoeszközzel".

Némi utánakérdezés után kiderült, hogy ez gyakorlatilag annyit jelent, hogy a jelszavakat nem plain-textben tárolja a rendszer, hanem tárolás előtt hasheli egy "saját, md5-tel megegyező kriptográfiai erősségű algoritmus" használatával. Komoly diskurzus következett a fejlesztőkkel, ugyanis kimondottan nehezen fogadták el, hogy ebben a formában ezen biztonsági funkciók kétszer aláhúzott nullát érnek. Miért?

• A rendszer mögött dolgozó adatbázisban valamilyen módon ledarált formában ülnek a jelszavak - ez elvileg az utolsó védelmi vonal kellene, hogy legyen a biztonsági funkciók sorában. Ha a támadó hozzáfér az adatbázishoz, akkor már úgyis mindegy minden (vagy ha még nem az, pár SQL query után már az lesz), maximum a "damage control" valósítható meg a hashelt jelszavakkal.
• "A támadó úgyse tudja, hogy milyen saját algoritmussal hasheltük a jelszavakat, tehát ha a hashekhez hozzáfér, akkor sem tud mihez kezdeni velük". Népszerű tévhit, hogy a security through obscurity működő modell lehet elszánt támadó ellen is: tesztelő kollégáink sok-sok rémtörténetet tudnának mesélni arról a döbbenetes adag naivitásról, amivel felvértezve írják meg a fejlesztők saját kriptokönyvtáraikat. Alapvetően ott hibás az elképzelés, hogy a fejlesztők abból indulnak ki, hogy a támadónak kizárólag a hashek állnak rendelkezésére, nulla információja van a rendszerről, ahonnét jöttek - ebben az esetben még akár igaz is lehet a "security through obscurity", viszont valódi támadó esetén mire a hashek megvannak, a támadó mindent tud a rendszerről, beleértve a hash algoritmust is. Ha nem tudja, akkor pedig addig keres, amíg meg nem találja egy másik sebezhetőségen keresztül. Ha pedig a támadó már hozzáfér az adatbázishoz és a hashekhez, és mondjuk a kódot is kedvére böngészheti, amit lefuttat a bejelentkezőszkript az ellenőrzés során, nagyrészt gyerekjáték a "hash" feltörése. (Én például már láttam működő rendszeren olyan kétirányú "hashfüggvényt", aminek alapját egy bizonyos Julius nevű alak dolgozta ki még az ókorban). Elvileg kriptoanalízis is végrehajtható a naivan implementált kriptoeszközök kimenetein, azonban a tapasztalatok szerint mindig van egyéb mód is (például emlékezzünk a Hacktivity drupáltörős bónuszjátékának célpontjára, amelyben az adminjelszó md5-hashelve nem törődött meg, viszont a jelszóemlékeztető kihasználásával megkerülhető volt a törés a GIJohnnal. )
  
• Ha a bejelentkezés során kliensoldalon történik a hashelés, gyakorlatilag olyan, mintha ott se lenne a hash: a támadó lefigyeli az adatfolyamot, és a hash-t hamisítja be saját kérései kiadásakor, mindehhez még "jelszótörni" sem kell.
• A HTTP plaintext. Ha nincs hálózati szintet titkosítva az adatforgalom, akkor megint csak lehet temetni a hash-elt jelszavakat az adatbázisban.