Onderzoekers vinden bestand met 10 miljard unieke wachtwoorden

Onderzoekers hebben een bestand online gevonden waar bijna tien miljard unieke wachtwoorden in staan. Het gaat om een uitgebreide versie van het RockYou-bestand dat geen inloggegevens bevat, maar kan worden gebruikt voor bijvoorbeeld credentialstuffing- of bruteforceaanvallen.

Het bestand werd ontdekt door onderzoekers bij Cybernews en is te vinden op Breach Forums. De ontdekkers menen dat het het grootste publieke bestand met wachtwoorden is, al circuleren er veel meer dergelijke bestanden op internet en op darkwebforums.

Het bestand heet RockYou2024 en bevat 9.948.575.739 wachtwoorden. Die zijn geaggregeerd via honderden of zelfs duizenden andere bestanden die zijn gemaakt op basis van andere datalekken. RockYou2024 bevat dus ook geen credentials ofwel combinaties van gebruikersnamen en wachtwoorden, maar alleen een lijst van bestaande wachtwoorden die ooit bij online diensten zijn gebruikt.

Onderzoekers van Cybernews vonden in 2021 al een oudere versie van dat bestand, dat toen nog RockYou2021 heette. Toen bevatte dat nog 8,4 miljard wachtwoorden. De onderzoekers schatten dat er wachtwoorden van zo'n 4000 databases in de compilatie staan.

Dergelijke bestanden zijn op zichzelf niet gevaarlijk. Ze bevatten immers geen credentials. Toch zijn de bestanden nuttig voor criminelen. Die kunnen ze bijvoorbeeld gebruiken om geautomatiseerde aanvallen uit te voeren, zoals bruteforceaanvallen of credentialstuffingaanvallen. Het bestand is online gezet door een gebruiker die zichzelf ObamaCare noemt en in mei van dit jaar is geregistreerd op het forum. Het is onduidelijk of het om de persoon gaat die eerder al RockYou2021 in elkaar zette.

Reacties (114)

[JDx]

Dit klinkt een beetje als een boek met alle postcodes.

[jdh009]

Toch kan dit het brute forcen van accounts vele malen gemakkelijker maken. Gezien je nu een afgekaderde lijst hebt met 10 miljard wachtwoorden, is het alsof je een bos met mogelijke sleutels hebt in plaats van blind in het duister te tasten door zelfs sleutels te maken ( AAAA, AAAB ect) die bij wachtwoorden vaak tot tientallen tot soms 100+ tekens mogen bevatten.

Zonder een wachtwoordenlijst zou een crimineel dus elke mogelijke combinatie moeten proberen, wat extreem tijdrovend is. Met een lijst van 10 miljard wachtwoorden heb je een geconcentreerde bron van vaak gebruikte en kwetsbare wachtwoorden, waardoor het brute forcen van accounts veel sneller en efficiënter wordt mits deze een wachtwoord in de lijst heeft. Daarna kun je altijd nog over op een ander account of de normale manier van brute forcen mocht je je speciek richten op een account.

Als je 1000 pogingen per seconde kunt doen, zou het ongeveer 115 dagen duren om 10 miljard wachtwoorden te proberen op een account. Lokaal kun je dat vele malen sneller.

[Verwijderd]

daarom implementeerd men ook een rate limit van 5 foute wachtwoorden per 15 minuten, reken maar uit hoelang 10 miljard is...

[Horatius]

Alleen los je daarmee verre van het probleem op. Wachtwoord raden via mass logins kan nog steeds prima met een botnet maar dat is niet waar ik op doelde. Met jouw antwoord ga je ervanuit dat er altijd ratelimiting op kán zitten, probleem is alleen dat er al zat wachtwoorden zijn gejat. Velen daarvan zijn versleuteld.

Met dit woordenboek aan wachtwoorden kan je dus gerichter wachtwoorden gaan raden in databases welke al gejat waren. Dan koppel je informatie weer aan die wachtwoorden en mensen hergebruiken wachtwoorden nogal graag.

[Verwijderd]

Met de rate limiter per gebruikersnaam heb je geen probleem. Geen botnet die iets kan. Daarnaast heb je dan een user logger tabel waarin alle inlogpogingen staan vermeld. Indien nodig pas je dan een gebruikersnaam aan (1 die vaak onder vuur ligt)

Dus je kan 5x fout inloggen per gebruikersnaam anders 15 minuten wachten en weer 5 pogingen later

[cotix]

Dat soort ratelimiting had MSN bijv vroeger. Gevolg; scriptkiddies proberen 5x per kwartier in te loggen en je kan zelf niet meer inloggen.

[Rikkert86]

Denken dat je met een ratelimit veilig bent voor bruteforce is wel erg naief en simpel gedacht. Je kijkt nu naar 1 inlogmethode via bijv een login van een website. Maar er zijn legio andere situaties waarin bruteforce kan worden toegepast. Een website bruteforcen is wel echt iets van 20 jaar geleden en is totaal niet meer relevant. De routes die tegenwoordig worden gevolgt om binnen te komen en lateraal te bewegen zijn totaal anders, en daarbij is bruteforce nog steeds relevant om te gebruiken.

Daarnaast kunnen password lists als deze ook op andere manier worden gebruikt, om bijv te hashen tegen databases aan te houden en andersom te zoeken..

[Reactie gewijzigd door Rikkert86 op 22 juli 2024 13:25]

[Verwijderd]

Een hash gebruikt een random salt zodat je niet andersom gaat zoeken. Omdat je op de username limiteert in de backend en je maar 1 functie hebt om in te loggen, zul je dus creatief met een username moeten zijn. Bijvoorbeeld een 4, 5 cijferige code meenemen in de username. Hierdoor kan je indien een username pincode onder vuur ligt, de username een andere pincode automatiseren.

Ik heb dit vanwege iso27001 vroeger geïmplementeerd, niet met de cijfers, wel met de rate limit. Je krijgt ook inzichten in inlogpogingen en groei van het systeem. Dus 15 minuten geeft 20 inlogpogingen per uur, zit je boven een threshold bijvoorbeeld 100 foutieve inlogpogingen mailen naar support en username wijziging samen met klant uitvoeren.

[Rikkert86]

Je blijft denken rond de conventionele paden en wat inlogsystemen doen die in place zijn . Dit houdt de gemiddelde aanval misschien tegen, maar iemand die weet waar hij mee bezig is komt niet eens in de buurt van dit pad en deze systemen. Die doen vaak niet eens een inlogpoging, maar zoeken en matchen met hele andere methoden die helemaal niks van doen hebben met ratelimits etc.

Het veiligste blijft om meerstaps verificatie te hebben, met verschillende methoden gecombineerd. Niets is onmogelijk om te hacken, maar met mfa maak je het in ieder geval een heel stuk minder aantrekkelijk en straight forward daar ze meerdere stappen moeten laten aansluiten op elkaar.

[Reactie gewijzigd door Rikkert86 op 22 juli 2024 13:25]

[RobbyTown]

Of een telefoonboek met alleen nummers zonder naam.

[JDx]

Was toch een comedian die zei ik weet alle postcodes uit mijn hoofd ofzo?

Maar het zal wel sneller zijn dan echte brute force en bij 0000000000 beginnen tot aan ZZZZZZZZZ zeg maar. Je weet wat ik bedoel, echt elke mogelijke combinatie. Nu heb je een selectie.

[RobbyTown]

Inderdaad, zo had Simyo tijdje terug ook een klein 'lek'.

Als je op de bestelpagina een Simyo 06 invulde zag je precies wie wel en geen klant was van Simyo (10 euro Vriendendeal korting).
06 klant van Simyo was de output Gefeliciteerd, geen klant Helaas als output.
060000001 - 0699999999 laten draaien en je weet zo welk nummer of wel of geen Simyo klant is.

Hierdoor was een gerichte sms aanval op Simyo klanten en leek Simyo dus gehackt.

Dit is 'lek' is nu gedicht als je gewoon een 06 nummer invult krijg je nu ook korting (ook al staat het niet bij Simyo).

[Reactie gewijzigd door RobbyTown op 22 juli 2024 13:25]

[Finraziel]

Die informatie is ook gewoon te vinden op https://www.acm.nl/nl/telefoonnummers-zoeken
Alleen daar wordt het aantal zoekacties beperkt... Hoewel er ook een csv bestand staat wat je zo kan downloaden. Kan op mijn telefoon even niet kijken of daar dan ook alle reeksen en alle geporteerde nummers in staan.

Edit: mja ok verschil is natuurlijk wel dat je bij acm niet gelijk ziet of het een actief nummer is of niet, maar ik weet niet of dat zo'n beperking is voor een sms spammer.

edit2: Ok had mezelf nieuwsgierig gemaakt en toch even de PC aangeslingerd om te kijken... Het bestand bevat alleen nummerreeks informatie, of een nummer geporteerd is of niet kun je dus alleen op de website zelf checken waar je maar 10 requests per dag kunt doen (hoe goed die beveiliging is weet ik niet en ga het niet proberen). Ook staat Simyo er niet in, in ieder geval niet met die naam. Het is natuurlijk een submerk van KPN dus goed kans dat de registratie ook gewoon op KPN staat. Ik ken geen Simyo nummers dus kan helaas niet checken onder welke naam ze staan.

[Reactie gewijzigd door Finraziel op 22 juli 2024 13:25]

[LuCarD]

Getest met een Simyo nummer. Je krijgt KPN te zien

[Stoney3K]

Of een lijstje met kentekens van alle auto's in Nederland?

[Bergen]

Die is er al, kun je zo ophalen op de opendata website van de RDW. Alle auto's die in Nederland op kenteken staan, zonder naam- en adresgegevens natuurlijk.

[HenkEisDS]

Yup, 16,4 miljoen records die je gewoon kunt downloaden. Is een paar gigabyte aan data zo uit mijn hoofd.
https://opendata.rdw.nl/V...igen/m9d7-ebf2/about_data

Best leuk om mee te spelen.

[Maestro.mosjuh]

Nog erger - ik kwam laatst een website tegen waar alle BSN's van alle Nederlanders te vinden waren 🙈

[Skidze]

Ja en alle verjaardagen lagen ook op straat

[RiGhTeOuS]

Zou mooi zijn als bijv HaveIBeenPwned deze lijst toevoegt aan hun site. Kan je meteen checken of je wachtwoord erin staat.

[Sissors]

Lijkt mij geen goed idee, dan moet je je wachtwoord naar hun toe sturen, zodat ze het kunnen controleren. Het zijn er veel te veel om lokaal via een website te controleren (als in, dat de hele lijst altijd gedownload wordt als je de website opent, en dat er lokaal een scriptje checkt of jouwe erin staat).

@Luuk1983 ah ja, dat is beetje dom van mij, dat kan inderdaad. Al blijf ik er wel een beetje bij dat je wachtwoord op een andere website dan waar je hem gebruikt invullen een slecht idee is, ook al is het in dit geval een betrouwbare.

Edit2: En zoals @MMaster23 schrijft lost dat niet het probleem echt op .

[Reactie gewijzigd door Sissors op 22 juli 2024 13:25]

[D_el_p]

Als ik mij niet vergis werkt de huidige API van HaveIBeenPwned ook door client-side het wachtwoord te hashen en hier enkel de eerste 5 characters van op te sturen. Door een slimme manier van hashen is dat al genoeg om te kijken of je wachtwoord in de HIBP database voorkomt. Ik verwacht dat deze lijst ook gewoon toegevoegd gaat worden.

[Sissors]

Ah ik wist niet dat ze zoiets al aanboden. Ik ken het van dat ze alleen je e-mail nodig hebben om te kijken of die voorkomt in breaches.

[D_el_p]

Ik denk dat de website ook wel de meest toegankelijke manier is. De API wordt bijvoorbeeld gebruikt door password managers om automatisch een berichtje te genereren als er een wachtwoord voorbij komt in een breach.

[PdeBie]

Telefoonnummer kan je tegenwoordig ook controleren bij HIBP.

[banaj]

Ook niet een goed idee:

Pwned Passwords is an interesting example of the dangers of designing a cryptographic protocol with a deemed acceptable risk, being used in an unforeseen way such that the risk becomes suddenly unacceptable.

[1superheld]

Mits goed geïmplementeerd is dit geen risk.

After the initial publication of this blog post on April 17, 2024, we notified Troy Hunt, and as result, the Pwned Passwords APlv3 documentation has been updated to include warning about the risks of incremental searches.

[Luuk1983]

Je kan server side een hash maken van alle wachtwoorden en client-side op de website de hash genereren van het ingevulde wachtwoord. Je hoeft dan alleen de hash over het internet naar de server te sturen en te vergelijken met de hashes op de server.

[MMaster23]

Ja dat werkt natuurlijk niet. Want als jij eerst een hash gaat maken van ieder wachtwoord, heb jij in theorie ook een 1:1 mapping tussen de hash en het wachtwoord. Wanneer men dan een hash naar jou sturen met de gedachte dat je dat niet hun wachtwoord weet, heb jij wel degelijk inzicht in het wachtwoord wat gecontroleerd gaat worden.

[Luuk1983]

Ja ok, ik ben iets te kort door de bocht, je wil het allemaal veel beter beveiligen natuurlijk. Maar het ging erom dat je geen lijsten heen en weer hoeft te slepen. Overigens ben ik altijd een beetje bang voor sites die databases hebben om te kijken of je op een bepaalde lijst staat, want dat zijn op zichzelf natuurlijk alweer geweldige doelwitten

[1superheld]

Haveibeenpwnd is een verzameling lijsten, al deze wachtwoorden zijn al gelekt (en dus niet veilig).
Dus niet perse een groot doelwit

[dasiro]

ze hebben de credentials al vanuit gelekte databreaches in het verleden. Je moet bij hen geen username/paswoord combinatie ingeven, maar altijd slechts een van beide: username of paswoord
Als je [e-mail] met pwd Lekker123 hebt gebruikt om bij www.kweekprogramma2021.gov in te loggen en ze weten dat in 2023 IvoryHunter die site gebreached heeft, omdat die een dump gepubliceerd heeft, dan kunnen ze je verwittigen. Ben je ondertussen een flinke stier geweest en dat paswoord nergens anders gebruikt hebt en/of een melding hebt gekregen van kweekprogramma2021.gov waarna je het hebt aangepast naar LekkerNootje123 dan zal je nog wel een waarschuwing krijgen op je username, maar niet op je huidige paswoord.
Als je dus een nieuw paswoord moet kiezen, dan kan je het eerst eens testen om te zien of het niet al in een oude breach bestaat, want het is niet omdat jij het nog niet gebruikt hebt in combinatie met jouw mailadres, dat een hacker het niet kan proberen.

[1superheld]

Maar als het een one-way hash is kan je deze altijd brute forcen,

HIBP doet dit op slimmere manier, door client side te hashen en dan aan de server te vragen "geeft mij alle hashes die beginnen met deze 5 characters) kan de client zelf controleren of het in dit lijstje staat.

Deze lijstjes zijn daarnaast veel beter te cachen en hebben 10tallen wachtwoorden waardoor het een stuk moeilijker is om te bepalen welk wachtwoord van jou is

[banaj]

Niet slim dus.

[1superheld]

Als ik het artikel lees, is het een issue wanneer er een get gedaan wordt per karakter ipv wanner het gehele wachtwoord ingevuld (en gehashed) is?

[Nark0tiX]

Moet je wel aardig wat tijd en resources hebben.

[zenlord]

Correct, maar als gebruiker moet je toch wel vertrouwen hebben in die site waar je je wachtwoord ingeeft (niet alleen dat de beheerder geen kwade bedoelingen heeft, maar ook dat die zeer goed weet de site te beveiligen tegen derden met kwade bedoelingen)

[jdh009]

Kun je die vergelijking niet ook lokaal/client side regelen na het opgeven van een mailadres die geverifieerd wordt bijvoorbeeld? Krijg je x hashes en kun je lokaal vergelijken of regel je het anders door alleen hashes te sturen naar de server. Dan hoe je in theorie geen eens een wachtwoord te versturen en haal je die gevoeligheid eruit.

[Reactie gewijzigd door jdh009 op 22 juli 2024 13:25]

[cotix]

Er zijn natuurlijk slimme manieren om te checken. Wat hibp doet is okay, maar je zou bijv ook een bloomfilter van de lijst kunnen publiceren.

[jaspermeul]

Dat lijkt mij niet heel veel toevoegen als je geen unieke wachtwoorden gebruikt.
Met bijna 10 miljard verschillende wachtwoorden zullen ongeveer alle normale wachtwoorden er wel tussen zitten. Zoals het dus niet gecombineerd is met een inlog kan je het ook maar (grotendeels) voor bruteforcen gebruiken.

[Mijzelf]

10 miljard is niet veel in vergelijking met het aantal mogelijke wachtwoorden. Wanneer je je bij wachtwoorden beperkt tot grote en kleine letters en cijfers, heb je 62 mogelijkheden per karakter. (26+26+10). Je heb dan 5.6 karakters nodig om tot 10 miljard mogelijkheden te komen (62^5.6 ~ 10.9 miljard). Met 6 karakters zit je al bijna op 57 miljard mogelijkheden.

Dus ja, ten opzichte van 'echt' bruteforcen kan dit een hoop besparing opleveren.

[playon1955]

Dit lijkt mij allemaal theoretisch geleuter van de bovenste plank. Na 3 verkeerde inlogpogingen lig je er toch gewoon uit.

[lmartinl]

Excuses voor de botheid maar dan begrijp je het helaas niet en deze uitspraken zijn gevaarlijk.

Vooropgesteld zijn er helaas vaak genoeg end points die oneindig inlog requests accepteren, danwel direct als via een exploit.

Het grotere risico is dat er regelmatig databases met encrypte data gelekt worden. Daarop kun je dus deze ‘theoretische’ brute force algoritmes, of rainbow tables met veelvoorkomende wachtwoorden loslaten.

Dan is bij een succesvolle poging de data gedecrypt, met als bijvangst: je inloggegevens+password zijn nu ook bekend, en deze kunnen weer gebruikt worden om te kijken of ze op andere services ermee kunnen inloggen.

Stel je komt in iemands email, dan kun je overal wachtwoord resets voor aanvragen. Het is een soort sudoku puzzel dat zich ontvouwt

Specifiek hierom is het dus zo belangrijk dat je 1) een wachtwoord kiest dat en lang genoeg (brute force) en niet veelvoorkomend (rainbow tables) zal zijn 2) je overal een uniek wachtwoord voor hebt (zeker voor je emailadres en eventuele password manager)

[musiman]

Het is geen bruteforce, maar een dictionary attack. Maar nu met een iets uitgebreidere dictionary.

[Ossebol]

Het lijkt mij nuttiger dat browsers een API toevoegen om bij het aanmaken/bewerken van een wachtwoord in een form, een waarschuwing te tonen als het wachtwoord voor komt in de lijst.

[musiman]

In ieder geval Microsoft doet al iets dergelijks. Wanneer je in Azure een veel gebruikt wachtwoord kiest, krijg je de melding dat die te vaak gebruikt is.

[beerse]

Waarmee ze impliciet aangeven dat de wachtwoorden op de servers leesbaar zijn. Dat is dan een niet zo netjes systeem: Ofwel de wachtwoorden zijn onversleuteld over de lijn gegaan ofwel ze zijn versleuteld zodat ze ontsleuteld kunnen worden.

Het zou beter zijn als jou wachtwoord zo snel mogelijk, liefst op jou eigen systeem, en niet-terug-te-draaien versleuteld worden.

[Ossebol]

Dat hoeft helemaal niet. Je kunt prima een wachtwoord lokaal hashen en de hash vergelijken met een database aan hashes. Aangezien je een hash niet terug kunt draaien, zul je nooit het oorspronkelijke wachtwoord zien.

[beerse]

Dat klopt. Maar daarmee kan het wachtwoord dus nooit vergeleken worden met de wachtwoorden in de lijst aan de andere kant. Of gaat de server voor elke wachtwoord verandering de hele lijst hashen? De seed is immers voor elk gewijzigde wachtwoord anders dus de hash ook.

[Ossebol]

Misschien begrijpen we elkaar niet. Wat ik bedoel is dat lokaal, op een computer, het wachtwoord wordt gehasht. Enkel deze hash wordt via het internet naar een server verstuurd. Deze server zoekt deze binnengekomen hash dan op in een database met hashes van alle gelekte wachtwoorden. Het resultaat van deze check wordt terug naar de computer van de wachtwoordbedenker gestuurd, om vervolgens een juiste melding te tonen.

Bij een wachtwoordwijziging gaat enkel opnieuw de hash van het gewijzigde wachtwoord naar de server, en herhaalt het proces zich.

Of bedoel je iets anders en begrijp ik je niet goed?

[beerse]

Dat is precies wat ik bedoel. Met als detail dat de hash die op jouw machine wordt gemaakt een random seed gebruikt om de hash te berekenen. Om dan de hash van jouw wachtwoord te vergelijken met de hash van 10-miljard wachtwoorden, dan moet je dus die 10-miljard wachtwoorden met jouw seed hashen. Dat is nogal wat werk. En dat moet dus voor iedere wachtwoord verandering.

Bij een toegangscontrole wordt de seed die ooit bij het aanmaken van jouw wachtwoord naar jouw lokale machine gestuurd om daarmee het wachtwoord te hashen zodat de hashes gecontroleerd kunnen worden.

Bij het maken van een nieuw wachtwoord wordt ook een nieuwe, random seed gemaakt en gebruikt. Als steeds een zelfde seed gebruitk wordt is dat een security issue.

[MrWillow]

Een hash is een Hash.

Daar voeg je dus geen random seed aan toe.

(Mag natuurlijk wel, maar dan heb je het niet meer over een hash)

Ik deel @Ossebol zijn/haar analyse.

[beerse]

De ene hash is de andere niet, als het goed is helemaal niet. Iedere hash heeft een seed, als het goed is een eigen, random seed. Juist met wachtwoorden maar ook met elke andere versleuteling word steeds weer een andere eigen seed gebruikt.

De meeste problemen met versleutel software de laatste jaren heeft te maken met een niet-zo-random seed en daarmee kan de versleuteling dan worden doorbroken.

[SunnieNL]

En dan krijg je continue meldingen dat je wachtwoord op zo'n lijst voor komt, terwijl het niets zegt.
Ik krijg op mijn ipad ook continue de melding dat een van de wachtwoorden op die lijst staat. Leuk, maar je hebt er niets aan zonder de unieke mailadres dat er bij hoort. Zolang je dat mailadres niet hebt komt je er ook niet in (en daarna volgt nog MFA).

[sympa]

Het geeft wel aan dat je wachtwoord niet uniek is, of gelekt is.
Dus cru gezegd: je had net zo goed Welkom123 als wachtwoord kunnen gebruiken. Ofwel je hebt je best gedaan en je wachtwoord is ergens gelekt.
En je wilt geen van beide.

[SunnieNL]

Ik weet dat het wachtwoord is gelekt en ook via welke dienst. Dat is het voordeel aan unieke mailadressen. De combi is uniek voor maar 1 dienst.

[lmartinl]

Als je dat wachtwoord (of makkelijk te bedenken variaties op dat wachtwoord) op andere plekken gebruikt zou ik me echt wel zorgen maken..

[Reactie gewijzigd door lmartinl op 22 juli 2024 13:25]

[SunnieNL]

Ik niet, dat wachtwoord wordt gebruikt voor diensten waar verder geen persoonlijke info aan hangt.
Afhankelijk van de dienst wordt een bepaald wachtwoord gebruikt en wel of geen 2FA ingeschakeld. Maar altijd met een uniek emailadres voor die dienst.

Je gaat ook geen slot van 1000 euro op je tuinhekje hangen.

[Reactie gewijzigd door SunnieNL op 22 juli 2024 13:25]

[lmartinl]

In dat geval wil je het wachtwoord vast delen hier?
Wij weten immers je email adres niet

//edit: niet doen. Wachtwoorden worden namelijk vaak wel encrypted en salted opgeslagen in (gelekte..) databases; gebruikersnamen niet. Als eenmaal je wachtwoord in een rainbow table zit valt dat passwoord eenvoudig te kraken in gelekte database en staat je username er gewoon naast.

Daarbij gaat je vergelijking mank want een beter slot is duurder en zwaarder dan een goedkoop slot. Het mooie is dat als je eenmaal een password manager gebruikt, elk slot gratis en gewichtsloos is.

[Reactie gewijzigd door lmartinl op 22 juli 2024 13:25]

[killercow]

Heb je daar een linkje van? Want dat is nog best een serieuze verdachtmaking.

[xxs]

Aangepast.

Dank voor je opmerking.

[kodak]

De uploader stelt de vorige lijst aangevuld te hebben uit andere datalekken en recent gekraakte wachtwoorden. Bedenk eens hoeveel lekken er moeten zijn om de voorgaande compilatie met een miljard unieke wachtwoorden aan te kunnen vullen. Dan mag je ergens maar hopen dat de lijst voor een deel flauwekul is.

[Reptile209]

Dat is dan weer het voordeel voor de uploader: als het een lijst met credentials was, kon je een paar (honderd) steekproeven doen om te zien of de data klopt. Met alleen maar passwords is dat onmogelijk natuurlijk, tenzij je toevallig je eigen standaard wachtwoord er tussen ziet staan . Hij kan dus net zo goed de passwords uit een eerdere hack hebben aangevuld met zelf gegenereerde passwords. Niet te checken!

[kodak]

Er zijn wel wat meer mogelijkheden. 1 miljard extra unieke wachtwoorden komen niet spontaan uit nieuwe lekken. En aangezien het kennelijk volgens de uploader ook nog om gedeeltelijk recent gekraakte wachtwoordhashes gaat is het prima te achterhalen of dat overeen komt met hashes uit eerder gepubliceerde lekken. En voor we dan stellen dat het niet vinden van overeenkomsten niets zegt, er valt bij dit soort enorme aantallen wel een verhouding te verwachten tussen bekende en 'nieuwe' wachtwoorden. Of bijvoorbeeld verhoudingen tussen waarschijnlijk menselijk gegenereerde wachtwoorden of door een applicatie. Eigenlijk had ik wel verwacht dat de onderzoekers daar naar gekeken hebben voor ze met dit nieuws kwamen.

[Alxndr]

Tien miljard klinkt veel, maar hoeveel wachtwoord combinaties zijn er als we alleen al tot 8 tekens lang kijken?

should contain upper and lower case characters, numbers, and special characters. This provides a character set of 95 possible characters. An eight-character password using a character set of 95 has a key space of 958, approximately 7×10^15

Dus zelfs zonder alle 'verstandige' mensen die meer tekens gebruiken is deze set nog geen miljoenste...

[Reactie gewijzigd door Alxndr op 22 juli 2024 13:25]

[Groningerkoek]

Juist daarom zijn lijsten met daadwerkelijk gebruikte wachtwoorden zo fijn. En 10 Miljard daadwerkelijk gebruikte wachtwoorden is best wel veel. Het is niet dat de gemiddelde burger tientallen verschillende wachtwoorden gebruikt.

[beerse]

Bedenk dat een wachtwoord per positie 10 cijfers, 26 hoofdletters, 26 kleine letters en nog een stuk of wat leestekens kan bevatten: zeg 75 per positie.
2 posities == 75x75 == 5625
3 posities == 421875
4 posities == 31640625
5 posities == 2373046875
6 posities == 177.978.515.625‬
Detail is dat van de speciale tekens lang niet alles wordt gebruikt. Ik kan mij niet voorstellen dat iemand het gulden/florijn teken ƒ in haar wachtwoord gebruikt.

[delphium]

Gebruik altijd twee factor authenticatie! Ik heb een aantal dagen terug een yubi-key gekregen van Tweakers.net. Het is mijn vierde al, maar toch ben ik er blij mee.

Als je dergelijke systemen gebruikt in combinatie met een echt sterk wachtwoord (zoek dat maar gewoon op via duckduckgo), dan ben je als gewone consument echt wel heel erg safe.

[SunnieNL]

Ik was ook wel blij met de Yubikey voor de Elite members
Enige nadeel is dat ze aangeven dat je er het beste 2 kan hebben zodat je een backup key hebt. Dus ik zit daar even op te wachten voor ik hem ga gebruiken

[lmartinl]

Uit mijn ervaring is een tweede 2fa vooral belangrijk. Dus een unikey + een 2fa app is prima.

Dat is ook direct zo fijn aan die ubikey, als je je telefoon kwijt raakt heb je nog een tweede fysiek apparaat voor de 2fa (in tegenstelling tot bijv een sms 2fa)

[Dennisb1]

Duurt vast niet lang voor deze openbaar te downloaden is. Erg handig met hashcat dan voor research mogelijkheden.

[neonite]

Hier is een wachtwoordenlijst met 28 miljard wachtwoorden

[svennd]

Nuttig voor criminelen en ethical hackers ...

[Sissors]

En voor bedrijven, door iig de meer voorkomende wachtwoorden op een zwarte lijst te zetten die je niet mag gebruiken wanneer je een nieuw wachtwoord wil kiezen.

[svennd]

Bleurk laten we hopen van niet, wachtwoorden zijn sowieso niet een afdoende bescherming, daarvoor is er MFA. Maar om iedere factor op zich dan nog door tal van checks te gooien maakt het voor gebruikers niet percé beter op.

[Sissors]

Ik heb 100x liever dat veelvoorkomende wachtwoorden geblockt worden, dan dat geneuzel met dat Welk0m! een sterk wachtwoord is, maar q34cRWc4wrc1Wxrcwrs4c3C afgekeurd wordt omdat er geen speciale tekens in zitten.

[RobbyTown]

Ja en dan heb je Pathe daar mag je juist weer geen speciale tekens in je wachtwoord . Dus q34cRWc4wrc1Wxrcwrs4c3C is dan weer perfect.

[Punkbuster]

die gebruik ik al

[CivLord]

Zolang de aanvaller niet weet wat voor tekens ik gebruik of hoelang mijn wachtwoord is, is 00000000000000000000 net zo sterk als 1dgnk%50-gjeGEl!

[svennd]

jep, maar wel redelijk eenvoudig voor shoulder surfers...

[lmartinl]

En als mijn oma wielen had..
Met diezelfde rationaal is dat net zo sterk als Welkom123

Helaas is dat in de praktijk niet zo. Ik vind het incorrect en slecht advies wat je zegt

[Reactie gewijzigd door lmartinl op 22 juli 2024 13:25]

[CivLord]

Welkom123 staat in de top 5 van elk rijtje dat een hacker zal proberen.
Maar leg uit waarom mijn 'advies' in de praktijk incorrect en slecht is.

[lmartinl]

00000000 staat ook gewoon in dat rijtje hoor.
Een random generator dat ingesteld staat op alle speciale karakters zal inderdaad theoretisch net zo veel kans hebben 00000 als k23Jz te genereren.
Mensen kiezen in de praktijk eerder voor 0000 dan k23Jz.

Sterker, zelfs mensen een random getal onder de 100 laten kiezen is totaal niet gelijk verdeeld. Tom Scott heeft hier een leuk filmpje over.

Plus de opmerking van svennd hierboven

Het is dus niet 'net zo sterk'. Het is een belachelijk slap wachtwoord.

[Reactie gewijzigd door lmartinl op 22 juli 2024 13:25]

[Bor]

En voor bedrijven, door iig de meer voorkomende wachtwoorden op een zwarte lijst te zetten die je niet mag gebruiken wanneer je een nieuw wachtwoord wil kiezen.

Aan de ene kant is dat slim maar aan de andere kant maak je het voor gebruikers wel heel snel heel moeilijk wanneer je 10 miljard unieke wachtwoorden uitsluit. Dat zal mogelijk frustratie opleveren waardoor mensen mogelijk een nog slechter alternatief gaan kiezen.

[JDx]

Een slechter alternatief dan een al bestaand wachtwoord lijkt me onmogelijk, wat wel mogelijk is, dat het wachtwoord zo ingewikkeld wordt dat het het op een sticky note schrijven en op het beeldscherm plakken, zoals ik wel eens heb gezien bij (grote) bedrijven. Welkom01 (waar de 01 voor januari staat) ook zoiets.

[Bor]

Met het aantal wachtwoorden op de wereld momenteel is de kans heeeeeel erg groot dat een wachtwoord al ergens bestaat ook al zit hij niet in deze set.

[LA-384]

Ik durf te stellen dat mijn hoofd wachtwoord uniek is op de wereld. Ik heb een rijtje woorden genomen in een niet-nederlandse taal, waarbij ik van elk woord de eerste twee letters heb genomen en een deel van de letters heb vervangen voor gelijkende symbolen en cijfers, afgewisseld met hoofd- en kleine letters.

Ik heb mezelf de toetsencombinatie aangeleerd en zou het zo niet met pen kunnen uitschrijven. Het heeft iets van 12 of 14 tekens.

Voor de rest gebruik ik een wachtwoordmanager.

[Miglow]

Zie ik bijna overal waar ik kom. En dan 01 doorgestreept met 02 erboven wegens elke zoveel tijd verplicht veranderen

[dlaoR]

Dat is ook het probleem met wachtwoorden en de steeds maar toenemende vormvereisten: er zit ook een humane kant aan. Iemand moet dat wachtwoord kunnen onthouden en reproduceren. Als daar een hulpmiddel voor gebruikt wordt, is het wachtwoord zelf hooguit zo veilig als dat hulpmiddel. En als dat een sticky note of tekstbestandje is...

[JDx]

GewoonEenBroodjePindakaasUit1980&Jam?Lekker!

[killercow]

https://github.com/minvws/horsebattery

[musiman]

Zorg ervoor dat je minimaal 6 woorden gebruikt. Met minder dan 6 Nederlandse woorden kan een aanvaller alle woorden in de dictionary combineren en proberen. Met 6 woorden heb je (in het Woordenboek der Nederlandse taal staan 430.000 woorden) 430.000 x 430.000 x 430.000 x 430.000 x 430.000 x 430.000 = 6,321363049e+33 mogelijkheden. Dat is op dit moment ruim voldoende om dit soort aanvallen af te slaan.

Die Rockyou2024 is trouwens al oud... Ik heb 'm al een paar weken geleden gedownload! Helaas oud nieuws dus (nou ja, oud is in IT security landschap een relatief begrip, want ik vind het oud maar T.net blijkbaar niet).

[uiltje]

Meestal rekenen we bij security met bits, dit is ongeveer 112 bits, oftewel de sterkte van een 3-key triple DES sleutel. Zeker voldoende aangezien je de wachtwoorden als aanvaller ook nog moet genereren / testen. Wat slap voor AES versleuteling; versleutelen met een wachtwoord is sowieso geen goed idee.

[cariolive23]

Ik werk voornamelijk op Apple spul, Safari kiest al járen voor mij de wachtwoorden. Echt onmogelijke wachtwoorden om te verzinnen of te onthouden, maar Safari doet z'n best. Ik kan me zo voorstellen dat je voor Android en Windows vergelijkbare functionaliteit hebt.

Met hoofdletters, kleine letters, nummers en een paar leestekens, uitgesmeerd over bijvoorbeeld 16 karakters, heb je al bijna net zoveel wachtwoorden als dat er zandkorrels op aarde zijn... Die 10 miljard meer of minder, vallen dan echt niet meer op.

[kuurtjes]

Theoretisch gezien kan je dit nooit credential stuffing noemen. Credential stuffing is de specifieke naam voor het proberen met credentials die ergens anders geldig zijn.

En praktisch gezien kan je dit ook bijna niet gebruiken op een online dienst. Zelfs als je duizenden bots hebt die allemaal samen werken om 1 specfiek account te kraken ga je nog steeds dagen bezig zijn om door heel de lijst te geraken. Een login poging op een online dienst kost wel wat resources.

Zo'n lijst is alleen goed om password hashes te kraken.

[gevoelig]

Credential stuffing is de specifieke naam voor het proberen met credentials die ergens anders geldig zijn.

Hoe weet je dat dit hier niet het geval is. Het is tot stand gekomen van bestanden uit andere data lekken. Geldige credentials lijkt mij.

[Bor]

Dat wel maar voor een succesvolle credential stuffing aanval heb je hier een aantal problemen;

- De lijst is veel te lang om allemaal bij langs te lopen zonder op te vallen
- Geen usernames beschikbaar

Een lijst als deze is door zijn omvang vooral geschikt voor offline cracking.

[kuurtjes]

Je hebt de helft van een credential die je niet 1:1 bij een andere service kan gebruiken. Dat is wat een credential stuffing aanval is.

[geerttttt]

En ook om gebruikers te attenderen dat hun wachtwoord niet veilig genoeg is wellicht...

[eurob]

Hoog tijd om geen wachtwoorden meer hoeven te gebruiken, weet niet wat het alternatief is gezien het feit dat 2FA ook al omzeild kan worden, misschien passkeys? Weet daar niet genoeg van.

[RobIII]

Waar haal je vandaan dat 2FA omzeild kan worden?
SMS 2FA wordt onveilig geacht (SIM "bietsen" is vaak (te) 'eenvoudig'), maar is nog altijd een behoorlijke drempel. En een (degelijk uitgevoerde) TOTP omzeil je niet "zomaar" tenzij je specifiek die gebruiker ergens in laat stinken. Maar dat laatste helpt niks tegen.

[Reactie gewijzigd door RobIII op 22 juli 2024 13:25]

[ShadLink]

Het grootste gevaar zit hem nu in sessiekapen, waar de aanvaller niet eens je wachtwoord hoeft te weten maar gewoon je sessiecookie overneemt. Met alle gevolgen van dien.

[eurob]

Zal waarschijnlijk niet vaak voorkomen...
https://zitadel.com/blog/2fa-bypass-attacks