Bachelor's Thesis

Password Leaks Automated Processing with NoSQL

Final Thesis 1.65 MB

Author of thesis: Adam Havlík

Acad. year: 2025/2026

Supervisor: Ing. Jan Pluskal, Ph.D.

Reviewer: Ing. Vladimír Veselý, Ph.D.

Abstract:

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.

Keywords:

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)

znamkaEznamka

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

  1. Popište proces výběru vhodné NoSQL databáze a proč jste si vybral MongoDB.
  2. Diskutujte silné i slabé stránky Vaší implementace (které vyplynuly z obhajob) a popište způsoby nápravy chyb (a v případě publikace skrz váš repozitář https://github.com/xhavli/LeakChecker hypotetické termíny aktualizace).
  3. V implementaci využíváte API k nástroji https://hashes.com/en/tools/hash_identifier . Uveďte v čem je tato služba lepší, než kdybyste se danou funkcionalitu pokusil realizovat sám.
  4. Jaký je hlavní přínos vaší práce? Můžete uvést nějaký scénář jejího reálného nasazení?

Language of thesis

Slovak

Faculty

Department

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 report
Ing. 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.

Evaluation criteria Verbal classification
Informace k zadání

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.

Práce s literaturou

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 během řešení, konzultace, komunikace

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í.

Aktivita při dokončování

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í.

Publikační činnost, ocenění

Není.

Points proposed by supervisor: 55

Grade proposed by supervisor: E

Reviewer’s report
Ing. 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:



  • které mohlo být po technické stránce výrazně lepší,

  • kterému zároveň chybí robustní testování,

  • které je doprovozeno lehce podprůměrnou technickou zprávou.

Evaluation criteria Verbal classification Points
Náročnost zadání

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í.

Prezentační úroveň technické zprávy

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:

  • Úvodní kapitoly obsahují za mě příliš mnoho pasáží, které nejsou dostatečně relevantní k jádru problému řešeném prací (např. celá strana 10, kde se čtenářovi zdlouhavě povídá o různých prohlížečích a různých vyhledávačích bez jasné souvislosti na úniky dat).
  • Poznámka pod čarou 8 je zcela zbytečná.
  • Podkapitola 3.4 analyzuje jen úvodní datovou sadu z předchozí bakalářské práce, nikoli tu finální, se kterou pracuje i implementace. 
  • Kapitola 4 je příliš podobná té ze semestrálního projektu a neodráží za mě všechny důležité změny, které pak student na díle později realizoval a popisuje později až v Kapitole 5.
  • Kapitola 5 začíná na straně 28 a končí na straně 54. Oceňuji vývojové diagramy, ale očekával bych je spíš v kapitole návrhu. Testování zde obsažené mi přijde nedostatečné.
  • Kapitola 6 analyzuje datovou sadu (což bych očekávál v podkapitole 3.4) skrz implementovaný nástroj.
55
Formální úprava technické zprávy

Práce je psána ve slovenštině, nejsem proto schopen správně posoudit jazykovou korektnost.

Typograficky práce obsahuje pár šotků, např.:

  • chybějící mezera a špatné uvozovky na straně 6 u „The Onion Router"šifruje
  • využití krátké pomlčky - tam, kde by patřila dlouhá — (tj. všude tam, kde jsou výčty, např. strana 7)
  • anotace/nápisy v obrázcích by měly být větším fontem pro lepší čitelnost (např. Obr. 5.5 či 5.8)
65
Realizační výstup

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. 

55
Využitelnost výsledků

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.

Rozsah splnění požadavků zadání

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. 

Rozsah technické zprávy

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.

Práce s literaturou

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.

65
Topics for thesis defence:
  1. V implementaci využíváte API k nástroji https://hashes.com/en/tools/hash_identifier . Uveďte v čem je tato služba lepší, než kdybyste se danou funkcionalitu pokusil realizovat sám.
  2. Popište proces výběru vhodné NoSQL databáze a proč jste si vybral MongoDB.
  3. Diskutujte silné i slabé stránky Vaší implementace (které vyplynuly z obhajob) a popište způsoby nápravy chyb (a v případě publikace skrz váš repozitář https://github.com/xhavli/LeakChecker hypotetické termíny aktualizace).
Points proposed by reviewer: 59

Grade proposed by reviewer: E

Responsibility: Mgr. et Mgr. Hana Odstrčilová