Door Anoniem: Door Anoniem: Een unieke token….
Speculatie: ik vermoed een hash.
En aangezien je makkelijk door allle rekeningnummers kunt bruteforcen heb je zo een rainbow table bij de hand.
Dat was in de jaren 80 en 90. Developers met opleiding gebruiken nu betere methoden zoals HMAC.
Hashfuncties zijn niet het probleem
Er is niks mis met ("ongekraakte") cryptografische hashes.
Een veel voorkómend probleem is dat onervaren programmeurs denken dat het zin heeft om korte en/of voorspelbare getallen (of karakterreeksen, door programmeurs "strings" genoemd, denk bijv. aan IPv4-, Ipv6- en MAC-adressen, BSN's en telefoonnummers) te pseudonimiseren middels whatever cryptografische functie: zonder het meenemen van een "secret" ("pepper", "IV" = Initialisatie Vector" of geheim gehouden cryptografische sleutel) krijg je dat nooit veilig als je ervan uitgaat dat de gebruikte functie niet geheim is of als je niet 100% zeker weet dat de functie geheim gehouden kan worden (wat zelden het geval is, ga uit van "nooit").
NVidia
Het hashen van een een korte string met een "gewone" (ongekraakte) cryptografische hashfunctie is zinloos, omdat je met een moderne grafische kaart in zeer korte tijd de hashwaarde van alle mogelijke input-combinaties kunt uitrekenen. Dat gaat tegenwoordig zó snel dat je de output niet eens meer in een rainbow table hoeft op te slaan (je vergelijkt gewoon elke berekende output met de hashwaarde die je in handen hebt, totdat je een match vindt).
Salts (die "even geheim" zijn als de resultaathash, normaal gesproken daarnaast worden opgeslagen) helpen ook nauwelijks nog.
Hergebruikte sterke wachtwoorden
Precies hetzelfde probleem speelt bij relatief korte wachtwoorden, maar ook bij
hergebruikte lange semi-random (of echt random) wachtwoorden (omdat die in "dictionaries", gebruikt door o.a. Hashcat en John, terecht kunnen komen).
Bij een voldoende lang random getal (of een voldoende lange random alfanumerieke string, of een voldoende groot blok bytes met elke mogelijke random waarde)
dat niet wordt hergebruikt speelt dat probleem niet.
HMAC
Bij een HMAC heb je twee inputs: de te pseudonimiseren reeks bytes en een "secret". De HMAC functie is een veilige vervanger voor het hashen van twee achter elkaar geplakte inputs: er zijn namelijk cryptografische hashfuncties die "informatie kunnen lekken" als je achter elkaar plakt.
Onraadbaarheid
Als je 100% zeker weet dat alle inputs cryptografisch random gegenereerde GUID's zijn (zie
https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-4,
https://peteroupc.github.io/random.html en
https://developer.mozilla.org/en-US/docs/Web/API/Crypto/randomUUID), is, in theorie, zelfs
MD5 goed genoeg (niet gebruiken, want teveel mensen snappen dit niet, en als later door derden GUID's worden aangeleverd kan het
wél fout gaan).
MD5
De reden daarvoor is dat MD5 vooral gekraakt is voor de situatie dat een kwaadwillende twee speciaal geprepareerde inputs genereert waarvan zij/hij weet dat deze dezelfde MD5 hashwaarde opleveren, en later de tweede input aanbiedt, bijv. om ergens onderuit te komen. Zie bijv. de plaatjes (met getallen er in) in
https://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities).
Sterk verzwakte sterke wachtwoorden
De volgende ogenschijnlijk sterke wachtwoorden moet
niemand meer gebruiken, want ze komen voor in "RockYou2021.txt". Nb. er zijn er veel meer zo, deze had ik uitgezocht speciaal voor een Duitse reactie (schrijven in die taal is niet mijn sterkste punt:
https://infosec.exchange/@ErikvanStraten/113923644127405769):
moc.tfosorcim.www
!!!!901118stephi!!!
1-behtjiu-11-bei-google
24enpkbysr7405eeqgdd
4548doubleboxmargins
ADEK.CHOJNOWSKI.3003
ADEKWATNOŚCIAMI
AlmA16sAnCheZ23
BARFRANKIERUNG1995
BARFUSSPARK-LIENEN
BARGAIN-CENTERZ-AMOS
BARGER,JUDITH,1948-
BRaNdSTIFTER"-ScHaU
Langer kan ook (ik voeg steeds een lege regel tussen om te voorkómen dat ze, op kleine schermen, in elkaar door lijken te lopen):
1_and_only_phatkat1_and_only_pimp_09
24brita29stephanqwe24brita29stephanrus
74e73aef4f51</h3>74e73aef4f51</title>
766e4373696a624arus766e4373696a624azxc
Angebot_1497697863Angebot_1497699863
CollegeStudent2011CollegeStudent2012
Guenter09111955rusGuenter09111955zxc
Kreuger2Kreuger2q10Kreuger2Kreuger2q11
ULRIKE.STIEHL-WEGEULRIKE.STRASSBURGER
X7t4yIDUyOQqQsAF777X7t4yIDUyOQqQsAF80
annika-rauch123rusannika-rauch123zxc
bloody_vampire_catbloody_vampire_chick
boriquasdoitbetterboriquasdoitright89
classicrockjunkieclassicrockjunkie21
duh_itz_katherineduh_itz_kaycie72369
e.undk.bielefeld1e.undk.bielefeld123
flag_of_discontentflag_of_djibouti.svg
gracieusshasyd34997gracieussouverein
heavy-metal-freakczheavy-metal-freaken
im_a_gay_homofobeim_a_gay_homosexual
jesuschristwisdomjesuschristwithhorns
k.,k.cdjb[drecyzitrk.,k.cdjb[gbnjvwtd0
lovin_my_lil_pinailovin_my_lil_prince
michaelandrewsteinmichaelandrewstephan
noneofyourbusinessnoneofyourbusiness!
o.ccu.rixx.be.x1337o.ccu.t.l.e.c.oust.y
panic_atthe_disco_5panic_atthe_disco_8
qqkenneth.a.wolfeqqkenneth.procureur
ride_my_skateboardride_my_small_pony
schmalleschmalle1schmalleschmalle123
the_lords_favoritethe_lords_follower17
ucer_tifyForever21ucer_tifyGeorge1984
vfktymrbqghbyw1977vfktymrbqghbyw1988
whocares@infotaxiwhocares@joymail.com
xxxsammi_is_sexyxxxxxxsammi_shexifulxxx
your_wellness1234your_wellness_coach
zvezdochetovcasz111zvezdochetovcasz113
Ondanks dat mensen (deels) in herhalingen vervallen, kun je dat niet zomaar zwakke wachtwoorden noemen.
Hoe gelekt
Het lijkt mij zeer onwaarschijnlijk dat bovenstaande plain text wachtwoorden middels brute-force uit hashes (welke functie dan ook) zijn achterhaald. Waarschijnlijk zijn zij, ofwel:
• Ingevoerd op nepwebsites (al dan niet via een gekaapte http-verbinding);
• Was de
échte server
zelf gehacked (mogelijk door een foute beheerder) en had de aanvaller toegang tot de wachtwoorden
vóórdat zij gehashed of versleuteld werden;
• Werden die wachtwoorden op de server "plain text" opgeslagen (ze kunnen ook -plain text- terechtkomen in logbestanden);
• Een Javascript aanleverende meekijkserver was gehackt waardoor aanvallers "in de browser" konden meekijken;
• De browser zelf was gehacked (of voorzien van een foute plug-in);
• Gepubliceerd als voorbeelden van hoe een sterk wachtwoord eruit zou kunnen zien;
• Waren zij opgeslagen in de versleutelde database een wachtwoordmanager waarbij een aanvaller toegang verkreeg tot die database
én het master password.
Fix: gebruik een wachtwoordmanager en laat deze
per account een zo lang als mogelijk random wachtwoord genereren. Check beslist ook "Veilig Inloggen" in
https://security.nl/posting/840236 voor andere eisen die je jezelf moet opleggen.