Hoe kan nu een wachtwoord van 400 chars worden gekraakt!?

het wachtwoord is niet gekraakt, maar de onveilige SHA-1 hash, waarvan het al langer bekent was dat het onveilig was,

niet dat het echt uitmaakt, maar hoe zeker weet je niet of je een collision gevonden hebt? kijk een 400 character ww is inderdaad heel erg ongewoon namelijk. dus voortbordurende, dat er een sha-1 reverse hash gevonden is, wil niet automatisch zeggen dat een ww niet meer te gebruiken is. je kunt dat ww net zo goed gebruiken op laatsen waar bijv sha-512 als hash gebruikt wordt met een salt.

Men raadt aan om wachtwoorden in dit soort databases niet meer te gebruiken. Het is te eenvoudig voor iemand de credentials met zo'n lijst te stuffen.

Ik zou zeggen dat een 400 character wachtwoord zo zeldzaam is dat als die op straat ligt, dat het eerste ww is wat weer geprobeerd wordt bij een aanval. Ik zou het dus zeker aanpassen als die van mij was.

Een wachtwoord van 1 persoon op de wereld is voor aanvallers zo ontzettend interessant, dat dit het eerste wordt dat men gaat proberen ? Je weet wel te overdrijven. De kans dat deze persoon deel uit maakt van de user database tijdens een breach is vrij klein.

Stel dat deze gebruiker in Nieuw Zeeland woont; zou een aanvaller dan werkelijk zijn wachtwoord als eerste proberen, wanneer hij bijvoorbeeld een website in Nederland aanvalt ?

Verder maakt het gebruik van 400 karakters de gebruiker niet speciaal interessanter voor aanvallers. Desalniettemin zou ik het wachtwoord ook aanpassen.

SHA-1 is alleen "cryptografisch" gekraakt wat wil zeggen dat het minder veilig is dan waar de ontwerpers vanuit gingen. En in de praktijk geldt dat alleen voor signatures: het blijkt minder moeilijk dan gedacht om een andere input te vinden die dezelfde output oplevert.

Voor wachtwoorden is SHA-1 helemaal niet gekraakt, MD5 trouwens ook niet, net zo min als bijv. SHA256 en SHA512. Het probleem van het gebruik van dit soort hashes voor het bepalen van afgeleiden van wachtwoorden is dat deze hashfuncties erg snel zijn, en wachtwoorden meestal erg kort. Dat maakt brute force aanvallen binnen een beperkt tijdsbestek mogelijk.

Uit https://cynosureprime.blogspot.nl/2017/08/320-million-hashes-exposed.html:
Het verhaal heeft een gigantisch FUD/hoax gehalte, want voor zover ik weet zijn willekeurige wachtwoorden van 16 karakters en langer (zoals bijv. KeePass ze kan genereren) op deze manier niet te kraken. Maar zodra het niet randon meer is, en vooral indien de voorspelbaarheid toeneemt, zoals in:
... dan snap ik hoe je aan "wachtwoorden" van 400 karakters kunt komen.

Gebruik gewoon een wachtwoordmanager met een uniek, random, en bij voorkeur minstens 20 karakters lang wachtwoord. Dan is diefstal van jouw wachtwoord jouw minste zorg, want dat kun je eenvoudig wijzigen - veel van de andere van jou buitgemaakte gegevens meestal niet.

Iedereen mag mijn wachtoord weten "dit is wel verdomde lastig". Succes met het bijboeken van account naam en waar het toegepast is.

Misschien is dat 400 char wachtwoord 400 keer de letter "a", en is 400 de max lengte voor die website/dienst.

Dus gewoon 2 keer dezelfde letter ingedrukt houden bij het aanmaken van een account.

het argument daarbij is dat er nu een dictionary attack gedaan kan worden met een lijst van meer dan 300 miljoen items terwijl de kans goort is dat vele van die ww niet meer gebruikt gaan worden?

In principe zijn alle wachtwoorden net zoals pincodes al bekend. Namelijk het complete bereik van alle mogelijke waardes. Het gaat er om de juiste combinatie account wachtwoord te weten zonder met blokkades of lange wachttijden opgezadeld te worden.
Dat een bekende hash gekraakt wordt zegt nog niet zoveel. Hoe zit het met een extra salt die wegens conversie van een réversible type mag zijn. Dan moet je naast de hash ook die sleutel hebben.

Ik zie nogal eens dat zwakke reversible encryptie als een hash aangeduid wordt.

De conclusie is dat een SHA1 of MD5-hash van een wachtwoord niet meer voldoende beschermt als hij uitlekt.
Ook in combinatie met gebruikelijke salts valt men door de mand.

Voordat je het weet is er zo'n hashkraakmachine of nog beter beschikbaar op internet (misschien Tor?)
waar je je gevonden hashje(s) tegen betaling kan laten omzetten naar het bijbehorende wachtwoord.


Zou er misschien een woordenboek of intelligent algoritme zijn gebruikt?
Verder met 25 Gigahashes per seconde met een intelligent algoritme schiet het lekker op,
en stel dat het wachtwoord bijv. was:

0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
(sorry, er vallen nulletjes buiten het tekstvak, maar in totaal zijn het er 400)

of iets anders met te weinig variatie, dan val je waarschijnlijk snel door de mand.
En anders kan het een collision zijn geweest.

Dat is wat kort door de bocht. Het bstand bestond uit SHA1 hashes zonder salt, en vrijwel volledig afkomstig van passwords die in plaintext beschikbaar waren.
Gezien de enorme succesratio denk ik dat de oorspronkelijke set passwords ergens al verwerkt moet zijn in de dictionary en permutatie rules waarmee gekraakt is.
(Anders verwacht je toch een klein maar zeker percentage onkraakbare passwords van mensen die echt 16..20 random karakters gebruiken )


Een collision kun je wel uitsluiten.

Je hebt duidelijk niet bij bron gekeken. (waar security.nl in hun artikel naar verwijst)

Gegeven is dat meer dan 300 miljoen van de 320 miljoen wachtwoorden alleen met SHA1 waren gehasht.
Blijkbaar is het dus bij meerdere websites in de mode om wachtwoorden alleen te hashen met SHA1 en meer niet.
De kans is dan groot, dat ook heel veel andere websites wachtwoorden aan het hashen zijn met alleen SHA1.

Dus het lijkt me heel terecht wat ik zei, als je bedenkt dat niet ieder lek onmiddelijk wordt ontdekt.
Een (kwaadaardige) hacker tijd heeft dus tijd om een crack station op te zoeken en wat wachtwoorden te laten bepalen.
Het hangt er nog wel vanaf of de bijbehorende loginnaam is meegehackt, of misschien logt men bij sommige websites in met alleen een wachtwoord.
Feit is in ieder geval dat de security ondermijnd is als één deel van de security gecompromiteerd kan worden.
Een goeie security engineer doet daar wat aan.

Omdat "hashhacken" tegenwoordig zo snel kan gaan, kan de hacker het lek misbruiken voordat het is opgemerkt.
Daarom zouden websites niet langer simpele SHA1 hashes van het wachtwoord opslaan, zoals blijkbaar gebeurt.
Als inloggegevens waaronder een wachtwoordhash onvoorzien naar buiten lekken, is het risico op problemen te groot geworden, en dat risico neemt alleen maar verder toe.

PBKDF2 is een tool om het moeilijker te maken, met als invoervariabelen een goeie hash en ongebruikelijke salt die vervolgens meervoudig wordt uitgevoerd. Al was het maar 10 iteraties dan is het al een hele verbetering terwijl het inloggen misschien niet zoveel langer hoeft te duren. Hoe meer iteraties hoe veiliger. (het juiste aantal iteraties is te bepalen door de systeembeheerder aan de hand van tests)

We hebben te weinig informatie op basis waarvan je met zekerheid een collision kan uitsluiten.

Ik heb bij de bron gekeken .
Jij hebt dat ook gedaan suggereer je, maar de allereerste zin niet gelezen of niet gesnapt ?

"Earlier this month (August 2017) Troy Hunt founder of the website Have I been pwned? [0] released over 319 million plaintext passwords [1] compiled from various non-hashed data breaches, in the form of SHA-1 hashes"

Troy Hunt heeft een heleboel gevonden logins in plaintext .
Hij wilde die wel beschikbaar maken op een manier waarop password geweigerd kunnen worden, maar niet als plaintext password, of erger - login/password combinaties.
Dus heeft Troy entries unsalted ge-SHA1'ed en die file(s) beschikbaar gesteld.

De mensen van CynoSure Prime hebben met die ge-SHA1'de bestanden van Troy Hunt gewerkt.
Ze hebben (oa) dus ook een hoop 'vervuiling' in de bronbestanden gevonden , in de vorm van hashes van hashes e.d.

Het is dus geen steekproef waaruit blijkt hoe gehackte sites hashen.

Ik zie zelfs niet of de de password breaches die Troy Hunt heeft de 'bron' data zijn, of lijsten die crackers gemaakt hebben .
Indien het username/plaintext pw lijsten zijn die crackers gemaakt hebben, verklaart dat de enorm hoge vind-score .
De passwords die met de dictionary en rulebase kraakbaar waren voor de crackers van een site, zijn met dezelfde rulebase en dictionary natuurlijk nogmaals te kraken uit een SHA-1 hash ervan.


Deze dataset is dus
1 - geen steekproef van gebruikte hashes op websites
2 - waarschijnlijk geen steekproef van alle soorten passwords, maar van passwords binnen 'bereik' van snelle hashers .

Jammer genoeg is er nog niet zo veel gezegd over de soorten passwords die binnen bereik van de dictionary en permutatie rules vielen .

(uit de blog van CynoSure staat één voorbeeld van een langere zin :
'donothackusoryouwilldieamostpainfuldeath445645thispasswordneverstopsandneverwillbecauseweusesxipperftpmighthaveaproblemwithitthough55545454' )

Wel een tikje beangstigend dat dit ook nog bereikbaar is. De distributie van lengtes en casing is wel wat je kunt verwachten.


Een tragere hash is beslist een goed advies, maar zoals gezegd, SHA1 was de keuze van Troy Hunt voor zijn plaintext bestanden.


Een set van 3.2E8 (<29 bits) heeft een echt totaal verwaarloosbare kans om een SHA-1 collision te bevatten.

Je hebt me... Ik moet er overheen hebben gelezen. Stom.... Troy Hunt had ze al met SHA1 gehasht.

Verder hoop ik dat het in de praktijk ook niet meer voorkomt dat men wachtwoorden alleen met SHA1 hasht, zelfs niet met salt. Laat iemand anders een voorbeeld nemen aan dit:
https://www.security.nl/posting/40920/LivingSocial+dumpt+SHA1-encryptie+na+hack



Maar eh... dit is toch echt een verkeerde interpretatie van je:
Wie heeft er gezegd dat er een collision kon zijn met één van de wachtwoorden uit dezelfde verzameling van 320 miljoen wachtwoorden?!

Ok, antwoord op de verkeerde vraag door mij . Ik blijf (nog meer) bij de conclusie .

Anoniem 01-09 17:31 dacht dat het password van 400 karakters hetzij erg simpel (400x 'a' ) of 'misschien een collision' zou zijn .
Dan zou er in de brondata van Troy dus een andere input staan waarvan de hash hetzelfde is als een input die Cynosure gegenereerd heeft.

In de context het vinden van een tweede input die dezelfde uitkomst heeft als een gegeven hash-uitkomst is het jargon 'first pre-image' attack - Dat vereist 2^160 pogingen voor SHA-1 (of een kans van 1/(2^160) per poging) .
Dat is dus echt _no way_ .

Een 'collision attack' in het jargon is heel veel makkelijker, omdat je hier _beide_ inputs mag kiezen (verschillend) en zien of de hash ervan hetzelfde uitkomt. Voor een [goede] hash van lengte <n> is die kans 2^ (n/2) - 2^80 dus voor SHA-1 .
In dit geval (vaste dataset met gehashte uitkomsten wordt dus gezocht naar een 'first pre-image'
Als je O(2^80) verschillende inputs hasht is er een heel grote kans dat je een collision tegenkomt - De kans dat een dataset van O(2^29) een collision bevat is nihil - dat is wat ik in gedachten had, alleen het is niet de vraag hier.

Natuurlijk is letterlijk gezien een 'first pre-image' _ook_ een collision, maar 'we genereren twee inputs met dezelfde hash-output' is een ander - veel makkelijker - aanvalsmodel dan 'we genereren/zoeken een input die overeenkomt met een gegeven output' .
(en om compleet te zijn : second pre-image attack: we zoeken een andere input die dezelfde hash uitkomst heeft als een gegeven input ).

Ik postte (02-09 00:09) al een angstig lang password (140 char) dat gevonden was - ik ben niet verbaasd dat 400 char , indien voldoende simpel ook nog binnen zoekbereik valt van de dictionary plus permutatie rulesets.
Er staan op de pagina nog wat opmerkingen over patches om de maximale lengte voor hun hash testers te vergroten - er is dus duidelijk gezocht tot heel lange strings.

Nee ik dacht dat er woordenboeken gebruikt konden zijn, of een speciaal algoritme dat hele lange wachtwoorden kan
ontdekken als er weinig variatie is.
En áls dat het niet is, zou ik denken dat het een toevallige collision kon zijn met een veel korter wachtwoord.

Het aantal mogelijke SHA1 collisions neemt namelijk heel erg toe als een wachtwoord veel groter is dan 20 karakters,
of liever gezegd: 40 hexadecimale getallen.
Men moet niet vergeten dat men aan de input van een SHA1 algoritme maar 2¹?? verschillende combinaties kan aanbieden.
Ieder wachtwoord dat langer is, wordt toch altijd weer automatisch herleid worden tot 1 van die 2¹?? combinaties.
Naar mate je een wachtwoord langer maakt, veroorzaak je dus in feite alleen maar nóg meer collisions.
Bij 400 karakters of 800 hexadecimale getallen of 3200 bits heb je 2³²?? mogelijkheden, maar er zijn iets van slechts 2?? verschillende hashes mogelijk. En er zijn niet alleen erg veel collisions met wachwoorden van dezelfde lengte, maar óók
met heel veel wachtwoorden die allemaal korter zijn dan 400 karakters.
Dat zijn echt een gigantisch aantal collision mogelijkheden die je dan bij elkaar hebt.

Dus ik denk niet als eerste aan een collision, maar dit is de mogelijkheid die overblijft als een plausibele verklaring,
die niet heel erg onwaarschijnlijk of zo.
Die machine is wel retesnel, maar nog steeds is het ondoenlijk om in afzienbare tijd alle 2¹?? SHA1 hashes te testen.
2¹?? is een integer getal dat uit 49 cijfers bestaat...
En dan natuurlijk als laatste mogelijkheid dat het om een echt wachtwoord van 400 karakters gaat.
Maar we hebben simpel te weinig informatie om te kunnen bepalen welke mogelijkheid zeker weten de juiste is.