Have I Been Pwned brengt 2.0-versie uit van datalekzoekmachine

Have I Been Pwned 2.0 is uitgebracht, meldt oprichter Troy Hunt. De website van de datalekzoekmachine is vernieuwd en biedt een verbeterde zoekfunctie. Ook is er een nieuw centraal dashboard om meldingen te ontvangen over datalekken.

Troy Hunt deelt dat de nieuwe Have I Been Pwned-website live is. Die bevat onder andere een nieuw centraal dashboard om verschillende functies samen te brengen. Ook nieuw is de Breach Page, een pagina voor ieder lek die advies bevat over gebruikersacties na een lek. Voorbeelden van adviezen zijn het wijzigen van wachtwoorden, het instellen van tweefactorauthenticatie en het gebruiken van een wachtwoordmanager.

Daarnaast is de domeinzoekfunctie van HIBP volgens Hunt nu overzichtelijker, waarbij gefilterd kan worden op e-mailadressen en de recentste inbreuk. Ook de verificatie van domeineigendom is volledig herschreven en heeft een eenvoudigere, overzichtelijkere interface gekregen.

De ondersteuning voor het zoeken naar gebruikersnamen en telefoonnummers is verwijderd, onder meer omdat deze lastiger te extraheren zijn uit datalekken dan e-mailadressen. Een antwoord op de vraag Have I Been Pwned is volgens Hunt bovendien ook te beantwoorden 'zonder die twee moeilijk te ontleden velden te laden, die bij de meeste inbreuken toch al niet aanwezig zijn'.

Gebruikers kunnen met Have I Been Pwned controleren of hun e-mailadres of wachtwoord is gelekt in een datalek dat bekend is bij HIBP. De website toont onder meer informatie over de aard van het lek, welke gegevens er precies zijn getroffen en wanneer het lek plaatsvond.

Reacties (78)

[xenn99]

Het nut van haveibeenpwned is voor mij de laatste jaren erg afgenomen omdat ze alleen posten dat je mail adres gevonden is maar niet met welk wachtwoord.
Ook staan er heel veel lekken op de lijst van bedrijven waar ik nog nooit mee in aanraking ben gekomen.
Inmiddels kom ik voor in 19 verschillende datalekken waarvan meer dan de helft van bedrijven waar ik nog nooit van heb gehoord.

De Pwned passwords functie is wel erg handig, het enige nadeel is dat je dan dus je wachtwoord naar Troy moet sturen.
Meerdere oude wachtwoorden die ik ooit gebruikte kwamen voor in de data.

[dennizzz]

maar niet met welk wachtwoord.

The problem with storing passwords alongside email addresses (and this problem goes back to day 1 of HIBP), is that I end up sitting on the motherlode of credentials which is a huge risk, both for the individuals involved and myself. The approach I've taken is to load the passwords into Pwned Passwords so you can always check the password alone there, but nobody can ever join the dots of who those passwords belong to.

(in reacties op deze pagina: https://www.troyhunt.com/processing-23-billion-rows-of-alien-txtbase-stealer-logs/)

Maar het zou natuurlijk ook geen issue moeten zijn als je voor elke dienst een ander wachtwoord in je wachtwoordmanager hebt.

het enige nadeel is dat je dan dus je wachtwoord naar Troy moet sturen.

Nope, dat doe je niet: https://www.troyhunt.com/understanding-have-i-been-pwneds-use-of-sha-1-and-k-anonymity/

[xenn99]

Ik heb een ander wachtwoord voor elke dienst, dat is juist het probleem.
Doordat ik alleen het mail adres kan zien en niet het wachtwoord, en ik de bedrijven op de lijst niet herken heb ik werkelijk geen idee wat er nou precies is gelekt.

[Muna34]

Misschien weet je het volgende al maar binnen de mail standaard bestaat hier een mechanisme voor. Neem dit met een korreltje zout want niet iedere website of service honoreert/herkent/implementeert deze specificatie.

Je kan namelijk sub-addressing gebruiken. Je kan met deze standaard in het lokale gedeelte met een + teken wat toevoegen ter herkening - of aan de kant van de mail server - filtering van mail. i.e. [e-mail] of [e-mail]

Als die sketchywebsite dan iets lekt naar een 3de partij dan zou je dit op die manier kunnen zien. BIjvoorbeeld wanneer de 3de site een nieuwsbrief stuurt met als geaddreseerde [e-mail]. Ik heb al meermaals op deze manier gezien welke winkels gegevens delen.

Nogmaals, dit werkt bij laten we zeggen 50%, maar zeker de moeite waard als je het mij vraagt.

[Frolow]

Jammer genoeg ondersteunt HIBP dan weer niet sub-adressing, dus als je [e-mail] hebt en [e-mail] is gebreached, dan krijg je daar helaas geen alerts van tenzij je al je sub-adresses invoert in HIBP. Je moet dus continu actiever zelf monitoren in plaats van dat je gewaarschuwd wordt.

[DataGhost]

Dit is geen standaard in de zin van dat het bij elke mailprovider werkt. Bij Gmail toevallig wel maar bij genoeg providers niet. Verder een behoorlijk nuttloze standaard, want het "echte" mailadres is alsnog bekend en iemand kan gewoon het gedeelte met de + weghalen of veranderen.

[Niemand_Anders]

Kopt, qmail gebruikt al sinds jaar en dag de dash (-) als scheidingsteken. Anders dan een plus, is een dash gewoon toegestaan in linux/unix usernames en is sub-addressing ook geen issue...

Deels offtopic:
Overigens heb ik een /dev/null forward op mijn algemene email adres staan. Dus alleen als je een sub-address gebruikt, waarvan een deel overeen (het gedeelte na de dash tot eventueel een volgende dash) moet komen met het verzendende domein, komt jouw email in mijn mailbox. Doordat al mijn emailadressen de website bevatten waar ik hem achterlaat ([e-mail]) weet ik ook wanneer het bedrijf achter die website mijn gegevens heeft verkocht of een datalek heeft gehad...

Ik heb een extension voor thunderbird welke het 'to' field ook gebruikt als afzender bij een reply of forward zodat ook dan de koppeling niet breekt. Oorspronkelijk had ik nog een eigen geschreven extensie welke blokkeerde dat ik een mail kon versturen met afzender [e-mail], maar als er een enkele ontvanger is, of alle ontvangers behoren tot hetzelfde domein, dan krijg ik een popup met de vraag of ik de afzender wil aanpassen...

Ik draai al mijn eigen mailserver sinds 1999 en ook al zo lang gebruik ik deze methodiek.

[DataGhost]

Okee, maar in de meeste gevallen (in ieder geval bij Gmail) komt mail op het algemene adres wel aan, en dat is wat het voor mij nutteloos maakt. Zelf werk ik met een whitelist (aliassen) en uiteindelijk hetzelfde resultaat als wat jij hebt, wellicht met als verschil dat ik adressen dus weer weg kan gooien als er gelekt is maar ik vermoed dat je daar aan gedacht hebt.

Wel ben ik benieuwd naar die extensie voor Thunderbird, ik ben er jaren geleden naar op zoek geweest maar toen was er geen die goed werkte (er bleef nog een restant van het "echte mailadres" hangen, wat niet geldig is op internet en spamfilters triggerde), dus ik zou graag die van jou nog eens proberen. Momenteel maak ik voor elk adres waarmee ik moet verzenden een identity aan maar dat is giga-onoverzichtelijk ondertussen, en een klein kutwerkje.

[Die_ene_gast]

Een beetje hacker doet dan toch alles tussen de + en @ verwijderen? (incluis de +). Dan heeft dat weinig zin lijkt mij.

[Anonyymm]

Ik heb het een tijd op die manier gedaan, maar merkte dat ik het ook behoorlijk vervelend vond als het emailadres gelekt werd. En misschien ook wel net zo minder prettig omdat het een deel van de toegang is. Uiteindelijk ben ik langzaamaan voor elke dienst een ander emailadres gaan gebruiken. Zo'n adres wat automatisch aangemaakt kan worden via bijvoorbeeld iCloud of passmail. Of via gmail door een alias in het mailadres verwerken.

Het niet tonen van wachtwoorden vind ik beter. Voorkomt verder misbruik als het wachtwoord niet gewijzigd is. Plus vaak zit er een bepaalde logica in verzonnen wachtwoorden.

[dennizzz]

De bedrijven die je niet herkend zijn vaak spamlists. Die zijn via via aan je gegevens gekomen. Lang niet altijd omdat ze een dienst gehackt hebben (in het geheim, anders stond die dienst ook op HIBP), maar vaak ook door scraping van social media of het doorverkopen van mailadressen. Dan hebben ze je wachtwoord niet eens.

[tszcheetah]

Volgens mij hebben meerdere wachtwoordmanagers tegenwoordig ook ondersteuning voor het checken van wachtwoorden tegen de HIBP-database. In mijn geval gebruik ik Vaultwaden (self-hosted), waarbij ik op de web UI een report van alle exposed passwords kan krijgen (de Bitwarden client kan alleen een check per entry doen).

Het kost een stap meer, maar op die manier kun je dus zelf wel achterhalen welk wachtwoord eventueel gelekt is.

Overigens bevat niet elk lek bij HIBP ook wachtwoorden, er staan ook datalekken in waarbij alleen andere gegevens (zoals je e-mailadres) gelekt zijn.

[banaj]

[...]
Nope, dat doe je niet: https://www.troyhunt.com/...of-sha-1-and-k-anonymity/

Technisch klopt het wat je zegt. Effectief niet. Het is het equivalent van: heb je wachtwoorden die lijken op "***sword2025!"? De dienst stuurt dan alles wat daarop lijkt terug, en je matcht het laatste stukje zelf lokaal. Niet heel moeilijk om dan het wachtwoord alsnog af te leiden

De wachtwoorden zijn opgeslagen als SHA-1, dat is het enige verschil. En die set van PwndPasswords is vrijwel volledig gekraakt, dus het omzetten van SHA-1 naar plain is simpel voor iedereen die ook communucatie van afvangen (naast Troy Hunt die volledige toegang heeft).

[P_de_B]

Je stuurt een hash, niet het echte wachtwoord.

[banaj]

Klopt, dat staat ook in mijn reactie Uitgelegd als plain. Maar dan is het een SHA-1 hash in PwndPasswords. 't Spelletje is identiek.

Voorbeeld voor wachtwoord "Password2025!". Je stuurt dus NIET een stukje van dat wachtwoord ("***sword2025!" = simpel voorbeeld), maar een stukje van de SHA-1 daarvan. PwndPassword stuurt dan NIET alle wachtwoorden die in het masker passen, maar alle SHA-1's van wachtwoorden die in het masker passen. Van al die SHA-1's weet je wat het bijbehorende wachtwoord is (Troy Hunt heeft ze zelf berekend dus 100% bekend bij hem, de rest van de wereld heeft 99,48% gekraakt). Je weet dus niet EXACT welk wachtwoord het is, maar wel in welke zeer beperkte set ie zit. Je lekt dus heel veel entropie.

Troy Hunt weet het mooi te vertellen, maar PwnPassword doet niet wat het beloofd, door beperkt inzicht: "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."

[Reactie gewijzigd door banaj op 21 mei 2025 13:34]

[svane]

Als je 't goed doet, lek je niks. De SHA-1 hash van mijn wachtwoord begint met d6eae.

Via de API krijg je dan een fikse lijst hashes terug.

Nu zijn er twee mogelijkheden:

1. De volledige hash van mijn wachtwoord staat wel in deze lijst. Vervolgens pas ik mijn wachtwoord aan, en is de informatie waardeloos voor kwaadwillenden.

2. De volledige hash van mijn wachtwoord staat niet in deze lijst. Nu weet Troy Hunt de eerste 5 characters van de hash mijn wachtwoord. Wat kan hij daarmee? Helemaal niets:*

Mathematically, with the next 34 characters unknown, there are 16^34 different possible hashes that this prefix could belong to. Just to really labour the point, given a 6 character SHA-1 hash prefix you could take a 1 in 87,112,285,931,760,200,000,000,000,000,000,000,000,000 guess as to what the full hash prefix is. And then due to the infinite number of potential input strings, multiply that number out to... well... infinity.

Je 'lekt' dus absoluut niet heel veel entropie. Je lekt juist zo weinig dat niemand ter wereld iets met deze informatie kan, niet eens een beetje. Enkel en alleen als je bewust je gelekte wachtwoord blijft gebruiken loop je gevaar, maar in dat geval was dit wachtwoord al lang bekend bij hackers, dus 'lek' je niks nieuws.

* Deze quote specifiek gaat over email-adressen, waarbij 6 characters bekend zijn. Voor de wachtwoorden (met 5 bekende characters) moet je de cijfers nog even keer 16 doen, al maakt dat voor oneindigheid weinig uit.

[banaj]

Als iedereen alles goed deed, bestond HIBP niet

Jij zegt dat je niet veel entropie lekt als je geen antwoord krijgt. Dat klopt en bestrijd ik niet: ik zeg dat je veel entropie lekt als je wel een antwoord krijgt. Beide kunnen tegelijkertijd waar zijn. Echter.

Als je geen antwoord krijgt dan lek je 6 nibbles = 24 bits. De theorie die jij daarna post is... theoretisch. Er blijven 160 (SHA-1) - 24 = 136 bits over = 2^136. Als en alleen als jouw wachtwoord willekeurig is en alle mogelijke karakters bevat ([0x00-0xff]), dan is dat niet te doen, eens.

Dan de realiteit. Prakrisch gebruiken de meeste mensen ASCII-gebaseerde wachtwoorden van typisch maximaal 8 lang. Laten we de karakterset "?s" van hashcat gebruiken, is 26 + 26 + 10 + 33 = 95, maakt een keyspace van 95^8. Sommetje: 2^136 / 95^8 = 13.130.781.299.951.264.532.498.589x kleiner. Met een RTX-4090 kun je ~50 miljard SHA-1's per seconde genereren, dat is alle opties in ~36 uur. Die filter je op de 6 nibble prefix. Dan blijven er een paar honderd mogelijke ASCII-wachtwoorden over. Dat is andere koek dan oneindig! En zelfs in het scenario dat ik niet noemde lek je dus genoeg entropie om een aanval mogelijk te maken.

Tuurlijk verliest de aanvaller dit spelletje als de wachtwoorden lang genoeg zijn. Maar dat is niet de realiteit voor de meeste mensen.

[Reactie gewijzigd door banaj op 21 mei 2025 16:21]

[svane]

Ik waardeer je rekensommen en de moeite die je neemt om het uit te leggen, maar ik hoop dat je ook open staat voor mijn berekeningen. Plus, als één van de bekendste security researchers zegt dat het veilig is, is dat op z'n minst een reden om je cijfers te dubbel checken.

Dan blijven er een paar honderd mogelijke ASCII-wachtwoorden over. Dat is andere koek dan oneindig!

Ik zou hier heel graag jouw rekensom van zien, want ergens tussen onze berekening gaat 't mis met een enorme factor.

Je lekt de eerste 20 (niet 24) bits van je sha-1 hash (160 bit).

De hoeveelheid mogelijke hashes gaan daardoor van 2^160 (1,46×10⁴⁸) naar 2^140 (1,39×10⁴²). Dit is grofweg een factor van een miljoen. Dit is ook wat Troy zelf zegt:

there are 16^5 different possible hash prefixes which is specifically 1,048,576 or "roughly a million"........passwords in the service are divided down into a million smaller collections.

Kort gezegd: je lekt in welke van de miljoen categorieën je wachtwoord valt / je verliest een factor miljoen in de veiligheid.

Hoeveel wachtwoorden van 8 karakters zijn er? Als we 95^8 gebruiken kom je uit op 6.634.204.312.890.625 mogelijke wachtwoorden. Als we dit getal door een miljoen delen kom je uit op. 6.634.204.313
Dit zijn niet 'een paar honderd' wachtwoorden, niet eens in de verste verte.

Probeer vervolgens maar eens te kijken hoe een paar miljard inlog-pogingen gaan in de echte wereld. Zijn weinig plekken waar dat lukt binnen een aanzienlijke tijd en zonder opgemerkt te worden. Dit is ook nog eens met de aanname dat de gebruikersnaam bekend is, anders wordt 't helemaal leuk.

Vergeleken met andere aanvallen is dit gewoon niet realistisch. Veel handiger om gewoon lekker met een dictionary attack aan de slag te gaan.

[banaj]

Je lekt de eerste 20 (niet 24) bits van je sha-1 hash (160 bit).

Klopt helemaal, mijn fout. Er zijn niet 6 maar 5 nibbles. Zoals je noemt dus 2^140. Echter irrelevant voor de discussie: 2^140 en 2^136 zijn beide niet te doen. Het punt is dat bij het hashen van wachtwoorden maar een fractie van de keyspace gebruikt wordt, bij 8 lengte mixed-case inclusief symbolen is dat 95^8. En dat getal is waar het om gaat. En is te doen.

Dit is ook wat Troy zelf zegt:

Troy maakt dezelfde denkfout: theoretisch maximum van SHA-1 minus 20 bit = 2^140 (huge, niets mee te doen), versus praktisch gebruik SHA-1 voor wachtwoorden ~= 2^53 in dit voorbeeld (behapbaar).

Als we dit getal door een miljoen delen kom je uit op 6.634.204.313 Dit zijn niet 'een paar honderd' wachtwoorden, niet eens in de verste verte.

Wederom theorie versus praktijk. Theorie: prefixes uniform verdeeld. Praktijk: niet uniform verdeeld door de selectieve invoer van gebruikers, en beperkte invoer van ongeveer 2^53 waardoor in er niet goed uitgemiddeld wordt. Daarnaast zijn veel wel technische mogelijke wachtwoorden praktisch door te strepen omdat ze niet aan policies voldoen of onwaarschijnlijk zijn (123, <spatie><spatie><spatie><spatie><spatie><spatie><spatie>a etc.).

De paar honderd is een educated guess op basis van hier beschikbare datasets van SHA-1-hashes van daadwerkelijk gekraakte wachtwoorden. Daar zou je op af kunnen dingen, maar zoals bovenstaand toegelicht hebben de theoretische getallen en de praktijk een stuk minder met elkaar te maken in dit geval. En onthoud: dit is het slechtste scenario voor een aanvaller, met 0 hits op PwndPasswords. Als je wel hits hebt dan - komt ie weer - lek je heel veel entropie.

[svane]

95^8. En dat getal is waar het om gaat. En is te doen.

Bron? Noem één relevante dienst waar je 6.634.204.312.890.625 inlogpogingen kan doen voordat ze het doorhebben en je blokkeren? Ik hoef slechts één enkele dienst te horen.

Ter illustratie: 95^8 wachtwoorden überhaupt opsturen kost minimaal 53 Petabyte aan dataverkeer. Met een 1Gb verbinding ben je daar zo ongeveer 13 jaar mee bezig om op te sturen. In welke realiteit noem je dit in hemelsnaam 'te doen'?

2^53 in dit voorbeeld (behapbaar).

Zelfde vraag, hoe is dit ook maar een beetje behapbaar?

Theorie: prefixes uniform verdeeld. Praktijk: niet uniform verdeeld door de selectieve invoer van gebruikers, en beperkte invoer van ongeveer 2^53 waardoor in er niet goed uitgemiddeld wordt.

Lees je eens in over hoe hashes werken.

A good hash function should map the expected inputs as evenly as possible over its output range. That is, every hash value in the output range should be generated with roughly the same probability.

Een hash functie hoort uniform verdeelt de zijn, ook als de input dat niet is. Ik zie graag jouw paper tegemoet waar je aantoont dat SHA-1 niet uniform (genoeg) verdeeld genoeg is over de range van wachtwoorden tot 8 characters. Lijkt mij interessant.
Of nog simpeler: hier heb je de API:
https://api.pwnedpasswords.com/range/d6eae
Laat maar zien welke prefixen veel vaker voorkomen dan anderen? Waar zit die 'niet uniforme' verdeling?

De paar honderd is een educated guess op basis van hier beschikbare datasets van SHA-1-hashes van daadwerkelijk gekraakte wachtwoorden.

Op welke berekening heb je die 'educated' guess gebaseerd? Als ik zeg dat er een miljarden zandkorrels in een woestijn liggen, en ik jij zegt 'een paar honderd'. Dan zit er toch iemand simpelweg heel verkeerd te rekenen? Ik laat mijn cijfers zien...

En onthoud: dit is het slechtste scenario voor een aanvaller, met 0 hits op PwndPasswords. Als je wel hits hebt dan - komt ie weer - lek je heel veel entropie.

In dat geval 'lek' je iets wat al bekend is. Dat noem ik niet echt lekken. Anders kan ik ook wel 'lekken' dat de postcodekanjer gevallen is in Balkbrug dit jaar.... niet echt boeiend.

Het lijkt erop dat je liever gelooft dat jij de enige bent die het snapt, en dat al je mede-tweakers niet. Experts en security researchers maken allemaal dezelfde 'denk-fout', en jij niet. Erg jammer. Open staan om iets te leren is belangrijk.

[banaj]

Bron? Noem één relevante dienst waar je 6.634.204.312.890.625 inlogpogingen kan doen voordat ze het doorhebben en je blokkeren? Ik hoef slechts één enkele dienst te horen.

Ik heb het niet over online pogingen. De 95^8 betreft kandidaten genereren (alle, 100%), die je DAARNA gaat filteren prefix. Die je DAARNA gaat filteren op aannemelijke wachtwoorden. Die je DAARNA online gaat proberen.

Lees je eens in over hoe hashes werken.

Wederom: dat is de generiek theorie, die dus generiek juist is. Die bij lage aantallen niet de praktijk is. Stel je hashed 'password': 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8. Nu start 100% met 5baa6. Je hasht twee wachtwoorden: 50% start met 5baa6. Etc. Dat middelt pas later goed uit.

Laat maar zien welke prefixen veel vaker voorkomen dan anderen?

Download alles data van PwndPassword en doe een wc -l op alle prefixes. Dan hoef je mij niet te geloven maar kun je het vaststellen op basis van de data van Tory hunt zelf

Op welke berekening heb je die 'educated' guess gebaseerd?

Een educated guess is niet een berekening. Download een rainbowtable SHA-1's en filter op prefixes. Dan kan je het zelf vaststellen.

Experts en security researchers maken allemaal dezelfde 'denk-fout', en jij niet.

Correct. Op herhaling. Theorerische keyspace SHA-1 minus 20 bit prefix = 2^140. Dat is alleen de praktijk als de invoer volledig willekeurig is. Dus iedere byte willekeurig tussen 0x00 en 0xff. Dat is NIET de werkelijkheid voor wachtwoorden, omdat mensen geen binaire tekens intikkenop hun toetsenbord. En omdat het een string ASCII is, afgesloten met een 0-terminator. En omdat een wachtwoord voor de meeste mensen niet willekeurig is. Daarmee wordt de keyspace verlaagt tot keymap^lengte. Wat bij normale mensen heel heel heel veel minder is. Dat is de essentie van mijn verhaal. Leg uit wat niet klopt.

[svane]

Hoeveel simpel te herkennen als een wachtwoord van een normale gebruiker? Ik zie er ongeveer 0

Jij bent degene die begon over wachtwoorden van 8 characters, jij had het over de hashcat characterset van 95 characters. Ik reken daarmee omdat jij dat graag wou.

Kom s.v.p. ook nog even terug op 2^140 die niet effectief gebruikt wordt, maar in mijn voorbeeld voor slechts ongeveer 2^53. Dat is waar de discussie over begon.

Waarom zou ik daarop terugkomen? Jij wilt graag met een kleine set rekenen, waarbij we iedereen negeren die meer of minder dan 8 characters heeft in z'n password. Ik ga hierin met je mee, is 't weer niet goed. Beide getallen zijn groot genoeg om zo'n aanval compleet nutteloos te maken.
De discussie begon toen je zei: 'Je lekt dus heel veel entropie.'. Dat is dus absoluut niet waar. Of mensen nou 'vooral' wachtwoorden van 8 characters gebruiken of niet maakt niks uit.
Persoonlijk gebruik ik wachtwoorden van 70 mogelijke characters, met een lengte van 12, gaat ook niet lukken.

Hoe kan jij 2^140 entropie aan uitvoer krijgen .......

Als je wachtwoord lang genoeg is kan dat. Als jij wil rekenen met korte wachtwoorden, dan kan dat niet. niet heel gek.

Download alles data van PwndPassword en doe een wc -l op alle prefixes. Dan hoef je mij niet te geloven maar kun je het vaststellen op basis van de data van Tory hunt zelf

Als je zo goed weet hoe je dit kan bewijzen, waarom doe je het zelf dan niet? Zou wel zo netjes zijn. Geen idee waarom ik jouw huiswerk hier zit te doen, maar oké....

Ik heb alle hashes gedownload, 1 file per prefix. 1,035,989 bestanden, 49GB aan data.

Hier een visualisatie van de files. Hoeveel uniformer wil je 't hebben?
99,999% van de files zijn tussen de 43kb en 52kb. SHA-1 is, zoals ik al zei en zoals algemeen bekend is, dus heel uniform verdeeld*

Waar zitten die prefixes die zo veel vaker voorkomen dan de rest? Je hebt dit overduidelijk niet zelf getest maar gewoon verzonnen.

Download een rainbowtable SHA-1's en filter op prefixes. Dan kan je het zelf vaststellen.

Ook gedaan, uiteraard met hetzelfde resultaat.

Maar ik heb al genoeg tijd verspilt. Harde cijfers zullen je vast ook niet kunnen overtuigen. Je zal vast wel een excuus hebben waarom dat data van Troy Hunt zo mooi uniform is.
Blijf vooral geloven dat je zoveel slimmer bent dan security-researchers, zo kom je er wel.

Hier is het begin van de hash van een wachtwoord van 8 karakters: e5a5e
Als jij een lijst kan vinden van 'logische' wachtwoorden waar die van mij ook in staat, dan kan ik je misschien wel serieus nemen, succes.


*De enige 'uitschieter' is 00000 met 64kb. Het lijkt alsof daar iets geks gebeurd is, anders zou ik wel andere files verwachten van 53 t/m 63 kb. Ook komt deze 'piek' niet voor bij de crackstation dataset. En zelfs als SHA-1 een flaw heeft dat hashes die met 00000 23% meer voorkomen dan is dat absoluut niet relevant voor deze discussie.

[banaj]

[...]
Als je wachtwoord lang genoeg is kan dat. Als jij wil rekenen met korte wachtwoorden, dan kan dat niet. niet heel gek.

Dank voor het bevestigen van mijn berekening op basis van het scenario waar deze hele post op gebaseerd is. En daarmee de bevestiging dat de door jou aangehaalde berekening van Troy Hunt dus niet klopt voor voor de meeste mensen gangbare wachtwoorden.

Blijf vooral geloven dat je zoveel slimmer bent dan security-researchers, zo kom je er wel.

Ik geloof niets. Ik toon slechts drie zaken:

• ]Berekeningen op basis van een scenario. Zoals nu door jou bevestigd.
• Edugated guesses, op basis van het tellen van data die ik beschikbaar heb (grep '^prefix' data|wc -l). Als wie dan ook betere guesses heeft (grep '^prefix' betere_data|wc -l): prima, dan ga ik daar helemaal in mee. Vervolgens kom jij met data die nota bene aansluit bij mijn eerste observatie, attendeer ik je daarop en daar reageer je vervolgens niet meer op die opmerking.
• Uitleg over verschil theorie algoritme en praktisch gebruik daarvan. Om toe te lichten waar verschillen zitten tussen wat jij verwacht en ik bereken of observeer. Wat doe jij? Dingen neerzetten als niet waar, heb ik zelf niet getest etc. Terwijl je eigen analyse zichzelf tegenspreekt, lees je eigen getallen en vooral je voetnoot hierboven nog eens terug

En dan interessant doen en allemaal dingen claimen over mij. LOL, ik vind helemaal mooi!

[svane]

Jij komt met de bewering dat SHA-1 hashes niet uniform verdeeld zijn. Jij komt met een manier waarop ik dat zelf kan checken.
Ik check dat, exact op de manier die je zelf voorstelt (data van Troy Hunt downloaden / wc -l / etc.), ik toon aan dat je er compleet 100% naast zit. En toch denk je nog steeds gelijk te hebben. Dat is echt olympische spelen niveau mentaal gymnastiek.

De rest van je verhaal kan je nog tien keer herhalen, maar dat verandert niks. Ook als je met 2^53 rekent (en daarmee vrijwel iedereen met een password manager negeert) dan is dat getal alsnog dusdanig groot dat je er niks aan hebt. Dáár begon de discussie over, of het veilig was om de eerste 5 karakters van je hash te 'lekken'. Dat je wil mierenneuken over de exacte hoeveelheid bits die relevant zijn is leuk voor je, maar daar gaat het niet om.

Ik wacht nog steeds tot je mijn wachtwoord raad: e5a5e. Gezien de enorme entropie die ik lek moet dit voor een security expert als jij toch makkelijk te doen zijn?
We weten allebei natuurlijk dat het je niet gaat lukken, maar hoe leg je dat aan jezelf uit? Daar ben ik eigenlijk wel benieuwd naar. Vertel je jezelf dat je het wel zou kunnen als je probeerde, maar dat het de moeite niet waard is? Zoveel kansen om jezelf te bewijzen met acties, maar in plaats daarvan alleen maar praten. Zo overtuig je niemand natuurlijk.

[banaj]

Jij komt met de bewering dat SHA-1 hashes niet uniform verdeeld zijn.

Nee hoor, ik kom met een veel specifieker voorbeeld ("niet uniform verdeeld door de selectieve invoer van gebruikers, en beperkte invoer van ongeveer 2^53 waardoor in er niet goed uitgemiddeld wordt"). Vervolgens verdraai jij die en toon je aan dat die verdraaiing niet klopt. Dat is het proces dat jij vaker volgt, te beginnen bij mijn punt dat je veel entropie lekt als je wachtwoord bij PwnPassword bekend is. Lees het hele draadje nog eens door.

De rest van je verhaal kan je nog tien keer herhalen, maar dat verandert niks. Ook als je met 2^53 rekent (en daarmee vrijwel iedereen met een password manager negeert) dan is dat getal alsnog dusdanig groot dat je er niks aan hebt. Dáár begon de discussie over, of het veilig was om de eerste 5 karakters van je hash te 'lekken'. Dat je wil mierenneuken over de exacte hoeveelheid bits die relevant zijn is leuk voor je, maar daar gaat het niet om.

Zoals sommigen zouden zeggen: "Dat is echt olympische spelen niveau mentaal gymnastiek" Dus als je wiskunde je niet bevalt: gewoon negeren. Daarnaast wederom een antwoord op een vraag die ik niet gesteld heb: ik heb het nooit gehad over mensen met wachtwoordmanagers. Sterker: ik noem expliciet "Tuurlijk verliest de aanvaller dit spelletje als de wachtwoorden lang genoeg zijn. Maar dat is niet de realiteit voor de meeste mensen".

Ik wacht nog steeds tot je mijn wachtwoord raad: e5a5e. Gezien de enorme entropie die ik lek moet dit voor een security expert als jij toch makkelijk te doen zijn?

Klopt en beantwoord.

We weten allebei natuurlijk dat het je niet gaat lukken, maar hoe leg je dat aan jezelf uit? Daar ben ik eigenlijk wel benieuwd naar. Vertel je jezelf dat je het wel zou kunnen als je probeerde, maar dat het de moeite niet waard is? Zoveel kansen om jezelf te bewijzen met acties, maar in plaats daarvan alleen maar praten. Zo overtuig je niemand natuurlijk.

Haha ik zou psycholoog worden als ik jou was

[Reactie gewijzigd door banaj op 29 mei 2025 13:36]

[banaj]

Ik check dat, exact op de manier die je zelf voorstelt (data van Troy Hunt downloaden / wc -l / etc.), ik toon aan dat je er compleet 100% naast zit.
..
99,999% van de files zijn tussen de 43kb en 52kb

Ik dacht: ik sla deze over wegens complete onzin, maar na je laatste opmerkingen toch te mooi om niet op te reageren...

Tellen (wc -l) levert een aantal op. De eenheid van tellen is niet kb (je bedoelt overigens kB, maar dat terzijde). Jij hebt dus niet geteld, maar zo te zien de bestandsgroottes genomen. Die komen goed overeen. Geen verassing, aangezien het formaat van PwndPassword bestaat uit <SHA-1[5:]>:<count>. Het lijkt er dus dat het aantal digits van de count jouw resultaten vervuilen.

Als je wel gedaan had wat je zegt gedaan te hebben, dan zou je tot een heel andere - en juiste - conclusie komen. Als je een wc -l op alle prefixes doet, dan zie je hoeveel de suffixes (alle truncated hashes voor een prefix) voorkomen. Die zouden bij uniforme verdeling heel sterk overeen moeten komen. En dat is dus niet het geval, omdat het aantal inputs relatief laag is, waardoor niet goed uitgemiddeld wordt. Simpele methode: check variatie tussen de extremen. Bepaal dus het aantal hashes voor iedere prefix-file (wc -l), sorteer die op aantal (sort -n) en pak de eerste en laatste. Laat de uitkomst weten, ik ben benieuwd! Spoiler: hey, dat is het helemaal niet zo unfiform!

Je hebt dit overduidelijk niet zelf getest maar gewoon verzonnen.

ROFLOL, wat een aannames allemaal zeg

[Reactie gewijzigd door banaj op 29 mei 2025 19:13]

[banaj]

Hier is het begin van de hash van een wachtwoord van 8 karakters: e5a5e
Als jij een lijst kan vinden van 'logische' wachtwoorden waar die van mij ook in staat, dan kan ik je misschien wel serieus nemen, succes.

Dat is altijd leuk! Het scenario is wat ik initieel beschreef, dus je wachtwoordhash is bekend bij PwndPasswords. Ik gebruik een publieke dataset van gekraakte hashes (Hashmob, zodat iedereen dit na kan spelen) versus een download van alle SHA-1-hashes van PwnPasswords van 29 mei.

Op basis van bovenstaande is jouw hash met prefix e5a5e met 100% zekerheid gevonden. Zie de lijst hieronder met het wachtwoord erachter. Zoeken is prima in een paar minuten te doen op een oude laptop. De oorzaak is zoals gezegd omdat je met de query (de prefix) heel veel entropie lekt, in de context van de zwakke implementatie van PwndPasswords. Dat is: de totale key space is ongeveer 2^30 bits (~1297M SHA-1's), en niet 2^160/2^140 bits waar Troy Hunt en jij mee rekenen.

Als je hash een van deze is, dan is het wachtwoord nog niet gekraakt in de publieke set. Je kunt het wachtwoord in het geval van jouw hash dan alsnog kraken in een aantal uren met een goede GPU. In alle andere gevallen is hash + wachtwoord onderstaand te vinden:

e5a5e00aa0931d2aa0f0821ddf27a755e65d3bb3:KarGi0li
e5a5e029c85e7551a893083e3a472d5baea77d52:tidusx13
e5a5e089436dd41c1c6c295ede77411117110e7c:lljj1023
e5a5e08986b55678be26b9382a2a14aeaa236b21:Gil42556
e5a5e09e88cef06ad754b6f05d7ea093414c42f6:zoqovese
e5a5e0a69a8c7ed2df12619d06165ff93a1ad132:29hrdgps
e5a5e0b976be9506d6672705478cfe8f697d1c64:VANDA196
e5a5e0c129c257e646c19677349e92a78a72a968:06317282
e5a5e0df22b77ca03e0aae77f61218db390b4b0e:arakan21
e5a5e0ed6bea483198e37da915c3d78a1cc9061f:t0r09256
e5a5e11df0360e1422e5604315e4e7356362c068:33846735
e5a5e139ed43f2c0012738de77cbb1da5dbc74ca:37221496
e5a5e1446b6f8275b9de2e6b277e998d0c9e19ad:fh071102
e5a5e14dc85490c90f5b3d0cd6b765339b36933a:josh2joe
e5a5e1699c97eb6b7b54ba6598671dfe441420af:12fAHIM,
e5a5e171bdd005e4cb1b96ce94c9235cbcd93b81:2adidoxl
e5a5e187804e717bf6bf82cb1aa4f2c1e61714c7:xapesyzo
e5a5e1906ffefa238b3248cd3d36ebc721d7ef31:velga122
e5a5e199f9ecfcf4f150ae205eb0378939b1ff9c:garunja!
e5a5e1b4d82d57598eadaba0a599b5601a190df9:bj4t9chn
e5a5e1bbec676fe225c338170935ac4438915b1b:akn@1995
e5a5e1c78cf340255c97e591c9c222dd5f02a6f1:team3d23
e5a5e1c999e3681729381131ac370413d41a3d7f:стенстен
e5a5e1d8dd55799d31608c23d50c355cf8720dc8:aipini84
e5a5e1dd207c3d4b2cbeab62fda5eb1d12300f57:Xiqevu+6
e5a5e1ddc537645aa1ba223d7033c64150764f61:Fuxo-898
e5a5e1e6937f76c81188e2cc0b5a47ebf8798ff4:32265405
e5a5e1e7e7db5978942a581cbe638304e62574f1:3jt027jp
e5a5e1eb18e4d1eed64eaf85987f8f143eb271bb:ygedocyr
e5a5e1f54ce395a12f9947046d8df26c7f3afb3a:loya2523
e5a5e205e79aa2f2ac4472caa6f4cb91f7f65066:3302aced
e5a5e20d0292531515821798f825330bea59b96e:59226rip
e5a5e21cf5ee3f09d27fd6aee4c84957aa020bde:sksmstng
e5a5e21dcbe487cbb256b5d6bd64bc53554e4889:raftcolt
e5a5e237a8729cb34b8e2d27da8323210345dd29:wunejexe
e5a5e24f1fa204ca910387a0dd035d2d15d1c7ee:97598251
e5a5e26fda91c23727679d3a1332060ddfb02e17:CalliC43
e5a5e2731fca1449838830267edb491d45e2b3cb:yfqmqbvx
e5a5e2a3ec1b837d35a40344fd88605db67ee985:qj724753
e5a5e2bdab76ff305cb9dfd79243207944725cbe:xboxWin2
e5a5e2c51dd69b41d7edefd69dd471a682bccf7b:vovolyqa
e5a5e2f7bad54b2955d7ce7ffb00fbbea0afd7ca:ljvs48gl
e5a5e2fc91a678184e7f89f358457a51acb85521:macluvin
e5a5e2ff141cfbf23e10d92dba5ba4918f790feb:86283940
e5a5e3051f153b1c895acdb6bc76d2ccd8d8fcd6:Liver011
e5a5e307bedf9e6f0488432cad67663c2227616a:STiky23C
e5a5e348a07389a2c3226a48fd1ccbcf38501e5a:jofydixi
e5a5e3554bd04c38604167d0f65e0d37201f1c23:pimycesy
e5a5e396fda25d3fb84ddb7d4f584ceb0cc24868:mmm03bop
e5a5e3993979fbb0df16ed5a574eb7fb5c19319c:53377347
e5a5e39f0f613aa8e126d7f054bcc848fa12825f:SMKKHAYU
e5a5e3b654c0dfe1d0f53baccbc2fc84ffaae92a:joel5841
e5a5e3cc8e444b1e06e829a7a7574055677f56c2:miami095
e5a5e3d50e50fb393edbc5aa9042b224406b2be1:43531837
e5a5e3f0ca5d8bfc52db93af5fb7316a2f19fd50:sound.it
e5a5e401e5b14215acbbd8790c269778b23716e5:mo-dbahn
e5a5e4222cd6ad4eb904e79cf4c5bf9caed924bb:40110095
e5a5e43b9999041682416a49f00afe537824f716:jqmahsih
e5a5e4695262240c3f1502d192d049197c15f68e:syjejcz7
e5a5e47ea887450df8d83649630fbf0e26bc339b:huzuna64
e5a5e489a6a4e9daa779dfcd888aedb08247fbd6:L6AvjWVX
e5a5e48d2850277a3d6dc3b42a871dfd17bc5f81:sammayla
e5a5e496329b0e324fd35b385947fb88b6a256bd:92871157
e5a5e498335b7a047980187b6a1ce907f2dd591a:198712pt
e5a5e49a94f4baf33ffc169c6af6abd0ee604d2a:Nimanavi
e5a5e4a07379a66a083a9d588fea683f153a09ef:cypozoko
e5a5e4d4e779aba0eb56f45f83a6f434047313c4:wfmvetif
e5a5e4d5b0369ea7993f43a802003490f7ad1894:woyou138
e5a5e4e01f440be04aa63714f0f34657f73888e2:xNyXcjvs
e5a5e4f29f8baa5fa518dc2c470bc9ed3746b672:95/95/73
e5a5e5035980034e31923823b999757d36010288:4qNhDKmZ
e5a5e516a20d3611187c84c9a8311667bd90bad0:udysosuk
e5a5e52fc869224c04742ccc2e76819d9af6faeb:angjac22
e5a5e53fd2f8b526f1c28747b38762800634cf2e:Segway15
e5a5e54d4d5213596b9ab359fd075568c1f1eee9:xvk49zfn
e5a5e55857b0a505c59629fb7670d9888d439b77:Mq6s4jTw
e5a5e55f3dc2097c9eaee9e55e5359483a223a28:punowela
e5a5e56f90ae9871e68a313ab9885f3de0d7c540:2Cr8bmwE
e5a5e580dc26fcc0a49fe9d924d94f005323009f:56156002
e5a5e5819ece6da39b5e048de4f0fa2921205dfb:0beb5e16
e5a5e587571f8a7a792cb20ca3f0e9999f3f9ad7:Djd12ljs
e5a5e59f5ef03ef99b761dac0b12caafda6c0581:0s/sadia
e5a5e5b1e94f6593a252c214792445d1dcd8a446:1014409s
e5a5e5c6aeb31b2cb3374aa825767471ad47854e:hahoyjfg
e5a5e5e74a4e7f063c59b258b673c17cb36914af:vpqwkjta
e5a5e5edae9dbb10ba5fd1fa5b03117518956b81:scot7365
e5a5e5eff06f2d1915e5aa5e6164b3746dfff1d6:1262856a
e5a5e5f9dad7ae3eb1fc6f478ad6b2b8d1a032ce:vix5sus1
e5a5e622bba318bfdc7e735f51ee1d74f402f36d:QvJg9PWq
e5a5e623b26870b827abb250f7cd76c48b4241ec:Bostin66
e5a5e6343ba40c2d9beb105608431aaa0eb2a075:Boys0015
e5a5e65f50a79e38ed8dfebb4b2721ddbae5873f:xanajese
e5a5e663184d58355319eff902fd75d89f4f1b84:based209
e5a5e669aa4b7e1b445ef84be002c22edf57c931:mx223671
e5a5e676b8d887b6da518785ddabae4186016a6d:byfezime
e5a5e68376a9f3910c2f326ff8131f0a6ae02ad0:pekita82
e5a5e68e5997104a6be2e5e09d4b7996369fe265:MobTurok
e5a5e6af0fb73be8c3712bea992f8cb52752c96f:dbklwhf9
e5a5e6cc7080f3026f382368a218c738c3631ca1:03082015
e5a5e6e20999eb9f271d2001903ac8fd120cc4ac:5837861w
e5a5e6edfb2114cf3036bbd4e21ac8e8df8d338a:timuwemu
e5a5e6ee2fa29a26c3a787ddec8b97116d92b38a:vasubume
e5a5e71a9b5a2c13507fc00ba58b0e6be3161805:tizasiqo
e5a5e7263dead3c7397f6b16440ae712c152809b:29028574
e5a5e72d96e5be543136c688acce1fc15843d72c:lybyfibe
e5a5e74436e334d4c66d6931ba71719de49c2a7b:68332015
e5a5e745828cf8a47bc7b3e37e18016a9fcc5e41:rbnmjj43
e5a5e7459784f967cf2118fd394a3e7760b0e186:petatuhe
e5a5e745b9dc9d917d9fe584d71d81816828dacc:modernss
e5a5e747704c89508571da45ea8c66bf5e70fecf:MUPU63eB
e5a5e76c6bc22cbdcd4a9ad1e7cece1da0e9ef6a:goblin94
e5a5e771316077d709c7dd9eadaad6608f3c2f65:copas247
e5a5e77302b29e1d4a5cdb6c36838bf21f7584d7:binimo10
e5a5e7738ef0a000029f317e62333a9c0146b3f3:l@@o31lk
e5a5e78c355c397a2011443d26447de3c8a04f41:xukokyfy
e5a5e7ac58b70e5614ec9beb0e7f606984d46a09:lujagibe
e5a5e7c4190d3c9150d319fa1fb09e0b827136d5:qazozowu
e5a5e7ca0b4dc1137c434f2cce45c6f884736bb6:okulumve
e5a5e7cc107da096fd96ee939853d4e1e44488ce:biya1625
e5a5e7ea35ac03be15838cd45dafdc5ad2ad8caa:Nirom16@
e5a5e8218e89f7e2756d842f6f2740283f7d4e9c:Fluorek1
e5a5e82253b7fb5b5771b26ec35e6ffa0bc315d5:25205586
e5a5e82531b635e7a222fa04aaa34290944aee75:bzzhujun
e5a5e82f088cdc0c46f8ca0f709ad477fcc5804a:Sanjiix3
e5a5e83630caff58d2584a2c425c2f6c04f13480:Vilasrao
e5a5e842f83bb32edc0ddf6c00b223134859d929:woxabewe
e5a5e8470e643f8e87059fc3061c4d36a474522b:bugnab1t
e5a5e864686c04c2be8baf6b2ff20e1888d63379:20362056
e5a5e89002cfe6bfae9b67d1b4a7849d4a5cbbcd:jiyMm719
e5a5e8943993426600685eb49cb7211a951b099a:bwjona61
e5a5e89bf43ba6d129e3d3c04818b68423f836ca:K33th345
e5a5e89f4207c373917a61105854df9b8a88941d:bpehepmj
e5a5e8c7ce4c65d8ea8487620313ebfed8ae5ce5:motuvibo
e5a5e8d55d58edfbf7ad1c94ee7718f66611fd85:aUroral8
e5a5e8ec51953482d09c220ba02357bc5e4d9f8d:leBNVZv1
e5a5e8f82222a71597cd0bb9bb1d8a70bafe787f:9D4d2nKG
e5a5e91d3276412390657564ee419a1a0ece04f9:7836l.ru
e5a5e932f258d1fdb4f99a48b82186b1fcd53e2d:naxitude
e5a5e93995e5199c794e60b68c5bff39c52ae920:0lt12345
e5a5e93d80bcca0509cea2929a517ee53b4ff769:peraxify
e5a5e94594cc47db54d34c2c4088155d0dd3e3e1:mugymuki
e5a5e94b095cd77c3b491a68715018575946174f:r1o3m3i4
e5a5e95a0c91e72ef6e3354e0c368beb41807130:herylewo
e5a5e963209616b554fc5dc7745d9ddb4b51b2bd:3fylzb35
e5a5e964009df20b40cdd7fcb533041f1b6cfa5e:zuveqori
e5a5e974cc48fdeaa88dab4feae5a54541957540:34063609
e5a5e988b5e37dba89ce5f88916ae2fec3fd16cf:7bdododo
e5a5e988f008478d2f54fe7833a5585cd9d72514:ai802222
e5a5e98a63c9814af9263179e2675315012fa03f:lisihuja
e5a5e99c6fe0c3f529db1bbbd6054d895ba63242:yzihitup
e5a5e9caba2bf12ca40baa40f99515cd5f100f7d:sbb88888
e5a5e9d67f33c1da93575970961f82622da052da:SeF2pisA
e5a5e9dec83845f8998e6856e0fd23e5ebd3f5e9:kLGgpGGU
e5a5e9fa150b20c4b77812a3609ea2dac1a89e65:Ahad2395
e5a5ea02d4c7d042cae42abacc4a7a1403b5867e:Nabila17
e5a5ea1f071e1e7c864005fe0c401e13d0a0d171:gusesivy
e5a5ea25b13fdb83639a04b04d417f164b059c20:03gibeht
e5a5ea3a9850f1b632ebf7ab7e603ef9adbc9728:dodemumo
e5a5ea3ccad58c3e5e9a44f26d7ebbb4d9f01297:447594aL
e5a5ea3f3048cd3e587c802b8a4ed05ddbc9b735:byiphone
e5a5ea4ef959944ed2c7e567e801e01ccd93838a:molowino
e5a5ea4ffb7a9e2d1290e12db86fc677cb3d9e50:lotusgr8
e5a5ea5ebd79695a12454fc499a21a550a8a5324:nebyhazy
e5a5ea70b814bf5894e21715bd79ebd39f6e7597:casstink
e5a5eaa7f2df4ca8be0356b18e9f456bb46bcebd:GR417QK9
e5a5eacc198d7bc28b3b1fce2edb7c9f43030f40:bypexumi
e5a5eacfe5038701e4b150262dd815061ac3cba7:i3bU5RK5
e5a5ead178909ca5c5376d7c2cdc723ee0fbc554:didotopa
e5a5eb1300fcbbaa3454c7bf99efe946a695f4db:Danma090
e5a5eb15d751c2a8ec8be57adb7d69d65fb4ca13:Abcd1713
e5a5eb19060c225af14cd657e8ea1aff064fdaae:1983RM80
e5a5eb36a09af1f26d52dafe94c34baa47f7fd96:futoruwe
e5a5eb51a287d513119fba23372b9dd224df6bad:nolapifi
e5a5eb6859d5bac168240c4a151745c7a4cadf70:ФИ373385
e5a5eb765b2a4774624e7d520710b6023d9c8a45:voxytymi
e5a5eb97f36c4ad714f27475c4d08fff475de854:8281djff
e5a5eb9a2f6f787533cbefea8d2a490ccfe96e08:91661645
e5a5ebc7a87365cdf8e54b1faaf6b8254244662d:pisuwaqi
e5a5ebd4c53fa02d65ef139877f8b406770d88fc:62242396
e5a5ebe204481fa3fe6e50895f2d3c0de1cc924b:3JaA9wSz
e5a5ec0000e2e098dad046d43223e096dc3e75aa:bofybuge
e5a5ec03546aa130ee4e88926708c4dea8387690:marria06
e5a5ec28b502929874d3861c9223e879e10f59d6:JSas.411
e5a5ec2a684e81aaa4efae72225f05d66da16516:13e2lQlW
e5a5ec494c9f0bf4cbc8d1634cbaa10e6e7f8298:cyxidepy
e5a5ec6dd02d1d9148c4703b6ea44d2567d5bc69:z09SygqF
e5a5ec908d9bfcf7efa2fa88e7e9e0e28cbc4ec4:revy8ssy
e5a5ec951d10dbc3fdbe9532937d8664bd7224b2:0002bapt
e5a5ec9ff78dfb3f2c3a7e68301435042d872e4f:justsat5
e5a5ecb731f4c515faf6b69e70b4f99c4226afd7:Anime088
e5a5ecbf64d8e056f2c4fd138d663b555a0f56af:lolpavve
e5a5ecce41c1201fbe3bd996e0f6093c584472c2:131smil3
e5a5ecd60989eb3a5bfada44b8dd52105e198e07:perec888
e5a5ecd8f94e5eb8b5df69d81c3b291ea9851697:honey2.0
e5a5ece18871d11d3f1726119d36244d59facf7c:123Cok13
e5a5ecef38f91ee524e20f2542c2f7908659f26b:fiwinolu
e5a5ed04882b936670c7f02d9e607eb052beaade:ZjYozdYN
e5a5ed05ca97b95bd31ed0ac4ccb32c18eb7d261:0d315c66
e5a5ed0bb6021ae749a02436a2b413fa36c3a600:tozoxexy
e5a5ed1d8cb12952817884e9b378e1e8b087d3cd:bjeans54
e5a5ed3be342be4003ff2578dd9171297b7b5b74:dezrez69
e5a5ed421be08ca400d644277eef427e835f45b1:snafunow
e5a5ed5309d096d90ed7c74466c5b5e11bb60fda:civiwybo
e5a5ed55a1b772cfd62bbce566aa26fadced5e43:Henrys22
e5a5ed59639dd5aef71f4b62a5aa8e0507287fb1:91x8636f
e5a5ed787b20b0810afd31bcacc4984c4ca218be:b7rym4ej
e5a5ed94aad44d909e0a0170fd74f35ce1cc5994:mm215845
e5a5edb2c25076321e14e59b84be706f1db57cf1:a3511179
e5a5edc56d9057c10ac8a6e17c59dea31f0a11e9:wupaneqy
e5a5edc875f7859cb8a5d6c3aeb987b64bbbd09c:00rotide
e5a5ede369c410e25f6d5cc300fae8096721333a:3s*A*2Ny
e5a5edfbcbd1aa737bbbc3ba2185a33fb6ddedb8:takivoje
e5a5ee008519320248ec3f64bef17482712b0808:PZQzyw19
e5a5ee14b16378b75533297ec8a5aef7c0c55946:ybyzerap
e5a5ee3a053db461bacc85a892ecb45e451ed194:e9cd193c
e5a5ee4b130df559f8d0bb8a82501937797f4d99:fazado31
e5a5ee80cc7f21485e1a93999332be1b29326e05:Rere9895
e5a5eea50992036923a93b6c0383c3c906c9ace2:qizynimy
e5a5eea8259fa5623c7231f08695cc78410ddcc4:zidenyqe
e5a5eead5f7da383592b88c264c2d595a58e2eeb:Pkf26161
e5a5eeb9e6755703b2455117c8938067270e85e0:voqocete
e5a5eec32f0e5cb0ec32e1a1d2f171fb3f209958:arine111
e5a5eecfe18c9b60d7dea19e0e17074700273d58:ndauth01
e5a5eed6282ad6f23210b864508eec1330e5961a:e5yhy5ab
e5a5eef01df1937b2795f35d23e46fa19a090b92:ms_irism
e5a5eef18b60cbc7e906289d3d28016184babcd7:4gw44284
e5a5eef4071732d081daaccb4a7238dfd65a5727:41BZz358
e5a5eefb2487343f362b553138981330c510c1e9:48f459a4
e5a5ef01b767da3f1e8ac5d2e647a58fa2c14acb:omowunmi
e5a5ef0bf2570ce27fec300e71478bbd48a0a0a6:mur26com
e5a5ef0ebe2282e4c564c4be1fba057a5b9b33ca:ketotemo
e5a5ef26d757732105510cf110145875fc265b81:sojawaqy
e5a5ef32b4823b1f7bb31a06f0ace6c48a77b8da:gokazace
e5a5ef3a9270404eca1d4f2e8e590fbef4caabd6:8468757l
e5a5ef45d2571a7372fcfa9ea66f3178ff656c2e:bujydigo
e5a5ef68a61531ca80d0d4dcf12a2b5966ac7a58:supalowa
e5a5ef69fc7244b4ebe83569d3643b77f55c193b:rutavune
e5a5ef7bb541a4f8409591a0f8612192fe6e00ae:moduzoxa
e5a5efb7e0528df0ac834fb0009cd9e33808f3a5:cynour87
e5a5efd3c19c9752e96c04f0c5641904d722fa28:W-c0-i-0
e5a5efd6d50c048a70b9ad4413f4a329bb11e7c4:nycilupu
e5a5efe6b0e1d82e265110a18a6e33f714e012df:whly4321
e5a5efef64b598188137d1bbe1b488f3ae96568a:079f6021
e5a5eff739a1da750ae9c793f5270942fff76054:hehetave

[Reactie gewijzigd door banaj op 30 mei 2025 14:24]

[svane]

Weet je nog toen je dit zei?

Beide kunnen tegelijkertijd waar zijn. Echter.

Als je geen antwoord krijgt dan lek je 6 nibbles = 24 bits. De theorie die jij daarna post is... theoretisch. Er blijven 160 (SHA-1) - 24 = 136 bits over = 2^136.......... (heel betoog)

We hebben 't al een week over de situatie dat je geen antwoord krijgt. Dus nee, mijn wachtwoord staat hier uiteraard niet tussen.

Je rekent ook al de hele tijd met 2^136. Dat is niet de grote van de HIBP dataset, die is veel veel veel kleiner. Je verplaatst nu de doelpalen door ineens te zeggen dat mijn wachtwoord in de HIBP set zit..... Leuk geprobeerd, maar slaat nergens op natuurlijk. 5 bytes entropie lekken van een wachtwoord dat in zijn geheel al gelekt is voegt überhaupt weinig toe.

[banaj]

5 bytes entropie lekken van een wachtwoord dat in zijn geheel al gelekt is voegt überhaupt weinig toe.

Dus Troy Hunt kan PwndPasswords uitzetten wat jou betreft begrijp ik Want als je al weet dat je wachtwoord wel gelekt is, waarom zou je het dan checken, "voegt überhaupt weinig toe". En als je al weet dat je wachtwoord niet gelekt is, waarom zou je de dienst dan gebruiken? En als je niets weet, dan is het niet handig om de dienst te gebruiken, want dan loop je het risico op de eerste categorie. Dat is nogal een draai t.o.v. onderstaande quote dat niemand iets met de informatie kan!

We hebben 't al een week over de situatie dat je geen antwoord krijgt.

Huh? De dicussie begon met dat ik zeg dat je heel veel entropie lekt als je antwoord krijgt van PwndPasswords. Met als jouw reactie::

Je 'lekt' dus absoluut niet heel veel entropie. Je lekt juist zo weinig dat niemand ter wereld iets met deze informatie kan, niet eens een beetje.

Wat mij betreft hebben we 't over analyse van een probleem. Met een berekening die hetzelfde is bij wel en niet een antwoord krijgen. Voor de liefhebbers staat de samenvatting hier.

Ik denk te begrijpen dat je het inmiddels met me eens bent dat je heel veel entropie lekt als je wachtwoord bekend is. Als je wachtwoord niet bekend is, dan is de berekening zoals genoemd identiek, met meer bitjes als invoer en als uitkomst daardoor een groter getal. Daardoor andere benodigdheden om de keyspace uitputtend door te rekenen bij gangbaar wachtwoordgebruik. Nog steeds te doen. Dus niet: "niemand ter wereld iets met deze informatie kan, niet eens een beetje". Ik ben benieuwd of je dat dan inmiddels ook inziet, of dat je de wiskunde nog steeds ontkent dan wel slechts selectief accepteert.

[Reactie gewijzigd door banaj op 30 mei 2025 13:30]

[svane]

Dus Troy Hunt kan PwndPasswords uitzetten wat jou betreft begrijp ik

Diensten als password managers kunnen PwndPasswords gebruiken om te kijken of je wachtwoorden zijn gelekt. Die kunnen dan een alert geven dat je zo snel mogelijk dat wachtwoord moet veranderen. Kan je niet inzien dat dat handig kan zijn?
1Password gebruikt dit onder andere omdat zij, net als iedereen met verstand van security, weten dat dit gewoon veilig kan.
Wat dacht je van 't master-wachtwoord van je password manager... Die moet je kunnen onthouden, dus wel fijn om te weten dat die niet ergens gelekt is.
Zelfde geldt voor mensen zonder password manager, die kunnen even kijken of hun zelf-verzonnen wachtwoorden niet al ergens bekend zijn.

En als je niets weet, dan is het niet handig om de dienst te gebruiken, want dan loop je het risico op de eerste categorie.

Dat risico loop je dus absoluut niet.........

Ik ben benieuwd of je dat dan inmiddels ook inziet, of dat je de wiskunde nog steeds ontkent dan wel slechts selectief accepteert.

Absoluut niet. Er is 1 iemand die hier continu wiskunde negeert, en dat ben jij. Als jij nog steeds uit MILJARDEN wachtwoorden moet gaan zoeken welke van mij is dan heb je daar absoluut niks aan. Net zoals je er ook niks aan hebt als ik jou vertel dat er een 9 in mijn pincode zit. Je zoekruimte wordt ietsje kleiner, maar je hebt er niks aan.
Waarom heb je nog steeds niet mijn wachtwoord gevonden? Vraag jezelf dat nou eens af....

[svane]

Ter aanvulling:

Die filter je op de 6 nibble prefix. Dan blijven er een paar honderd mogelijke ASCII-wachtwoorden over.

Dit is de aanname waar je hele verhaal op misloopt. Het zijn er niet 'een paar honderd'. Misschien is dat een educated guess, maar in werkelijkheid zijn het er een paar miljard. En ja, dat zijn allemaal ASCII wachtwoorden van 8 characters.

Hier is een lijst van 3.200 wachtwoorden van 8 characters (met keuze uit 95 characters) waarvan de hash allemaal begint met d6eae. Wil je er meer zien? Dat kan, er zijn er namelijk een paar miljard van. Dat valt niet meer onder de noemer 'een paar honderd'.

Edit: Mocht je 't nog simpeler willen: hier zijn een paar honderd wachtwoorden die bestaan uit een engels woord met een (kort) getal erachter. Allemaal dezelfde prefix, waar je dus absoluut niks aan hebt

[Reactie gewijzigd door svane op 26 mei 2025 11:43]

[banaj]

Hier is een lijst van 3.200 wachtwoorden van 8 characters (met keuze uit 95 characters) waarvan de hash allemaal begint met d6eae. Wil je er meer zien? Dat kan, er zijn er namelijk een paar miljard van. Dat valt niet meer onder de noemer 'een paar honderd'.

Hoeveel simpel te herkennen als een wachtwoord van een normale gebruiker? Ik zie er ongeveer 0

Edit: Mocht je 't nog simpeler willen: hier zijn een paar honderd wachtwoorden die bestaan uit een engels woord met een (kort) getal erachter. Allemaal dezelfde prefix, waar je dus absoluut niks aan hebt

Hey een paar honderd! Waar heb ik dat eerder gehoord?

En dit zijn niet eens alleen wachtwoorden van <=8, dit is een veel grotere scope.

Oow en deze reactie betreft de educated guess (die natuurlijk ernaast kan zitten, het blijft een guess). Kom s.v.p. ook nog even terug op 2^140 die niet effectief gebruikt wordt, maar in mijn voorbeeld voor slechts ongeveer 2^53. Dat is waar de discussie over begon. Hoe kan jij 2^140 entropie aan uitvoer krijgen als jij er 2^53 instopt? Ieder input genereert 154.742.504.910.672.534.362.390.528 outputs? Ik ben benieuwd!

[Reactie gewijzigd door banaj op 28 mei 2025 01:24]

[mobrockers]

Volgens mij mis jij het stukje informatie dat de sha1 hash een fixed length heeft, de lengte is niet afhankelijk van de lengte van je wachtwoord en daarmee klopt je berekening niet.

[banaj]

Leg uit.

[Niosus]

Je weet alleen in welke beperkte set die zit, als die er ook daadwerkelijk in zit. En dat betekent ook dat je wachtwoord waarschijnlijk bij de 99% van de gekraakte wachtwoorden zit. In dat geval is je wachtwoord dus absoluut al niet veilig meer, zeker als je in je achterhoofd houdt dat er dan ergens op het internet ook een lijst rondzweeft waar dat wachtwoord ook gewoon naast je email adres staat. Een lijst die Troy heeft, want zo kan hij waarschuwingen uitsturen. Er verandert dus niets als je wachtwoord al op de lijst staat.

Langs de andere kant, als je wachtwoord nog niet in de database zit: dan krijgt Troy 5 random tekens binnen. Puur vanwege het pigeon-hole principe kan je daar eigenlijk niets mee. Er zijn veel meer wachtwoorden dan er manieren zijn om 5 tekens achter elkaar te zetten. Het is triviaal om een wachtwoord te genereren waarbij de eerste 5 tekens van de SHA-1 hash overeen komen met wat je binnen krijgt. Maar als je geen toegang hebt tot de rest van de hash is de kans astronomisch klein dat die toevallig ook daarmee overeen komen. Je kan dus wel een absurde stapel kandidaten gaan genereren, maar je hebt niets om ze aan af te toetsen. En ook al zou hij weten voor welk email adres op welke website het zou gaan, het zijn te veel opties om na te gaan rechtstreeks op de server.

Ik zie niet hoe je dit zou misbruiken om effectief op een account binnen te geraken. Ofwel heeft hij al alles wat hij nodig heeft van andere bronnen, ofwel kan hij een brute force attack proberen te doen zonder einddoel. Iets wat elke goed-geconfigureerde server tegenhoudt met rate limiting.

Je kan heel ver gaan zoeken naar manieren dat hij dat stiekem kan misbruiken. Maar als hij echt van kwade wil is steekt hij gewoon iets van javascript bij op de website die het hele wachtwoord in plain tekst tot op de server krijgt. Dat zal uiteindelijk wel naar boven komen, maar tot die tijd hoeft hij dan gewoon geen moeite te doen met een zware brute force aanval op flarden van hashes.

[Reactie gewijzigd door Niosus op 21 mei 2025 14:11]

[banaj]

als je wachtwoord nog niet in de database zit: dan krijgt Troy 5 random tekens binnen. Puur vanwege het pigeon-hole principe kan je daar eigenlijk niets mee. [..] En ook al zou hij weten voor welk email adres op welke website het zou gaan, het zijn te veel opties om na te gaan rechtstreeks op de server.

Onjuist, zie mijn reactie op het bericht van svane.

Je kan heel ver gaan zoeken naar manieren dat hij dat stiekem kan misbruiken

Ik zeg niet dat Troy Hunt evil is. Ik zeg dat het protocol dat gebruikt niet zaligmakend is en dat er aantoonbare risico's zijn met gebruik ervan. Juist tof dat jij deze diensten aanbiedt!

[Niosus]

Lees dan eens de reactie van svane daar op. Ik was begonnen met iets heel gelijkaardig uit te typen.

Jij bent aan het rekenen met de key space die de browser net niet meestuurt. Die 140 bits zijn niet informatie die je beschikbaar hebt op de server. Je krijgt maar 20 bits binnen. Je kan dus opdelen in ~ een miljoen categorieën, wat miljarden keren minder is dan er mogelijke wachtwoorden zijn, zelfs met jouw constraints (ik genereer altijd 16 tekens of langer, veel succes). En die lijst van kandidaten kan je onmogelijk gaan testen buiten rechtstreeks op een server, wat compleet onpraktisch is.

Je wiskunde klopt dus gewoon niet. Je berekening klopt als je bijna 90% van de hash doorstuurt. Ja, dan kan je gaan brute forceren en gaan er niet veel opties meer overblijven. Maar dat gebeurt niet. Je stuurt ongeveer 10% door, dus je mist gewoon het overgrote deel van de informatie.

[banaj]

Check als je 't leuk vindt de opvolging. De essentie is:

• Optie 1: je wachtwoord is bekend bij PwnPassword. Dit zijn ~1290M SHA-1's =ongeveer 2^30 opties. De berekeningen van Troy Hunt kloppen alleen als er 2^140+ opties zijn. Die zijn er niet. Je kunt niet 2^140 aan outputs genereren op basis van 2^30 aan inputs. Om 2^30 door te rekenen heb je aan een oude PC voldoende.

In de andere gevallen: je wachtwoord is niet bekend bij PwnPassword. Het aantal opties is afhankelijk van de lengte van het wachtwoord en de compositie van de gebruikte karakterset: krarakterset^lengte.

• Optie 2a: gangbaar wachtwoord. In mijn voorbeeld van ongeveer alles op je toetsenbord en 8 lang kom je op 95^8 = ongeveer 2^53.Om 2^53 door te rekenen heb je een aardige consumenten-GPU en uren tot dagen nodig om alle mogelijke wachtwoorden uitputtend uit te rekenen.
• Optie 2b: moeilijk wachtwoord. Extereem voorbeeld: 32 lang willekeurig gegenereerd. Complexiteit wordt nu te groot om door te rekenen.

Je stuurt als gebruiker 20 bits door. Daarmee lek je, door de verschillende keyspaces:

• Optie 1: heel veel entropie, met oude CPU uitputtend uit te rekenen.
• Optie 2a: veel entropie, met mooie GPU uitputtend uit te rekenen.
• Optie 2b: weinig entropie, niet uit te rekenen.

Als je fouten ziet in de berekeingen: laat het weten, met correcties. Dank!

[Reactie gewijzigd door banaj op 30 mei 2025 12:41]

[svane]

Optie 1, is irrelevant. Als je wachtwoord in de lijst voorkomt dan is je wachtwoord al bekend bij hackers. Wederom: je kan niet iets lekken wat al gelekt is.

Bij opties 2:

Stap 1: je zet je GPU lekker aan het werk, en je gaat alle 95^8 combinaties doorrekenen.
stap 2: Je slaat alleen de wachtwoorden/hashes op met de juiste prefix
stap 3: ???

Je hebt nu ongeveer 6,6 MILJARD de wachtwoorden + hashes. Wat is nu je plan? Letterlijk: wat is de volgende stap?
Het wachtwoord wat je zoekt zit niet in een bekend lek / wachtwoordenlijst (want anders zou HIBP een hit opleveren). Ga je handmatig die lijst door om te kijken wat het meeste 'lijkt' op een wachtwoord? Ga je 6 miljard keer proberen in te loggen op een dienst? Wat ga je in hemelsnaam doen om uit 6,6 miljard wachtwoorden de juiste te vinden?

Antwoord: helemaal niks. Mijn uitdaging staat nog steeds, vind mijn wachtwoord. gegarandeerd dat het je niet lukt. (En nee, alle 6 miljard wachtwoorden teruggeven telt niet)

[banaj]

De laatste reactie van mijn kant. Ik hoop wat dingen voor jou (en anderen) te verduidelijken. Er zijn twee gescheiden zaken: wat ik noem de wiskunde, en de toepasbaarheid van de aanval.

• Wiskunde. 't Is bovenstaand samengevat in optie 1, 2a en 2b. Initeel besteed jij dit: "Je lekt juist zo weinig dat niemand ter wereld iets met deze informatie kan, niet eens een beetje". Inmiddels is het kwartje denk ik gevallen want ik hoor je hier niet meer over, en je hebt nu een ander stokpaardje.
• Toepasbaarheid. Wat ik laat zien is dat, op basis van optie 1, er een aanval mogelijk is als je een query uitvoert, en het antwoord jouw hash bevat. NB: het maakt niet uit hoe lang je wachtwoord in dit geval is. De wiskunde van Hunt klopt in dit scenario dus niet, je lekt heel veel entropie, een aanvaller met kennis van de query kan een uitputtende lijst maken, met een resultaat dat goed hanteerbaar is voor succesvolle aanvallen. Een voorbeeld is elders in dit draadje te vinden. Ik denk dat veel mede-Tweakers zich dit niet realiseren, vandaar ooit mijn eerste reactie op dit onderwerp.
  
  Jouw nieuwe stokpaardje is dat ik jouw wachtwoord van lengte 8 dat niet in PwndPasswords staat moet achterhalen (optie 2b). Ik vind dit niet interessant omdat ik nooit beweerd heb dat ik dat kan. Het enige dat ik gezegd heb is: "zelfs in het scenario dat ik niet noemde lek je dus genoeg entropie om een aanval mogelijk te maken", doelende op dat je de keyspace van alle wachtwoorden t/m 8 prima en volledig door kunt rekenen met consumentenhardware.

Dan, als antwoord op jouw vragen:

stap 3: ???

Stap 3: filteren en combineren.

Zoals eerder genoemd lek je bij optie 2b nog steeds relatief veel entropie. Daarmee kun je ten minste indirecte aanvallen uitvoeren. Concreet voorbeeld, zoals eerder gelinkt, zie dit onderzoek. Het meermaals lekken (meerdere queries) van entropie zorgt ervoor dat je wachtwoorden prima kunt achterhalen. Het betreft een... Password Manager! Je weet wel, van mensen die "weten dat dit gewoon veilig kan"

Net zoals je er ook niks aan hebt als ik jou vertel dat er een 9 in mijn pincode zit. Je zoekruimte wordt ietsje kleiner, maar je hebt er niks aan.

Ik hoop niet dat jij verantwoordelijk bent of wordt voor wiskundig of cryptografisch onderzoek. Daar is men soms maanden, jaren bezig om 1 of een paar bitjes van de keyspace af te schaven, ook als daar (nog) geen toepassing voor. Als jij geen toepassing ziet betekent dat niet dat het niet nuttig is of niet bestaat.

Bedankt voor het lachen!

[svane]

Inmiddels is het kwartje denk ik gevallen want ik hoor je hier niet meer over, en je hebt nu een ander stokpaardje.

In geval 2a/2b, waar ik het al de godganse tijd over heb, lek je nog steeds helemaal niks wat bruikbaar is. Daar hoor je mij wel degelijk nog steeds over, maar je begrijpend lezen lijkt nog ergens te zijn blijven hangen.
In geval 1 lek je ook niks: want je wachtwoord is al bekend. Hoe moeilijk is dat te begrijpen?

Hou alsjeblieft op over geval 1. Je lijkt de enige te zijn ter wereld die niet begrijpt dat als de website letterlijk zegt:

Oh no — pwned!
This password has been seen 8,178 times before in data breaches!

This password has previously appeared in a data breach and should never be used. If you've ever used it anywhere before, change it immediately!

Dat je dan niet je wachtwoord moet veranderen... Als jouw grootste probleem is dat één van de meest bekende security researchers mogelijk, misschien, met heel veel moeite, kan inbreken op jouw account, dan leeft je niet in de normale werkelijkheid. Hoe werkt die logica? "Oeh, hackers hebben mijn volledige wachtwoord al, maar een paar bytes van m'n hash lekken, DAT is pas een probleem". Zie je écht niet in hoe dom dat klinkt?

Concreet voorbeeld, zoals eerder gelinkt, zie dit onderzoek.

Dat heeft echt compleet niks hiermee te maken. In dit onderzoek 'lekt' de password manager ongelofelijk veel meer informatie. Dat je dit überhaupt vergelijkt met normaal gebruik van HIBP laat wel zien dat je er niks van snapt, en ook niet bereid bent om meer te leren.
Snap je écht niet dat niet elke password manager niet even 'goed' is? Kan je niet bevatten dat een klein bedrijfje met +- 3 miljoen in total funding, niet exact dezelfde technische vaardigheden heeft als 1password, wat in 2022 $6.8 miljard waard was. En ja, geen enkele password manager is feilloos, maar zij erkennen hun fouten, en passen dingen aan. Gelukkig luisteren zij naar echte experts. Vraag je je niet af waarom er geen enkele serieuze researcher zegt dat HIBP of 1Password op dit moment onveilig is? Ben je echt zo veel slimmer dan de rest van de wereld?

zelfs in het scenario dat ik niet noemde lek je dus genoeg entropie om een aanval mogelijk te maken

Dat is dus niet waar. Die 'aanval' heeft nooit bestaan, bestaat nu niet, en zal nooit bestaan..... Nog nooit heeft iemand dit voor elkaar gekregen, jij niet, en niemand anders niet. Dat jij dit verzonnen hebt maakt dat nog niet waar. Ik kan ook alle mogelijke pincodes opnoemen, maar dat houdt niet in dat ik met een gevonden pinpas ineens kan gaan pinnen. Kan je dat begrijpen?

Bedankt voor het lachen!

Bedankt voor de bevestiging dat je naast koppig en hardleers, je ook nog eens ontzettend arrogant bent. Oprecht medelijden met de docenten die je, tevergeefs, iets hebben proberen te leren

[Reactie gewijzigd door svane op 30 mei 2025 20:24]

[Chopper_Rob]

Nee, je maakt lokaal een SHA1 hash van je wachtwoord. Vervolgens worden de eerste 5 karakters (van de 40) van de hash verstuurd naar PwndPasswords. Deze stuurt jou vervolgens de volledige lijst met hashes die beginnen met de aangegeven karakters. Je hash wordt vervolgens lokaal gematcht tegen deze lijst om te zien of deze bekend is.
Het enige wat dus wordt verstuurd is een klein deel van de hash waar Troy niks mee kan aangezien deze verre van compleet is.
Knappe jongen als Troy daar jouw wachtwoord uit weet te halen, daarnaast weet ie dan nog niet wie je bent of voor welke dienst je wachtwoord zou moeten zijn.

[weouter]

geweldig

[Ischium]

Dat er geen wachtwoorden bij staan lijkt me meer dan logisch, toch? Dat is het hele punt van hibp, het in kaart brengen van gelekte wachtwoorden, zonder dat er daar weer direct misbruik van gemaakt kan worden.

Anders zou de website de natte droom van elke hacker zijn, de grootste verzameling gelekte logins, e-mailtje invoeren en je krijgt een mooi lijstje met wachtwoorden en welke websites ze bij horen.

[xenn99]

Dat snap ik ook wel hoor, je wil natuurlijk niet dat de site om jou te informeren over lekken wordt gebruikt om die lekken juist uit te buiten.

Misschien zouden ze bijvoorbeeld een of enkele letters kunnen laten zien of bijvoorbeeld een link kunnen sturen naar het betreffende mail adres om de wachtwoorden die gelinkt zijn aan dat adres in te zien.
De wachtwoorden zijn al gelekt dus veilig zijn ze sowieso niet meer.

In het begin probeerde ik zelf de datasets nog wel is binnen te halen om te kijken wat er precies over mij in stond maar inmiddels komt het zo vaak voor dat daar geen beginnen meer aan is.

[banaj]

• De data is al publiek.
• Alle normale bedrijven mogen dit niet toen zonder toestemming.
• Alle boefjes houden zich niet aan de wet en doen dit al.

Je kunt dit dus prima doen. Als je niet tegen hitte kan heb je niets in de keuken te zoeken

[Die_ene_gast]

Ik heb eens in een gelekte db mezelf opgezocht.
Daar vond ik ook alle relevante data die ik nodig had voor een wachtwoord reset

[Waterpater]

Als je Google One hebt laat die wel een deel van je gelekte wachtwoord zien, veel fijner imo

[telenut]

bedoel je dit? https://passwords.google.com/checkup/lite?ep=1&hl=nl
Ik zie nergens wachtwoorden of delen ervan alvast...

[Rixard]

Helaas kan ik HIBP niet echt meer gebruiken sinds een paar jaar. Ik heb een catch-all e-mailadres en als ik me aanmeld bij Tweakers is het zoiets als [e-mail].

Omdat ik nu dik moet betalen voor een domain-search is het voor mij dus niet meer relevant. Ik ga geen 19 dollar (of meer) per maand betalen.

[Reactie gewijzigd door Rixard op 21 mei 2025 13:30]

[Wannial]

Opzich nog wel, als je ineens een influx aan spam ontvangt op een van die catch all adressen kan je nogsteeds los dat specifieke mail adres opzoeken in de database.

granted, dan zwerft het al rond bij spammers, maar is het meer een verificatie.

[Youckle]

Maar wanneer “je bank” je een mailtje stuurt op [e-mail] dan kan je er al van uitgaan dat het e-mailadres gelekt is.

HIBP is daarmee niet meer nodig voor bevestiging. Het was juist praktisch dat je een bericht van HIBP kreeg voordat de spam begon.

[Fido]

En dat lekken van adressen wordt ontkend door betreffende partijen. Maar goed, omdat ze voor maar een partij gebruikt worden kan je ze daarna aanpassen en het originele adres als spamtrap adres gebruiken en daarop blacklisten. En dat werkt erg goed.

[Dlocks]

Spam krijg je niet alleen door een lek. Een spammer gebruikt ook [e-mail].

En kan ook zijn dat een partij niet weet dat er een lek was (en misschien zelfs nog steeds is).

[Fido]

Waar baseer je je stelling op dat spammers woorden en namenlijsten gebruiken? Op mijn catchall mailbox lijkt die bewering onjuist te zijn. Het is ook erg dom als je dat als spammer gaat toepassen. Hierdoor word je enorm beperkt in je bereik, want een hoop 'user unknown' meldingen zal snel tot een blacklisting leiden. Als spammer wil je juist gebruik maken van geverifieerde adressen om een zo groot mogelijk bereik te hebben.
Mogelijk slechts enkel het algemene info@ adres wat ik nergens gebruik, maar daar houdt het echt wel bij op. Spam krijg je mogelijk niet alleen door een lek, maar ook door scraping, als gebeurt dat laatste steeds minder, maar een lek is wel voor 99% de oorzaak. Jouw adres hoeft maar in 1 lek bekend te zijn en je krijgt er spam op binnen.

Het is ook evident dat er partijen zijn die niet weten dat er een lek was of is. Het melden van een lek is helaas ook vaak tegen dovemansoren gericht.

[Reactie gewijzigd door Fido op 22 mei 2025 09:53]

[Thijn41]

Ik kan nog steeds gratis een domain search doen?

You don't currently have an active HIBP subscription for **@**. You can still search domains with up to 10 breached accounts, as well as retrieve full domain search results for any subscription-free breaches. You can purchase a subscription below to query larger domains and use the API to query both domains and individual email addresses.

[b12e]

Ik vermoed dat

You can still search domains with up to 10 breached accounts

het probleem is.

Als je een catch-all gebruikt heb je al snel meer dan 10 "accounts" (e-mailadressen).

Of ik begrijp het verkeerd, dat kan ook.

[Thijn41]

Het zijn 10 "accounts" waarvoor er een breach is. Als je al lang je domein gebruikt kom je daar denk ik ook wel aan (Ik heb er op mijn oude gmail emailadres meer dan 30 bijvoorbeeld). Persoonlijk gebruik ik mijn domein pas een aantal jaar, dus zo veel breaches zijn er niet op geweest.

Je weet nu in ieder geval dat je meer dan 10 gebreached emails hebt, welke dat zijn kom je nu inderdaad niet meer achter zonder (inderdaad veel te veel) te betalen.

[b12e]

Ja, klopt. Zo had ik het begrepen maar slecht uitgelegd.

Echter na een paar jaar heb je er dus inderdaad niet veel meer aan. Mijn domein komt inmiddels voor in 23 breaches, als dat 23 e-mailadressen waren dan kon je dat al niet meer zien.

In mijn geval is het 1 e-mailadres waarvan er voor 12 ook het wachtwoord is gelekt. Gelukkig allemaal unieke wachtwoorden.

[Reactie gewijzigd door b12e op 21 mei 2025 17:18]

[Die_ene_gast]

Een beetje hacker snapt ook wel dat als ze de database van tweakers hebben en dan [e-mail] zien dat er dus een catch al zit op email.com.
Wat voor verdediging is een catch all dan? Want ineens kan je dus op alle combinaties emails ontvangen en weet je niet waar de lek zat.
Alleen bij hackers die niet zulke scriptjes laten lopen zal je pakken.

[Fido]

Een beetje hacker snapt ook wel dat als ze de database van tweakers hebben en dan [e-mail] zien dat er dus een catch al zit op email.com. Alleen bij hackers die niet zulke scriptjes laten lopen zal je pakken.

Denk je nu echt dat hackers dat doen? Een hacker downloadt de database en verkoopt de inhoud. Het versturen van spam is niet zijn business. De mensen die die databases kopen zijn degene die de spam versturen, en dat noem ik oplichters en geen hackers. En denk je nu echt dat ze dat eruit gaan filteren? They don't give a ....

[Die_ene_gast]

Pfft, je snapt ook wel dat ik met hacker degene bedoel die de spam verstuurt..... Sommige mensen reageren echt alleen om redenen als "ik snap wat je bedoelt maaaaaaaar.... ackchyaully"

[roawser]

Probeer eens zoiets als Simplelogin.io, tegenwoordig van Proton. Veel gecontroleerder dan een domme 'catchall'.

[Foechoer]

En Simplelogin is ook gratis self-hosted mogelijk op je eigen domein

[turkeyhakan]

Ik neem aan dat het dezelfde website is? https://haveibeenpwned.com/

[Meg]

Het is inderdaad dezelfde website.

[IndigoX]

Wat een prachtig initiatief is HIBP toch. Die man heeft meer gedaan voor cyber security & awareness dan vele grote bedrijven samen.

[anpat]

Als ik hoor hoeveel data ze daar hebben, vind ik het altijd weer verbazend hoe snel ze 'zien' of jouw mail in hun DB staat...

[TheProst]

Hoe weet HIBP welke emails Pwned zijn? Koopt hij de gestolen data of hoe doet hij dat?

[Meg]

Volgens mij gebeurt dit door datalekken die openbaar gemaakt zijn of worden.

[gpglang]

Vroeguh dreef deze site op "donaties" van bestanden vanuit FBI en andere organisaties. Er werd niet life gezocht "on the darkside". Hoe dat tegenwoordig is, geen idee. Maar om die reden maken wij eigenlijk geen gebruik want het gaat altijd om achterhaalde data (die zeker niet minder waardevol is!). Zal er weer eens naar gaan kijken nu bij 2.0

[Die_ene_gast]

Zat plekken waar men die databases deelt ben ik achter gekomen toen ik jouw vraag deelde.

[nietvoorniets]

Ik vind het nog steeds een mooi initiatief.
Wat ik wel een beetje vervelend vind vind is dat (bijvoorbeeld) de antieke Adobe hack van October 2013 nog steeds getoond wordt.
Ik heb dat wachtwoord al heel lang geleden aangepast.
Ik zou graag een "hoera er zijn geen nieuwe breaches" melding zien.

[Bubbles]

Ah, de Adobe hack. Waar vrij vlot daarna een website is gekomen waar je kruiswoordpuzzels kon invullen met de 1000 meest-voorkomende wachtwoorden uit die hack.

https://zed0.co.uk/crossword/

[Reactie gewijzigd door Bubbles op 21 mei 2025 12:46]

[banaj]

Grappig genoeg zijn de wachtwoorden zelf nog steeds veilig omdat ze niet gehasht maar versleuteld waren, en die sleutel voor zover bekend niet gekraakt is.

De site site die jij noemt is heel creatief bedacht: op basis van de versleutelde wachtwoorden en frequentie van wachtwoorden een vertaaltabel maken. Waarschijnlijk grotendeels correct. Maar uiteindelijk speculatie, tot de sleutel opduikt en we het feitelijk weten...

[Die_ene_gast]

Hoe werkt dat praktisch dan? Stond er nog een server naast waar je dan het user ingevulde ww heenstuurde samen met de versleutelde en die zooi uit de vertaaltabel? En daar kwam dan een ack uit terug?

[banaj]

Wat Adobe deed: een n.a.w. DES-gebaseerde vesleuteling met een geheime sleutel. Zonder sleutel kun je niet terug, maar hetzelfde wachtwoord voor verschillende gebruikers levert wel dezelfde ciphertext op (er is geen 'salt' gebruikt).

Wat de analyse is, ook gebruikt voor de kruiswoord-puzzle: je gaat ciphertexts tellen. Dus welke komt het meest voor, wat is nummer 2 etc. Die koppel je aan de meest gebruikte (plain) wachtwoorden. Grote kans dat minstens veel klopt.

Daarnaast hebben sommige mensen aangegeven wat hun wachtwoord was in de tijd bij Adobe. Met die extra data kun je zelfs vaststellen dat aannames kloppen.

Het is dus een soort 'side channel'-aanval: je kan indirect vaststellen wat de wachtwoorden (waarschijnlijk) waren.

[Die_ene_gast]

Er zijn accounts waarvan ik al langer hetzelfde ww heb denk ik zo