Přístupnostní navigace
E-application
Search Search Close
Bachelor's Thesis
Author of thesis: Adam Havlík
Acad. year: 2025/2026
Supervisor: Ing. Jan Pluskal, Ph.D.
Reviewer: Ing. Vladimír Veselý, Ph.D.
This thesis deals with automated processing of leaked user credential databases, which are commonly found on the internet in various formats and structures. It analyzes the distribution channels of such data, their structure and encoding. Based on this analysis, the LeakChecker tool is designed and implemented. The tool processes files in a streaming and parallel fashion, detects their format, encoding and types of contained attributes, and stores records in a MongoDB NoSQL database. It provides searching over the processed data by a wide range of attributes including email address, domain, IP address and phone number. The tool was deployed on a deduplicated dataset of 1.1 TB in size, processing nearly 9.67 billion records.
data breaches, big data, data analysis, credentials, automated processing, NoSQL, Mon goDB, .NET, C#
Date of defence
16.06.2026
Result of the defence
Defended (thesis was successfully defended)
Grading
E
Process of defence
Student nejprve prezentoval výsledky, kterých dosáhl v rámci své práce. Komise se poté seznámila s hodnocením vedoucího a posudkem oponenta práce. Student následně odpověděl na otázky oponenta a na další otázky přítomných. Komise se na základě posudku oponenta, hodnocení vedoucího, přednesené prezentace a odpovědí studenta na položené otázky rozhodla práci hodnotit stupněm E.
Topics for thesis defence
Language of thesis
Slovak
Faculty
Fakulta informačních technologií
Department
Department of Information Systems
Study programme
Information Technology (BIT)
Composition of Committee
prof. Ing. Adam Herout, Ph.D. (předseda) doc. Ing. Michal Bidlo, Ph.D. (místopředseda) Ing. Jaroslav Dytrych, Ph.D. (člen) Ing. Ivana Burgetová, Ph.D. (člen) Dr. Ing. Petr Peringer (člen)
Supervisor’s reportIng. Jan Pluskal, Ph.D.
Student dokončil druhou iteraci zadání a předkládá funkční nástroj LeakChecker pokrývající extrakci, detekci kódování, detekci formátu, detekci položek a perzistenci do MongoDB, doplněný o sadu 946 automatizovaných testů a jednoduché grafické rozhraní postavené nad Blazor Server. Nástroj byl nasazen v "ostré prevádzce na produkčním stroji" a zpracoval část deduplikované datové sady o objemu přibližně 280 GB s 9,67 miliardy záznamů. Tyto výsledky dokládají, že student je v základní míře schopen dotáhnout inženýrské zadání do funkčního celku.
Naopak vyhodnocení samotného běhu odhalilo zásadní slabiny v návrhu, na něž jsem během konzultací opakovaně upozorňoval. Naměřená propustnost zpracování přibližně 2,65 MB/s a celkový čas nad přibližně 280 GB dat ve výši třiceti hodin, k nimž je třeba připočítat dalších 39,5 hodiny pro stavbu indexů, představuje na použitém hardwaru velmi nízkou rychlost a ukazuje, že volba MongoDB jako primárního úložiště nebyla pro daný typ úlohy vhodná. Stejně tak nasazení složeného indexu (Gender, _id) nad atributem s extrémně nízkou kardinalitou, jehož velikost v produkčním běhu dosáhla 100 GB, je elementární návrhové selhání, které mělo být odchyceno již ve fázi návrhu, nikoli až ve fázi zpracování celé datové sady. Architektonicky problematické je rovněž rozhodnutí spoléhat při identifikaci hashů na vzdálené veřejné API služby hashes.com a při detekci pojmenovaných entit na externí Python proces komunikující přes localhost, což vnáší do jádra zpracování síťovou závislost a režii, která dále snižuje propustnost. Drobnější, ale příznačné jsou pak nedostatky jako trvale duplicitní popis stejných mechanismů v návrhu a implementaci, povrchní diskuze k-anonymity v sekci grafického rozhraní nebo opomenutí systematického měření poměru CPU a I/O využití během běhu.
Navrhuji práci hodnotit stupněm E jako dostatečnou.
Jedná se o druhou iteraci zadání bakalářské práce, jejíž první vypsání v akademickém roce 2024/2025 student úspěšně nedokončil. Cílem práce je automatizované zpracování databází uniklých přístupových údajů, jejich perzistentní uložení do NoSQL databáze a vyhledávání nad širokým spektrem atributů. Téma navazuje na bakalářskou práci Jakuba Dvořáka [5] a od počátku bylo známo, že klíčovou výzvou je zpracování dat o velikosti v řádu jednotek terabajtů, kde rozhodují volby na úrovni návrhu úložiště a paralelizace. Z mého pohledu se jedná o zadání průměrně náročné po teoretické stránce, avšak nadprůměrně náročné po stránce inženýrské, kde úspěch stojí a padá s rozumnou volbou technologií a střízlivým časovým plánem. S dosaženými výsledky nejsem spokojen. Student měl od první iterace zadání jasně danou velikost vstupních dat i nutnost paralelního a proudového zpracování, přesto v klíčových rozhodnutích, zejména volbě úložiště a parametrizaci výpočetního stroje, postupoval živelně a bez ohledu na opakovaná doporučení vedoucího.
Student samostatně nalezl 27 zdrojů, mezi nimiž jsou jak recenzované publikace (Graupner, Jaeger, Thomas, Heen, Burg), tak online materiály a blogové zápisky. Vzhledem k povaze tématu je převaha online zdrojů přirozená. Citační aparát je v textu použit většinou korektně, byť na některých místech (např. v kapitolách 2 a 4) jsou citace situovány spíše do úvodů odstavců a u jednotlivých myšlenek chybí přesnější vazba. Rešerše stávajícího stavu je dostatečná pro úroveň bakalářské práce, hlubší kritická diskuze srovnatelných nástrojů však chybí.
Aktivita studenta byla po celý akademický rok nárazová a soustředila se výhradně do období bezprostředně před deadliny semestrálního projektu a finálního odevzdání. Konzultace probíhaly nepravidelně, zpravidla z popudu studenta a v intervalech několika týdnů. Na konzultace student docházel pouze sporadicky připraven a opakovaně se vracel k otázkám, které byly v dřívějších konzultacích již uzavřeny. Doporučení k volbě úložiště, konkrétně rezervovaný postoj k MongoDB a požadavek na zdůvodnění výběru NoSQL technologie vzhledem k charakteru workloadu, student převzal pouze formálně a v textu práce je technologie obhajována převážně odkazy na obecné benchmarky YCSB, nikoli vlastní úvahou nad konkrétními požadavky úlohy. Místo soustředění na klíčové aspekty zpracování velkých dat (propustnost vstupně-výstupních operací, granularita dávek, paměťový profil indexů) se student opakovaně vracel k dílčím detailům parserů a heuristik, jejichž dopad na celkový výkon byl marginální.
Práce byla dokončována až do poslední chvíle. Specifikaci cílového stroje pro produkční běh student zahájil 20. dubna 2026, tj. tři týdny před termínem odevzdání, přičemž ani v této komunikaci nebyl schopen samostatně určit parametry virtuálního stroje a odhad úložiště prošel několika iteracemi. Vlastní nahrávání dat na cílový stroj proběhlo 30. dubna a samotné měření a vyhodnocení tak dobíhalo prakticky až do předposledního týdne před odevzdáním. Žádost o závěrečnou konzultaci student zaslal 6. května, tj. sedm dnů před odevzdáním, čímž porušil pravidlo dohodnuté na začátku roku, že poslední konzultace a předání práce k zpětné vazbě probíhají nejpozději čtrnáct dnů před odevzdáním. Finální podoba textu se mnou tedy nebyla konzultována a do textu se promítá řada drobných formálních i obsahových nedostatků, např. překlepy, duplicitní popis stejných mechanismů v sekcích 4.3 a 5.4, nekonzistence v zápisu jednotek a názvů technologií.
Není.
Grade proposed by supervisor: E
Reviewer’s reportIng. Vladimír Veselý, Ph.D.
Výslednou práci hodnotím jako dostatečnou (tedy stupněm E) s možností polepšit si před komisí dle obhajoby. Vzniklo funkční dílo:
Evaluation level: průměrně obtížné zadání
Práce je součástí dlouhodobých výzkumných aktivit NES@FIT. Cílem práce bylo otestovat na reálných datech rychlost jejich zpracování i ve chvílích, kdy tato data jsou "znečištěná" (ve smyslu změněných kódování, změněných schématů, výskytu mojibake. aj.) a jejich následné nahrátí do nějaké NoSQL DB pro potřeby perzistentního uložení a dotazování se. Svou povahou se tedy jedná o průměrně obtížné zadání.
Práce je sice strukturovaná, za mě ale nelogicky. Nepříspívá tomu, ani že v úvodu chybí odstavec právě o strukturování práce do kapitol a co se v nich čtenář dozví. Kapitoly navazují a kopírují myšlenkové postupy a pokroky studenta při řešení práce, leč ne vždy se s nimi dokáži jako čtenář ztotožnit:
Práce je psána ve slovenštině, nejsem proto schopen správně posoudit jazykovou korektnost.
Typograficky práce obsahuje pár šotků, např.:
Technické řešení se sestává z řady modulů napsaných v jazyce C# sestávající se z desítek autorských souborů se zdrojovými kódy. Realizace zahrnuje jak back-endovou, tak front-endovou část (s akcentem na výstupy zpracování a možnost vyhledávání v datech). U některých zdrojových souborů je indikováno, že pocházejí z pera AI. Student během obhajoby byl schopen vysvětlit vybrané části kódu a jejich funkcionalitu a ve struktuře kódu se orientoval.
Z technické zprávy lze zhodnotit, že aplikace se jeví funkční a dělá, co bylo požadované zadáním, leč při osobní obhajobě se ukázalo, že implementace má limity použitelnosti. Např. zpracování cca 1,5 MB velkého souboru ve formátu *.sql trvalo přes 10 minut. Student pochopitelně vysvětlil, proč tomu tak je (měnící se schéma v souboru a nutnost jeho znovudetekce), ale z praktického hlediska je výsledná implementace rozumně použitelná jen na "čistá", nikoli "špinavá" vstupní data. Implementace využívá navíc i externích služeb (API volání vůči hashes.com), čehož důsledkem pak narůstá režie při běhu.
Práce má kompilační charakter a představuje vývoj softwarového díla (sadu nástrojů pro zpracování/uložení leaků a dotazování se nad nimi v databázi) při použití stávajících technologií (různé typy NoSQL databází) ve specifické doméně (obecně spousta malých i velkých textových souborů s potenciálně různě nevalidními daty). Výsledek je funkční, ale za mě jen ve fázi prototypu nikoli produkční aplikace. Během obhajoby se bohužel i ukázalo, že část práce věnující se vyhledávání v naimportovaných datech postavená nad MongoDB několikráte spadla.
Evaluation level: zadání splněno s drobnými výhradami
Všechny body zadání byly splněny, leč k poslednímu, a to testování mám výhrady. V technické práci jsou pasáže věnující se testování (tj. podkapitola o automatizovaných testech 5.7 a měření databází v 5.8) velmi strohé. V Kapitole 6 se počítají statistiky na využití oddělovačů a typech kódování; mnohem důležitější by však bylo zhodnocení implementace s ohledem na její výkonostní, paměťové a úložišťové nároky.
Evaluation level: je v obvyklém rozmezí
Práce má 61 stran textu v husté LaTeXové šabloně, 69 stran i s pomocnými provozy. Dle nástroje https://app.fit.vut.cz/theses-checker/ na počítání normostran, má 82,44 normostran. Kolem a kolem je tedy je tedy mírně nad obvyklým rozmezím BP.
Student v práci cituje z dostatečného (27 pramenů) množství relevantních zdrojů, kde majoritu tvoří relevantní vědecké články k tématu. Během obhajoby se ale ukázalo, že využití některých pramenů (např. [18]) student popletl či nebyl schopen obhájit vyvozenou argumentaci v práci s ohledem na obsah pramenu.
Grade proposed by reviewer: E
Responsibility: Mgr. et Mgr. Hana Odstrčilová