Nederlandse dienst kraakt in drie dagen meer dan helft Hookers.nl-wachtwoorden

De Nederlandse dienst Scattered Secrets is er naar eigen zeggen in geslaagd om 'met minimale inspanning' 57 procent van de uitgelekte wachtwoorden van accounts van Hookers.nl te kraken. Bij het kraken van bcrypt-hashes gebruikte de dienst fpga's.

Scattered Secrets nam de dataset van meer dan 292.853 useraccounts van het Nederlandse prostitutieforum Hookers.nl. De database van de site kwam half oktober op straat te liggen via een kwetsbaarheid in vBulletin, het platform achter het forum. In de dataset zaten 290.871 wachtwoorden en bij 166.328 daarvan lukte het om die kraken.

Het gros daarvan was eenvoudig te achterhalen, doordat ze nog met achterhaalde gesalte md5-hashes waren verhaspeld. VBulletin paste deze techniek toe tot 2012. Door een Nvidia RTX 2080 Ti in te zetten, wist de dienst in korte tijd 154.653 wachtwoorden van de accounts te achterhalen.

Sinds het verschijnen van versie 5 van vBulletin in 2012 gebruikt het platform, en daarmee Hookers.nl, het veiligere bcrypt voor hashes. Hookers.nl is sinds 2002 online en slechts een beperkt deel van de wachtwoorden is sindsdien met bcrypt gehashed: 49.324 wachtwoorden oftewel 16,8 procent van het totaal. Hoewel bcrypt-hashes aanzienlijk moeilijker te kraken zijn, lukte het om 11.675 wachtwoorden te achterhalen.

Het team deed dit door gespecialiseerde crackers op basis van fpga's, oftewel field programmable gate arrays, in te zetten. Volgens Scattered Secrets presteert een enkel systeem op basis hiervan gelijkwaardig of zelfs beter dan een heel serverrack met high-end gpu's. In totaal duurde de crackingsessie drie dagen.

Uit de top 35 gekraakte wachtwoorden blijkt dat de populairste wachtwoorden relatief kort en simpel waren. Opvallend was dat 'vRbGQnS997' in totaal 1320 keer en daarmee het meest gebruikt was. Een verklaring is dat dit geautomatiseerd werd aangemaakt voor spamactiviteiten. Andere bevindingen van de analyse zijn dat sommige accounts geregistreerd zijn met mailadressen met domeinnamen van overheidsorganisaties, zoals ministeries, en dat uit ip-adressen blijkt dat het forum veelvuldig vanaf bedrijfsnetwerken werd bezocht.

Reacties (130)

[gunghir]

" Het team deed dit door gespecialiseerde crackers op basis van fpga's, oftewel field programmable gate arrays, in te zetten. Volgens Scattered Secrets presteert een enkel systeem op basis hiervan gelijkwaardig of zelfs beter dan een heel serverrack met high-end gpu's. In totaal duurde de crackingsessie drie dagen."

Kan iemand uitleggen hoe dit mogelijk is? Onlangs heb ik zelf een DE10-NANO aangeschaft.
Enkel voor emulatie van oude hardware,

[PinQ]

Een FPGA gebruik je door de logica die het uit moet voeren te beschrijven (bijv. and- en or-poorten en hoe deze gekoppeld zijn). Het verschil met een CPU is dat een CPU wel uit logica bestaat maar niet alle logica een CPU is. Dus met een FPGA kun je vrijwel alle processoren 'emuleren' (complexiteit even negeren). Maar met een FPGA kun je nog veel meer. Want een CPU is bedoeld om met een beperkte set instructies allerlei (general purpose) taken te kunnen uitvoeren. Deze taken zijn typisch sequentieel, dus lees data van geheugen, voer een vermenigvuldiging uit en voer daarna een optelling op deze data uit en schrijf het terug naar geheugen. Complexe algoritmen zullen hiermee dus uit een veelvoud van stappen bestaan die elk worden uitgevoerd met een bepaalde kloksnelheid.

En FPGA kan hier een verbetering bieden omdat je in een FPGA specifieke operaties kunt beschrijven. Dus bijvoorbeeld het optellen en vermenigvuldigen beschrijf je in 1 keer waardoor het versneld uitgevoerd kan worden. Meestal maak je hier gebruik van een pipeline aan operaties waardoor het veel memory IO scheelt.

Een FPGA wat specifiek voor een dergelijk doel is gemaakt is dus niet in staat om general purpose problemen op te lossen maar alleen het specifieke probleem waarvoor het geprogrammeerd is. Voor een ander probleem dien je een nieuwe 'firmware' te maken.

[PuzzleSolver]

Goed verhaal, mooi uitgelegd. Het is wel belangrijk om te vermelden dat het aantal varieties in FPGA's enorm is. De door gunghir aangehaald DE10-NANO bevat een Intel Cyclone FPGA die ook nog een ARM cpu aan boord heeft voor de general purpose stuff,

https://www.intel.com/con...html#introtext_1276892109

Deze is in veel variaties beschikbaar:

https://www.intel.com/con...clone-v-product-table.pdf

Verder zit er natuurlijk overhead op een FPGA gezien de AND's en OR's die je gebruikt in je ontwerp allemaal veel uitgebreider zijn dan een normale AND of OR in een CPU en bevatten dus ook een hoop ongebruikte transistoren. Vandaar dat de volgende stap een ASIC is (dedicated gebakken chip) die je kan baseren op hetzelfde ontwerp. Zo is het destijds ook gegaan met de bitcoin miners,

Hier staat meer uitleg over hoe en waarom ze FPGA's gebruiken:
https://medium.com/@Scatt...of-passwords-6773af298172

edit:
Extra links en info

[Reactie gewijzigd door PuzzleSolver op 25 juli 2024 02:57]

[kdeboois]

De FPGA kunnen inmiddels door middel van softcores ook prima generieke CPU’s implementeren en zo general purpose problemen oplossen. In theorie kun je er daar honderden van kwijt wat een behoorlijke processing kracht kan hebben.

http://fpga.org/2019/08/1...anx-at-hot-chips-31-2019/

[cdwave]

Softcore in FPGA is niet efficient. De resulterende cores lopen op teleurstellende snelheden (orde 300MHz) en hebben heel slechte IPC. Daarom komen er steeds meer modelen met ingebakken "harde" CPU cores.

Softcores zijn leuk voor emulatie en wat besturing enzo.

[kdeboois]

Soms zit de kracht in de eenvoud van de implementatie en dan zijn ze echt zeer krachtig. Je kan het systeem rond de softcore namelijk strippen tot het puur noodzakelijke en het is nog altijd veel sneller te implementeren dan een complexe State-machine.

De performance delen implementeer je in pure Hardware en de huishouding doet de softcore. Win-win

[cdwave]

FPGA's zijn overigens gebaseerd op RAM. Je kunt ze dus onbeperkt vaak voorzien van nieuwe firmware, en ook afzonderlijke delen onafhankelijk bijwerken. De programmeertijd hangt vooral af van hoe snel je de firmware data aan kunt leveren, en dat kan dus in enkele milliseconden.

Ee zit ook heel veel verschil in de grootte, zo'n D10 is een kleintje. De echt grote jongens stoken makkelijk 150W weg en kosten meer dan mijn auto...

FPGA's blinken eigenlijk nergens echt in uit, maar ze zijn in kleine oplages veel goedkoper dan ASICs. En je kunt er echt alles mee maken.

Ze zijn ook heel populair voor diverse bitcoins - met name coins die ontworpen zijn om niet door ASICs te worden geimplementeerd zoals Raven en Ethereum - bijvoorbeeld omdat ze voor dat soort taken minder stroom nodig hebben dan GPUs.

[banaj]

In een andere blog van Scattered Secrets komt het voor een gedeelte aan de orde.

[gunghir]

Mooi artikel bedankt!
@PinQ jij ook!

[Reactie gewijzigd door gunghir op 25 juli 2024 02:57]

[swhnld]

In de basis komt het er op neer om de software te stroomlijnen voor een bepaalde taak door gebruik van specifieke hardware. Je ziet dit bijvoorbeeld ook veel voor Bitcoin gebeuren, dat grafische kaarten ingezet worden omdat die goed zijn in bepaald rekenwerk.

Voor een leek, een normale auto kan zand vervoeren, maar als je meer zand wil vervoeren moet je of vaker rijden (duurt langer), of de hardware (auto) aanpassen door een aanhanger achter de auto te hangen, of ander hardware (vrachtwagen) nemen.

[SinergyX]

Maar wat was nu het 'nut' om dit te kraken? Of is het nieuwswaardig hoe snel dit gedaan is? Het is bijna een standaard script wat je moet draaien op zo'n groot mogelijk serverpark mogelijk, de rest is pompen maar. Maar MD5 is onveilig.. ja wisten we al heel wat jaren. Maar MD5+salt is simpel te kraken, ja.. wederom niets nieuws.

Ok, dan een 'wachtwoord analyse', welke totaal geen zicht heeft op creatie, ouderdom, doel of gebruik, zeker niet op een site waar je bij voorbaat al geen enkel link wil hebben aan enig ander account/mail/ding. Ik heb 12 spam adressen waarbij ik de meest simpelste wachtwoorden gebruik op die flutsites (reclame, inschrijving, winnen etc), maar ze ook werkelijk niets meer verder mee kunnen doen.

Het was een stuk interessanter geweest als ze meer inzicht gaven op hoe zij die salt hebben kunnen vinden, dat is nog steeds de uitdaging (en pure rekenkracht), dat daar uiteindelijk X-resultaat uit komt is gewoon een complex rekensommetje.

Enige overige nuttige data is natuurlijk de hele link naar overheid en kantoren, kijken welk story/prive/AD nu als eerste zulk nieuws neerzet.

[CAPSLOCK2000]

Maar wat was nu het 'nut' om dit te kraken? Of is het nieuwswaardig hoe snel dit gedaan is? Het is bijna een standaard script wat je moet draaien op zo'n groot mogelijk serverpark mogelijk, de rest is pompen maar. Maar MD5 is onveilig.. ja wisten we al heel wat jaren. Maar MD5+salt is simpel te kraken, ja.. wederom niets nieuws.

Ik vind het interessant omdat het een heel tastbaar voorbeeld is. Meestal zijn beveiligingsproblemen nogal abstract en voor de meeste mensen een ver-van-mijn-bed show want ze hebben toch "niks te verbergen".

Nu zullen de meeste mensen niet op dit forum zitten, maar ik denk dat iedereen zich kan voorstellen dat bezoekers dat liever geheim houden en dat een aantal van hen best wel eens in de problemen zou kunnen komen als het bekend wordt.

Daarnaast is het een mooi praktijk voorbeeld van hoe oude techniek nog lang kan doordraaien en hoe moeilijk het is om het goed te doen. vBulletin is volgens mij marktleider op dat gebied en dat er al sinds 2012 bcrypt gebruikt wordt is een goed teken. Daarbij draaide deze site de nieuwste versie van die software, met uitzondering van patches die slechts een paar dagen oud waren. Toch was dat niet voldoende.
Op grond van mijn eigen ervaring denk ik dat 90% van de websites in Nederland het minder goed voor elkaar heeft.

[0xtw3]

De salt stond gewoon in dezelfde database

Overigens beweren die beheerders op dat forum dat er alleen emailadressen waren gelekt, ze hebben de gebruikers niet ingelicht dat er ook usernames, ip adressen, en wachtwoorden(!) waren gelekt. Ze denken blijkbaar dat een md5 gehashed wachtwoord geen wachtwoord is.

[GekkePrutser]

Dat is overigens normaal bij een salt. Die is alleen bedoeld om rainbow tables onmogelijk te maken, maar het is normaal dat hij naast het versleutelde paswoord wordt opgeslagen.

[DonLexos]

Had niet zo heel veel uitgemaakt. Stel de salt staat ergens in een PHP bestand in vBulletin, dat is dan bekend (waar), en met het gat dat in vBulletin zat had de hacker deze mogelijk ook gewoon uitgelezen.

[RobIII]

Dat zou een "globale" salt betekenen (doorgaans "pepper" genoemd) en dat zou nog véél erger zijn dan een salt per account.

[Anoniem: 167912]

waarom "nog veel erger", er is niets mis met het gebruik van een salt, wel integendeel, geen salt is een probleem

[RobIII]

Een globale salt (ook wel pepper) is (veel) erger dan een salt per account. Lees mijn reactie (en waar ik op reageer) nog eens

[Anoniem: 167912]

maar je zegt dat een salt altijd erg is ("want een globale is nog erger"), dat klopt gewoon niet.
Een salt per account is helemaal niet erg, geen salt per account is pas erg.

[RobIII]

Je leest het verkeerd. Een globale salt i.c.m. MD5 zou nog veel erger zijn dan een salt per account i.c.m. MD5. Het erge is MD5, een globale salt zou 't erger maken. Het erge is de MD5, het nog ergere is globaal i.p.v. per account. Het begon hier en daar ging 't over MD5

[Reactie gewijzigd door RobIII op 25 juli 2024 02:57]

[Niemand_Anders]

Hash + salt worden door heel erg veel systemen in dezelfde database weggeschreven. Je kunt de salt wel wegschrijven naar een andere database, maar als via een bug in de software tabel 1 kan worden uitgelezen, dan men ook wel tabel 2 uitlezen.

Het idee van een unieke salt per user, is dat dat de moeilijkheid omhoog gaat omdat je geen rainbow tabel kunt aanleggen. Een global salt heeft een minimale impact ten opzichte van geen salt gebruiken. Daarnaast wordt in veel systemen de global salt voor- of na het wachtwoord geplakt..

Een md5 hash is technisch gezien geen wachtwoord. Even simpel gesteld dat mijn wachtwoord hash is samengesteld door 3 + 9 bij elkaar op te tellen. Vervolgens wordt '12' als hash weggeschreven. Wat een hacker doet is proberen om opnieuw een output van '12' te krijgen. Dat kan dus ook 5 + 7 zijn. Zodra twee verschillende wachtwoorden dezelfde hash opleveren noemen we dat een collission..

Overigens was al direct bekend gemaakt dat er meer was buit gemaakt dan alleen emailadressen:
bron: NOS - https://nos.nl/artikel/23...n-te-koop-aangeboden.html

Naast e-mailadressen gaat het onder meer om gebruikersnamen, ip-adressen en wachtwoorden. De wachtwoorden zijn beveiligd, en kunnen niet zomaar worden gekraakt, maar de e-mailadressen van gebruikers zijn wel leesbaar.

[Anoniem: 718943]

De kennis van een salt maakt niets uit. Het nut van een salt is om rainbow tables onbruikbaar te maken voor collisions.
Het feit dat je de salt weet, geeft je nog steeds geen beschikking over een database aan rainbowtables met hashes voor die salt.

[Anoniem: 84766]

Interessanter is om te weten hoeveel iteraties er werden gebruikt voor de bcrypt hash. Bcrypt is goed, maar je moet wel mee gaan met de tijd. Zelfde geldt voor PBKDF2.

[banaj]

In artikel staat: workfactor 10, dus 2 ^ 10 = 1024 iteraties.

[Anoniem: 84766]

Dank. Beetje magertjes, maar ook niet heel dramatisch. Lengte van het wachtwoord is dan toch belangrijk. Onduidelijk in het artikel is tot welke lengte van wachtwoorden ze zijn gekomen in drie dagen. Ze hebben het even over 6 karakters en dat dat 27 jaar zou duren met 1 Nvidia.

[SpiceWorm]

De salt hoef je niet te zoeken, die staat gewoon in clear text in de db.

[Anoniem: 58485]

Het komt voor dat men 1 en hetzelfde wachtwoord voor alles gebruikt. Dus ja ook een database zoals die van hookers is zeer interessant.

[kristofv]

Allemaal niet eens nodig, een Tesla instantie op cloud platform x kraakt een gemiddelde Active Directory md5 hash in 8 minuten. Heb het eens in de praktijk getest voor de lol.

[banaj]

Active Directory is niet MD5 maar NTLM. NTLM is gebaseerd op MD4, niet gesalt en gebruikt geen iteraties. Appels en peren dus.

Ook een Tesla kraakt bcrypt traag. Ook een Tesla heeft tijd nodig voor hashes met salt.

[kristofv]

True was al aan het twijfelen toen ik het schreef maar had toch moeten checken

[Jorgen]

Niet alleen het nut van het onderzoek, maar ik heb ook mijn vraagtekens bij de ethiek van het onderzoek. Waarom zou je alle wachtwoorden proberen te kraken, of na willen gaan wat de emailadressen zijn? Ik vind dat een grove schending van de privacy. Nu kicken mensen op ministerie + prostitutie = RTL Boulevard. Hadden we dat ook OK gevonden als het wachtwoorden waren bij het UWV of een portaal voor GGZ-hulp? Puur onderzoektechnisch had dit ook met een veel kleinere, random, privacywaarborgende steekproef gekund.

[AW_Bos]

Ik snap niet dat onveilige hashes bewaard blijven, als je in je database een mengeling van md5(), sha1(), bcrypt() en weet ik veel wat hebt. Die mieter je die onveilige toch weg, waarna je gebruikers bij het inloggen dwingt om een nieuw wachtwoord aan te vragen via een mailverificatie?

Dat je niet een zomaar een onveilige hash kan omtoveren in een veilige hash, dat snap ik wel. Maar ergens lijken er geen goede procedures te zijn in vBulletin, heb ik het idee?

[Reactie gewijzigd door AW_Bos op 25 juli 2024 02:57]

[Niosus]

Wat vaak gebeurt is dat de eerste keer dat gebruikers inloggen je eerst checkt of het ingegeven wachtwoord correct is via de oude hash, en dan terwijl je het plaintext wachtwoord nog hebt, de nieuwe hash berekent en opslaat. 100% transparant voor gebruikers en je hebt in no time alle actieve gebruikers omgezet naar het nieuwe algoritme.

Je kan dit een grace period geven van bijvoorbeeld een jaar. Nadien verwijder je gewoon alle oude hashes en forceer je gebruikers om via hun email adres hun wachtwoord te resetten. Zo zijn volledig inactieve gebruikers beschermd. Voor die paar mensen die minder dan 1 keer op een jaar inloggen, moeten ze gewoon even via hun mailbox gaan. No biggie normaal, en aangezien ze toch de account niet vaak gebruiken is het waarschijnlijk ook geen ramp als ze niet meer aan die mailbox kunnen en een nieuwe account moeten aanmaken.

Als ik het goed heb is dit hoe Wordpress de zaken heeft aangepakt (zonder de grace period). Ik snap niet waarom vBulletin niet hetzelfde heeft gedaan. Het is triviaal om te programmeren en verhoogt de veiligheid enorm.

[Blokker_1999]

Dit komt doordat men gebruikers vaak een goede ervaring wil bieden bij de omzetting. Je doet een upgrade van je software waarbij de volgende login je oude hash controlerrt en ook de nieuwe aanmaakt waarna de oude verwijderd wordt. Beheerders vergeten evenwel na enkele weken alsnog alle oude hashes die overblijven weg te gooien.

[svane]

Je kan ook de oude (md5) hash nog een keer hashen met bcrypt. Zodra iemand inlogt kan je 'm meteen opnieuw opslaan met enkel de goede hash-methode.

Op die manier heb je én veilige hashes, én merken de gebruikers er niks van. Geen idee hoe makkelijk dit met vBulletin te doen is, maar dat zou geen excuus mogen zijn.

[CMG]

Precies; ik heb zelf ook zo'n systeem gemaakt toen ik vond dat een stuk software dat ik moest onderhouden MD5 hashes gebruikte. Zelf gebruik ik altijd PBKDF2; maar ik heb de tabel uitgebreid met een 'password type', zo had je een type voor md5, pbkdf2 en pbkdf2 van de md5. Zo kun je gefaseerd over. Kun je een deel van de compute gebruiken om hashes te 'upgraden' en bij het inloggen kun je detecteren hoe je moet decrypten; als het target != gewenste type is, daarna opslaan in gewenste type.

[Xerxes249]

wat is dan de sleutel van deze bcrypt hash?

[netfast]

De md5 hash van het originele password

Dus in de database heb je dan:
Bcrypt(md5('mijnwachtwoord'));
ipv
md5('mijnwachtwoord');

Als iemand inlogt kijk je eerst of je de bcrypt hash matched met het wachtwoord.
Als dat niet is, probeer je het nogmaals maar dan match je de bcrypt hash met de md5 hash van het wachtwoord. Die zal dan wel matchen.
Daarna vervang je de bcrypt hash met alleen bcrypt('mijnwachtwoord');

gebruiker voelt geen centje pijn, en alles is veiliger!

Zeer elegante oplossing moet ik zeggen!

[Anoniem: 167912]

Ik verbaas me erover dat bcrypt blijkbaar ook al relatief eenvoudig kan gekraakt worden. Wat moet er dan wel nog gebruikt worden?

[Niosus]

Nee, in principe is bcrypt nog altijd veilig. Kans is groot dat die 10% dat ze gekraakt kregen ofwel heel korte wachtwoorden waren, ofwel "bekende" woorden waren, of triviale combinaties met getallen zoals "voetbal123".

Volledig brute forcen is nog niet praktisch, maar als je wachtwoord gewoon een eenvoudig patroon volgt kunnen ze natuurlijk wel een hoop verschillende patronen proberen.

Wachtwoord manager + random wachtwoorden gebruiken dus!

[kr4t0s]

Als je de hashes offline weet je krijgen zoals in dit geval kun je miljoenen pogingen per minuut doen. Heb het zelf ook een keer getest met hashes van Linkdin lek. Kon ook 67% achterhalen in een dag. Er is bijna niks tegen bestand er zijn gigantische rainbow tabels van tientallen gb's die je kunt gebruiken. Had het wel geanonimiseerd door alleen de hashes te nemen.

Multifactor authenticatie is stuk veiliger inderdaad met password manager en random wachtwoorden.

[EraYaN]

Die rainbow tables doen dan wel weer vrij weinig als er salts gebruikt worden. En dat is dan ook net het punt. En het verschil met een "simpele" hash als MD5 en bcrypt met een workfactor van 10 is echt een tiental orde groottes.

[svane]

Met bcrypt gaat dat gelukkig een stuk moeilijker, ook offline. Rainbowtables zijn niet bruikbaar vanwege de salt die gebruikt wordt.
Ook moet je een heel flink systeem hebben om miljoenen pogingen per minuut te doen

750 tries per second on an Nvida RTX 2080 Ti

https://medium.com/@Scatt...n-three-days-da613bbac32b

Multifactor authenticatie is stuk veiliger inderdaad met password manager en random wachtwoorden.

Helmaal mee eens

[Reactie gewijzigd door svane op 25 juli 2024 02:57]

[Niosus]

Op bcrypt zie ik je echt geen miljoenen hashes per minuut nemen. Verder zijn rainbow tables vrij nutteloos als de hashes met een "salt" gemaakt zijn. Je hebt natuurlijk wel grote lijsten van wachtwoorden waarmee je kan proberen, maar als je wachtwoord daar op staat is het natuurlijk inherent niet meer veilig, ongeacht het hash algoritme.

Maar dan nog. Stel dat je een random wachtwoord hebt van 9 tekens (met pak 100 opties per teken, dat is ongeveer wat je hebt met ASCII). Dan heb je 100⁹ mogelijke wachtwoorden. Zelfs al geef ik je 100 miljoen hashes per minuut (equivalent van meer dan 2000 2080Ti's volgens de bron van dit artikel voor bcrypt), dan heb je nog meer dan 19000 jaar nodig om die hash te brute forcen. Oke, goed, gemiddeld gezien is het maar 9500 jaar. Voor enkel die ene hash. Dat gaat dus niemand doen tenzij dat het echt over staatsgeheimen gaat.

Een goed hashing algoritme is dus juist cruciaal om de impact van dit soort hacks te verminderen. Multifactor authenticatie geeft in dit geval maar beperkte veiligheid. Ja, je verliest dan niet zomaar toegang tot je andere accounts, maar de hackers kunnen nog altijd je email adres aan je wachtwoord koppelen en dat door verkopen! Beter dan worst-case, ja. Maar zeker niet "een stuk veiliger". Als je een random wachtwoord in je password manager hebt steken kunnen de hackers je email adres enkel koppelen aan een random string die enkel van belang is op de website die ze net gehackt hebben. Met een random wachtwoord komen je andere accounts nooit in gevaar. Multi-factor authenticatie heeft nog altijd nut, maar de allerbelangrijkste basis blijft een sterk wachtwoord. Als hackers tot het punt geraken dat multi-factor authenticatie een verschil maakt, heb je ergens al een gigantische flater begaan.

[Wobblier]

Correct! Daar komt bij dat het artikel ook niet zegt dat bcrypt is gekraakt. Dat is dus niet gebeurd. Bij het kraken van van een hash zoek je naar collisions, nooit naar het originele wachtwoord. (wat ook niet mogelijk is)

De groep presenteert een top35 aan wachtwoorden. Dus de groep heeft een (password) dictionary attack gedaan.

[cricque]

Als de "attacker" gewoon een brute force doet op basis van een lijst met woorden. Dus een grote veel voorkomende wachtwoord lijst, kan hij zo ettelijke combinaties op een relatief "snelle" manier gewoon forceren om te kijken, klopt dit of klopt dit niet.
De wachtwoorden die niet in zo een "dictionary" staan, die zijn een pak moeilijker

[Jace / TBL]

bcrypt is prima, ik durf te wedden dat de 'gekraakte' bcrypt passwords allemaal gevallen waren van gewoon slechte passwords.

Als je 'admin' of 'abc123' als password gebruikt maakt het sowieso niet uit hoe sterk je hash of KDF functie is. Ze proberen sowieso de honderdduizend meest voorkomende passwords en dan zitten er altijd al een hoop hits tussen.

[Anoniem: 1076733]

Alles kan gekraakt worden. Alles.

[BushWhacker]

Ongelooflijk dat er tegenwoordig nog zo slecht gehashed wordt.
Dit moet toch minimaal met sha256+salt gebeuren om veilig te zijn.
En de salt moet per userid anders zijn.

Dus iets van: sha256, salt==blahblah+userid+otherblah

En in 2012 bij de update hadden eigenlijk alle accounts geblokkeerd moeten worden totdat het ww werd aangepast met de nieuwe (helaas was bcrypt ook geen veilige keuze, maar wel minder erg dan md5)

Edit: Helaas verkeerd gelezen.... bcrypt met salt is veiliger dan sha256....

[Reactie gewijzigd door BushWhacker op 25 juli 2024 02:57]

[deadinspace]

Ongelooflijk dat er tegenwoordig nog zo slecht gehashed wordt.
Dit moet toch minimaal met sha256+salt gebeuren om veilig te zijn.

Salted SHA256 is praktisch gezien niet beter dan salted MD5.

Hoewel MD5 lek is, heeft dit geen impact op het gebruik voor wachtwoord-hashing; gegeven md5(X) is er nog steeds geen manier bekend om X te berekenen. De enige manier daarvoor is nog steeds brute force, net als bij SHA256.

Het probleem met zowel MD5 als SHA256 voor password hashing is dat ze veel te snel zijn, waardoor brute force een haalbare aanpak is. Daarom moet je voor wachtwoorden een trage hash-functie met een instelbare work factor gebruiken, zodat de hash-functie snel genoeg is voor authenticatie, maar te traag om effectief te brute forcen. Goede voorbeelden zijn PBKDF2, bcrypt, en scrypt.

(overigens zou ik het gebruik van MD5 wel altijd afraden; het feit dat er significante zwakheden in zijn gevonden is reden genoeg om het nergens meer voor te gebruiken)

Dus iets van: sha256, salt==blahblah+userid+otherblah

Voorspelbare salts zijn ook geen al te goed idee. Best practice is al tientallen jaren om een random salt te gebruiken.

(helaas was bcrypt ook geen veilige keuze, maar wel minder erg dan md5)

Bcrypt is wel degelijk een veilige keuze. Een zwak wachtwoord als Welkom123 is altijd te brute forcen, ongeacht de gebruikte hash-functie.

Stel, je stelt je hash-functie zo in dat het 0.1 seconde duurt om een wachtwoord te verifiëren. Dan kan een aanvaller die de hash heeft met dezelfde hardware óók elke 0.1 seconde een wachtwoord proberen. Dat geeft ongeveer een miljoen pogingen per dag. Een aanvaller met standaard hardware kan dus simpelweg en lijst van de miljoen meest gebruikte wachtwoorden gebruiken en daarmee de nodige accounts kraken, zelfs als een fatsoenlijke hash-functie is gebruikt. Met betere hardware en meer tijd kunnen meer accounts gekraakt worden.

De enige bescherming daartegen is een fatsoenlijke hash-functie EN een fatsoenlijk wachtwoord.

[Jace / TBL]

Geheel mee eens, doch is het wel zo dat als je echt een fatsoenlijk password hebt, ook een zwakke (snelle) hash functie niet uitmaakt.

Ook snelle hashes zoals md5 of sha256 zijn verreweg niet te brute forcen. Alleen voor relatief korte inputs (en voor md5 zijn er nog wat bijkomstige zwaktes maar die werken vooral de andere kant op). Weliswaar voor langere inputs dan wat met PBKDF2 of bcrypt haalbaar is natuurlijk, maar nog steeds relatief kort.

Als je wachtwoord zoiets als f7Tm3MRcpFZaPbGH42nm2vkLcNkSa6Q is en iemand heeft daar de md5 of sha256 hash van, zelfs zonder salt, gaat hij dat nooit brute forcen.

Maar evengoed is er natuurlijk geen enkele reden om een snelle hash te gebruiken in plaats van een zware KDF.

[Byron010]

IMO is er tegenwoordig totaal geen reden om iets anders dan een PBKDF variant of sterke AES (beiden met salt en een hoge iteration count indien mogelijk) te gebruiken. (PBKDF2, bcrypt, scrypt, argon2(id) als voorbeelden)

NIST raadt PBKDF2 aan.

[Jace / TBL]

Wat is er niet veilig aan bcrypt2?

[EraYaN]

bcrypt is toch echt een betere keuze dan SHA256, daarom zijn de meeste standaard implementaties of bcrypt of PBKDF2 bijvoorbeeld en geen SHA256.

[satoer]

Waarom doet de Nederlandse dienst dat dan? De site was toch niet illegaal ofzo? En dit dan te gaan vergelijken met ministeries gaat ook een beetje ver qua privacy niet?

[cyclone]

Ik gis even maar grootste beweegredenen is bewustwording lijkt me.

Moet zeggen dat ondanks werkzaam in de IT ik ook laconiek bleef en vaak dezelfde wachtwoorden gebruikte tot op enkele jaren geleden toen ik puur uit interesse in aanraking kwam met hackthebox.eu.

Sindsdien zijn mijn ogen geopend, en gebruik ik voor elk account een complex wachtwoord ism een password manager.

Het “hacken” van veel (heel veel) systemen ivm fouten / niet up to date zijn is soms kinderlijk eenvoudig als je kan lezen en de juiste tools gebruikt. En daar valt geld mee te maken dus trekt het verkeerd volk aan die dit ook kunnen.

Maar hoewel heel vaak gewaarschuwd leek het mij ook allemaal “onwaarschijnlijk” totdat ik zelf aan de lijve ondervond hoe eenvoudig het was en ik zelf in no time het ook kon (let wel in de hackthebox omgeving waar het dus volledig legaal is maar wel real life scenario’s worden gebruikt)

Kortom dit “even” doen maakt dat mensen u en ik zich er bewust van raken dat als je eenmaal een password file hebt het gewoon mogelijk is om ze te cracken zonder hele grote investeringen.

En zolang er geen mensen bij naam genoemd of de resultaten gepubliceerd worden wordt niemands privacy geschonden en kan dit prima.

[Reactie gewijzigd door cyclone op 25 juli 2024 02:57]

[blinchik]

Mijn paswoorden zijn vaak niet "zo" enorm moeilijk, maar ik gebruik wel 2FA.

[cyclone]

two factor authenticatie is natuurlijk TOP, echter is de gebruiker niet degene die bepaald of dit überhaupt gebruikt wordt en ben je dus overgeleverd tot vaak de basic username password authenicatie bij de meeste systemen die ik ken.

Antwoord daarop is dan weer toch een password manager (die dan weer wel ontsloten is met een 2FA)

[Anoniem: 1076733]

Ik gebruik 2FA plus sms!

[Poulske]

Off-topic, maar ik ga me eens verdiepen in hackthebox, ziet er interessant uit.

[cyclone]

Kan het je van harte aanbevelen ik kan me er zeer mee vermaken, let wel op vrij verslavend

[Kiswum]

Waarom ze dit doen? Dit onderdeel van deze Nederlandse dienst, doet dit als core-business:

What is Scattered Secrets?
Scattered Secrets is a password breach notification and prevention service. By using Scattered Secrets, you can drastically reduce the risk that hackers will be able to hijack or takeover your accounts.

Via Google in 2 tellen gevonden

Bedankt @MaxKorlaar, ik heb het aangepast!

[Reactie gewijzigd door Kiswum op 25 juli 2024 02:57]

[MaxKorlaar]

Ik betwijfel sterk dat ze onderdeel van het Rijk zijn 😛

[BAJansen]

De dump met gehashte wachtwoorden kan op dit moment bij iedereen liggen, dus het is wel handig om te weten hoe makkelijk de wachtwoorden zelf hieruit zijn af te leiden.

[steareth]

om te kijken hoe goed de encryptie is van een gelekte database.

"De database van de site kwam half oktober op straat te liggen via een kwetsbaarheid in vBulletin"

[P_Tingen]

Opvallend was dat 'vRbGQnS997' in totaal 1320 keer en daarmee het meest gebruikt was. Een verklaring is dat dit geautomatiseerd werd aangemaakt voor spamactiviteiten

Betekent dit dan dat die 1320 accounts uiteindelijk door één en dezelfde partij zijn gemaakt?

[Zoidberg_AvG]

Of dat 1320 mensen toevallig allemaal het wachtwoord vRbGQnS997 hebben gekozen

maar dat lijkt me niet heel waarschijnlijk....

[Byron010]

Die conclusie kan je hier niet uit trekken maar maakt het inderdaad wel erg aannemelijk.

[veltnet]

Als ik google op dat wachtwoord dan krijg ik de volgende info:
184.154.77.228//Autoblacklisted with registration signature: U=Proorofloom;P=vRbGQnS997;E=[e-mail] [PS07]/20111101

[Kareemthereem]

Waarschijnlijk voor/door spam accounts

[Stealthy]

fake accounts a la datingsites of een standaard wachtwoord wat ze mensen geven als men hun wachtwoord reset lol
kan allemaal tegenwoordig

[Reactie gewijzigd door Stealthy op 25 juli 2024 02:57]

[Anoniem: 428562]

Ken de achtergrond van hoe en waarom niet maar 'vRbGQnS997' staat in diverse password lijsten.

In een lijst met veel gebruikte franse passwords staat het in de top 400

https://github.com/tarras...ch_passwords_top20000.txt

[Anoniem: 58485]

Er kan een geautomatiseerd script in omloop zijn dat zich bezighoudt met registraties. Niemand gaat kijken naar het registratiewachtwoord. Het gaat erom een bot op een forum te krijgen die gebruikers kan spammen of spam posts kan maken (wat hier op Tweakers.net ook soms gebeurd).

Ik zie het ook op wordpress sites overigens. Standaard contact form 7 formulieren, worden kapot gespammed door ja ook nederlandse bedrijven met oplossingen tot het probleem. Zet er een honeypot in en het hele spammen houdt op.

[Anoniem: 718943]

Dit kan ook een collision zijn met bijv. 'welkom'.

[MarvinJames]

Was er een reden om specifiek deze website te kiezen?

[Kiswum]

Het is waarschijnlijk een van de meest interessante kandidaten?

Hieronder de reden waarom men de accounts controleerden:

De database van de site kwam half oktober op straat te liggen via een kwetsbaarheid in vBulletin, het platform achter het forum.

[MarvinJames]

Ah op die manier. Ik dacht dat Scattered Secretse zelf aan het hacken was geslagen. Maar ze hebben die database dus weten te bemachtigen en die vervolgens gekraakt.

Check. Ik snap 'm.

[Schway]

afpersing.
1. Zoek de adressen van bedrijven en overheid er uit.
2. Stuur ze bericht:
Hoi A. Noniem.
Jij werkt bij @werkgever.nl
Jij bezoekt hookers.nl
graag x btc overmaken.
Groetjes,
3. Profit.

[targaryanwolf]

En dan nog, ik geloof dat iedereen ook wel eens porno op internet kijkt...
Denk dat de "gedupeerde" niks te vrezen hebben, tenzij er echt hard bewijs is zoals foto's ofzo.

[Xirt]

Sterker nog: iedereen kan een account aanmaken met het e-mailadres van iemand anders. De vraag is of het account geactiveerd / gebruikt wordt na aanmaak (want daarvoor moet je waarschijnlijk bij je mail kunnen) en het is niet direct duidelijk of dit ook het geval is voor de genoemde accounts (waarschijnlijk wel te achterhalen door de gebruikersnamen te linken aan forumposts).

Ik kan mij overigens voorstellen dat ook vanuit de overheid de community actief in de gaten wordt gehouden dus dat er wel een paar "zakelijk legitieme" accounts aanwezig zijn in de database.

[kritischelezer]

De zakelijke controle zal niet gedaan worden met een zakelijk account van een overheid

Inderdaad kun je je registreren met elk email. Als de database gepubliceerd is met alleen gebruikersnamen, wachtwoorden en emails, dan is er geen verschil tussen een geactiveerd of alleen geregistreerd account.

[caipirinha]

Ik weet dat dat in mijn vakgebied in het verleden (20 jaar geleden) wel gebeurde.
Tegenwoordig alleen via VPN en niet herleidbare email adressen.
Je weet niet hoe oud deze accounts zijn.

[kritischelezer]

Men gebruikt ook een specifiek vpn netwerk voor controles.

[Jerie]

Je kunt hier een account hebben zonder dat je actief participeerde. Volgens mij had ik hier ook nog een account (op een of ander vaag e-mail adres) omdat ik iets wilde lezen (zonder verder die informatie voor eigen consumptie te gebruiken) waar ik voor in moest loggen.

Het verbaasd me trouwens dat dit forum nog bestaat. Is deze informatie wel AVG-proof?

[Jace / TBL]

Beste O. Plichter, nee hoor dat is niet zo, ik heb geen account daar.

[icecreamfarmer]

Opvallend is dat veel registraties ook via werk email liepen.
Dat je op zo'n forum zit is iedereen zijn ding maar om nu je overheids of zakelijk mail adres te gaan gebruiken.

[Anoniem: 677216]

Kleinere kans dat je partner er achter komt op die manier

[Anoniem: 420148]

Kleiner dan een throwaway gmail/protonmail?

[Anoniem: 677216]

Uiteraard is dat een 'betere' optie, maar er zijn genoeg mensen die echt niet weten hoe ze nieuwe mailadressen moeten aanmaken en/of ervoor zorgen dat daar geen inloggegevens of historie van bewaard blijven.

[Anoniem: 420148]

Ik zou eerder zeggen dat werk-mail gevaarlijker is. Je vrouw die erachter komt is 1 ding, je werkgever een heel ander probleem.

[djmexxc]

Dat is inderdaad echt onbegrijpelijk, kan ook zijn dat iemand een ander wilde vervelen en zijn werk mail heeft gebruikt.

[BramV]

Conclusie in Medium artikel is misschien wel het meest interessant:
To stay as safe as possible in the future: use long (≥12 positions) and unique passwords (completely unrelated) for all your accounts.

[osmosis]

Wat is hier aan interessant dan?
Toch vrij logisch basis begrip om niet altijd dezelfde wachtwoorden te gebruiken. Daarnaast zijn langere wachtwoorden natuurlijk beter. Liefst nog wat willekeurige tekens/hoofdletters/cijfers erdoor

[BramV]

Daarnaast zijn langere wachtwoorden natuurlijk beter.

Ik was benieuwd naar de lengte. Langere zegt mij namelijk niet zoveel. Scattered Secrets geeft dus aan minimaal 12. Persoonlijk gebruik ik nu 20 en zit ik, zolang het duurt, nog safe.

[Rho d Berth]

Verschillende wachtwoorden hebben ook een nadeel, namelijk dat je ze niet kunt onthouden.
Je kunt ook op heel veel onbelangrijke sites hetzelfde wachtwoord gebruiken, en deze site lijkt me een prima plek om een garbage-password te gebruiken. Want als je verder niks van je persoonsgegevens in je account zet is er niks aan de hand.

Verder is het beste password een zin, niet dat gedoe met gekke letters en tekens. Een lange zin die je makkelijk kunt onthouden. Voor dit forum kan je dan bijvoorbeeld: "Hier heb ik in 2014 mijn vrouw voor het eerst ontmoet"
Makkelijk te onthouden, vrijwel onmogelijk om te kraken.

[b12e]

het leuke is websites die belachelijke eisen stellen..

Zo ben ik al tegengekomen:

• "Je wachtwoord mag maximaal 12 tekens lang zijn en mag enkel kleine letters, hoofdletters en cijfers bevatten" (bank)
• "je wachtwoord mag geen speciale karakters bevatten en maximaal 8 tekens lang zijn" (telco)
• "je wachtwoord moet minimaal 16 tekens lang zijn en een combinatie van hoofdletters, kleine letters, cijfers en speciale tekens bevatten uit volgend lijstje (@#$%&ç{})" (forum over een populaire tv reeks)

Alles moet wel een beetje proportioneel blijven.

[TERW_DAN]

het leuke is websites die belachelijke eisen stellen..

Ja, verschrikkelijk is dat. Gelukkig kan m'n passwordmanager wel voor al die dingen een wachtwoord genereren op basis van de eisen die ik ingeef.

Maar dingen als max 8 karakters geven me vaak wel de kriebels.

[Free rider]

Inderdaad vreemde zaken, ICS (creditcards) liet geen underscores toe in wachtwoorden.

Ik denk dat zulke instellingen proberen te voorkomen dat je wachtwoorden kiest die je ook elders gebruikt - en dat op deze manier afdwingt. En dat klinkt dan weer logisch.

[Jace / TBL]

Klopt ja, echt ongelofelijk wat sommige websites voor belachelijke restricties verzinnen. Zeer storend, en dat soort bullshit komt bovendien de veiligheid heel erg NIET ten goede.

[Anoniem: 420148]

Je zou zelfs kunnen stellen dat het wachtwoord grotendeels irrelevant kan zijn, wanneer de dienst ook MFA heeft.

[Jace / TBL]

Toch vind ik die conclusie nog conservatief, ≥12 is niet echt lang. Waarom ≥12 en niet gewoon ≥30.

Het is heel simpel, passwords moet je NIET:
1. zelf verzinnen
2. zelf onthouden
3. hergebruiken voor verschillende accounts

Password managers dus.

Een password als T6eW4iMu0by2rMF84gcW59DvSced3Oj is hartstikke veilig, zelfs als ze zeer crappy hashing zoals md5 of sha1 zonder salt hebben gebruikt. En niet moeilijker of lastiger in gebruik dan een wachtwoord van 12 tekens, want copy/paste en nooit zelf onthouden.

[Cid Highwind]

Het grootste risico daarbij zie ik in het managen van de password manager. Immers wat gebeurt er zodra de password manager niet meer beschikbaar is? Eén Windows reset of harde schijf crash en alle wachtwoorden zijn weg.

Niet iedereen wil namelijk voor cloud of synchronisatie opties betalen, of maakt regelmatig een export naar een extern apparaat.

[Jace / TBL]

Een fatsoenlijke password manager synchroniseert het zelf, zonder extra kosten. En uiteraard encrypted, dus het maakt niet uit waar het staat (de cloud provider in kwestie kan het toch niet lezen).

Niet iedereen wil namelijk voor cloud of synchronisatie opties betalen, of maakt regelmatig een export naar een extern apparaat.

Ok, ja dat is dan sowieso wel vragen om problemen natuurlijk. Ook voor andere data dan je passwords. Er zijn intussen zo veel makkelijke prima backup oplossingen, ook gratis, dat mag eigenlijk geen excuus meer zijn.