quote:
Naast de beperkte informatie die door het beveiligingsbedrijf is vrijgegeven, is er ook kritiek op de werkwijze. Mensen die willen weten of ze mogelijk slachtoffer zijn geworden kunnen zich aanmelden voor de Hold Identity Service. Een gratis dienst die mensen waarschuwt als hun gegevens in de database voorkomen. Hiervoor moeten mensen de wachtwoorden van de mogelijk gecompromitteerde websites op een pagina invullen.

lol, je wachtwoord invullen?
Is dit niet de definitie van een phishing mail?

Hold Security komt niet sympatiek op mij over. Ze proberen hier een slaatje uit te slaan.

Die password checker klopt ook van geen kant. Een database met alleen hashes is niet interessant. Die hashes zijn alleen interessant als ze gekoppeld zijn aan een inlognaam en/of email adres, en dan nog in combinatie met de website waar de hash is buitgemaakt. Zou Hold die informatie eigenlijk wel hebben?

Hold moet gewoon de lijst met gehackte sites openbaar maken. Vervolgens moeten klanten van die sites op inlognaam/email-adres kunnen zoeken.

Het invoeren van het wachtwoord lijkt mij zeer onverstandig, ook al claimt Hold dat het veilig is.

Nee Peter V., dat klopt niet! (kan je ook zelf controleren op de website van HS)

- De Breach Notification Service voor webmasters kost 120 dollar per jaar
- De Hold Security Electronic Identity Monitoring and Protection is gratis.

"This service is FREE of charge and designed for the individual users to check whether they became victims of cyber-criminal activities. Please note, that this service does not provide you with any information pertinent to a website breach. If you are contacting us on behalf of a company, please, refer to our BNS service."

https://identity.holdsecurity.com/Register/

Hold Security doet er juist goed aan niet te publiceren welke sites betrokken zijn bij de diefstal, maar in plaats daarvan de eigenaren van die sites waarschuwen zodat ze maatregelen kunnen treffen. Het kost veel tijd totdat die hun zaakjes op orde brengen.

Daarna kan de lijst naar de overheid van betreffende landen. Voor zover er disclosure wetgeving van kracht is, kan dat helpen bij het uit de kast te laten komen van de gehackte bedrijven en instellingen.

@Peter V
Gratis dienst zegt het artikel. Ik zou er nooit gebruik van maken, want je gaat natuurlijk niet je gegevens aan een derde verstrekken.

Krebs is een geloofwaardige journalist, en er is geen enkele reden waarom de vondst van de data niet waar zou kunnen zijn.

Inderdaad, wanneer je dat moet doen, kun je beter meteen al je wachtwoorden vervangen, nu weet je nl. zeker dat iemand die ze niet nodig heeft over de informatie kan beschikken. Die hash is leuk, maar dan moet je wel geloven dat ze dat doen. Er zijn maar weinig gebruikers die kunnen beoordelen of er ook gebeurt wat er staat.

Gratis oplossing en breder dan deze "hack": https://leakdb.abusix.com


De aankondiging valt wel heel toevallig samen met BlackHat USA...

http://www.chron.com/business/article/Expert-wants-to-help-nab-Russian-password-thieves-5672694.php?World_Business_News=

Brian Krebs, who investigates online cybercrime and blogs about it, said his phone and email were inundated while he was at the conference Wednesday with people asking about Holden's announcement.

"Alex isn't keen on disclosing his methods, but I have seen his research and data firsthand and can say it's definitely for real," said Krebs. "Without spilling his secrets or methods, it is clear that he has a first-hand view on the day-to-day activities of some very active organized cybercrime networks and actors."

Krebs is inderdaad een geloofwaardige journalist, maar ook betrokken bij Hold Security: http://www.holdsecurity.com/about/advisory-board

Waarom niet de usernamen met bijbehorende websites gebruikt kunnen worden bij de verificatie begrijp ik niet. Daarnaast, zijn alle onderschepte wachtwoorden die Hold Security in haar bezit heeft allemaal via SHA-512 gehashed? Zo niet (en ik weet nu al dat het niet zo is), hoe kunnen ze dan zien of mijn wachtwoord is gestolen? Aangezien ik alleen een wachtwoord in kan vullen bij de verificatie, weet ik alleen dat die tekststring in SHA-512 formaat in het bezit is van Hold Security, verder niets. Ik weet niet of het wachtwoord gekoppeld is aan een account van mij, ik weet niet of mijn wachtwoord gestolen is en niet in SHA-2 maar in b.v. SHA-1 of bcrypt formaat in hun bezit is. Ik weet helemaal niets, dus waarom deze verificatie in het leven is geroepen is mij een raadsel. De terugkoppeling van Hold zegt namelijk 0.0 over de veiligheid van mijn accounts en wachtwoorden.

https://identity.holdsecurity.com/ gebruikt momenteel een domain validated certificate, geen HSTS en geen forward secrecy. Verder hebben ze hun zaakjes redelijk op orde met een A- op https://www.ssllabs.com/ssltest/analyze.html?d=identity.holdsecurity.com.

Een SHA-512 hash van een kort wachtwoord (van zeg max. 8 a 9 karakters) is zinloos, want daar kan Hold Security (of een aanvaller die hen weet te hacken) een rainbow table voor maken. Daardoor kunnen zij te weten komen welk wachtwoord jij gebruikt, OOK als dat nu nog niet in hun "collectie" voorkomt.

Daarnaast schrijven ze (zie boven en http://www.holdsecurity.com/news/cybervor-breach/) dat jouw wachtwoord SHA-512 gehashed wordt in jouw webbrowser. Wellicht is dat vandaag zo, maar geldt dat morgen ook nog?

Als jij een wachtwoord invoert in een webapplicatie moet je ervan uitgaan dat jouw wachtwoord plain-text naar de server gezonden kan worden (tenzij je er verstand van hebt en eerst alle html, javascript etc. doorspit die de server naar jouw webbrowser heeft gestuurd); je moet de beheerders dus volledig vertrouwen en hopen dat ze de zaak goed beveiligd hebben. In de "Lavabit-case" heeft de FBI de beheerder van Lavabit om dienst private key gevraagd (zie http://en.wikipedia.org/wiki/Lavabit); de beheerder, Ladar Levison, heeft die niet afgegeven maar in plaats daarvan "de zaak gesloten". Dus je moet er rekening mee houden dat autoriteiten mee kunnen kijken op de verbinding.

Persoonlijk zou ik nooit mijn wachtwoord in een webpagina van zo'n "dienst" invoeren. Banken verbieden overigens dat je jouw wachtwoord "deelt" met derden, wat je doet via zo'n site.

Als het om een legitieme organisatie gaat, vermoedelijk doordat zij beschikken over (al dan niet uit hashes herleide) plain-text wachtwoorden en die met SHA-512 hebben gehashed. Daarna is het een kwestie van hashes vergelijken.

Hold heeft een verdienmodel, net als Fox-IT, Kaspersky, TrendMicro en zelfs onze Franse vriend van het blog Malware don't need Coffee (aanrader!) zal ergens van moeten leven. Ik zie het probleem niet.


Als je het originele artikel met interesse leest, kun je er achter komen dat Hold stelt dat er een botnet gebruikt is (wordt?) om SQL-kwetsbaarheden in bezochte sites te vinden. Waarom zou dat niet kunnen?


Mijn vraag is alleen of het wel gaat om account-gegevens (vaak versleuteld en nog vaker onbruikbaar), of om email-adressen (spam / scam / wholesale) ???


Zoek op z'n minst eerst eens uit of het wel of niet klopt wat er gezegd wordt, het lijkt geenstijl wel als ik sommige reacties hier lees. Onderbuikgevoelens, haat, onbegrip, ongeloof, daar wordt niemand echt wijzer of veiliger van mensen (au contraire) en is -IMHO- dit forum onwaardig.

Zo zal het wel gan ja. Maar ik weet niet of een gehashed wachtwoord dat in hun bezit is aan mijn acount is gekoppeld (doordat ik de bijbehorende gebruikersnaam en de website niet te weten krijg), ik weet niet of ze mijn wachtwoord hebben in een formaat anders dan SHA-512 (al dan niet zelf ontsleuteld of "onthashed"), ik weet eigenlijk niets. Het enige dat ik weet is wanneer ik een succesvolle verificatie uitvoer, dat ze "Secret123" in SHA-512 op hun server hebben staan. Wat heb ik daaraan? Ik zou mogelijk zenuwachtig worden wanneer de SHA-512 hash van mijn wachtwoord "Ditwachtwoordveranderikiederedag2keerwantdanbenikpasechtveilig" tegenkom. De kans is vrij aanzienlijk dat ik de enige ben ter wereld met zo'n wachtwoord.

Als laatste punt: ik moet me eerst registreren voordat ik een verificatie uit kan voeren. Ik vind het een groter risico dat een bedrijf dat ik niet ken ten eerste mijn e-mailadres krijgt en ten tweede een SHA-512 hash van mijn wachtwoord. Wie zegt mij dat Hold Security in kolom 1 van hun wachtwoorddatabase niet de (al dan niet zelf gemaakte) SHA-512 wachtwoorden heeft staan en in kolom 2 de bijbehorende plaintext wachtwoorden? Dan weten ze in ieder geval een e-mailadres en een plaintext wachtwoord. Als ik een "evil Hold" was zou ik vervolgens zeggen dat het wachtwoord niet in de database voorkomt. Met een beetje geluk is het geverifieerde wachtwoord gekoppeld aan het e-mailadres dat bij registratie is gebruikt en wordt het wachtwoord door de gebruiker door mijn melding niet veranderd. Maar zo zal Hold Security niet zijn.

Een klassieke blog over deze "hack" van Graham Cluley: http://grahamcluley.com/2014/08/cybervor-pay

Let vooral op de graphic hierboven in het artikel en het commentaar van Graham :-)

Hoe denk je dat een wachtwoordlijsten met werkelijke gebruikte wachtwoorden die hackers als woordenboek gebruiken, tot stand komen?

Hoe zou IT-services van Stanford aan een woorden lijst met 63 miljoen woorden komen om vooraf, bij het aanmaken van een account, te controleren of een nieuw wachtwoord soms bekend is?

Door dit soort lijsten te gebruiken en te de-hashen volgens mij. Dus zo'n lijst is uitermate interessant, ook voor mijn toekomstige wachtwoorden.

Online gevoelige gegevens invullen? !

Eerst nadenken en dan vervolgens alnog niet doen ;-)
https://www.security.nl/posting/397781#posting397797

Iets in de reactie scrollen naar :

* Gezonde Paranoia : Argumenten tegen en rondom online checkers van persoonsgegevens - Privacy!

@Righard, zo te zien kan Graham ook niet lezen... maar ja, sensatie en zo he...

"Security firm that revealed “billion password” breach demands $120 before it will say if you’re a victim"

eh nee. "This service is FREE of charge and designed for the individual users to check whether they became victims of cyber-criminal activities. Please note, that this service does not provide you with any information pertinent to a website breach. If you are contacting us on behalf of a company, please, refer to our BNS service. " free is nog steeds gratis in mijn woordenboek.

Ehh, vreselijk Off Topic maar heeft Peter V. zijn (of haar ;D) account nu ineens verwijderd?

Ik blijf het verhaal van de SHA-512 hash voor de vergelijkingsservice vreemd vinden. Zouden Hold soms een lijst met SHA-512 gehashte wachtwoorden hebben verkregen/gestolen? En daarom nog weinig anders kunnen doen dan vergelijken. Vervolgens hebben zij toch wel enige tijd nodig om die lijst te de-hashen, lijkt mij.

De kracht van hash algoritmen ligt in het feit dat er niet "ge-dehashed" kan worden. Het is kortom niet mogelijk om op basis van een hash waarde de input te achterhalen. In theorie bestaat er ook een oneindig aantal berichten dat tot dezelfde hashwaarde leidt, dus je zou zelfs niet zeker kunnen zijn van de juistheid van een "ge-dehasht" plaintext bericht (maar nu gaan we heel erg in de theorie zitten). De enige manier (zeker bij SHA-512) om te achterhalen wat de input van het hash algoritme is geweest is om een dictionary te pakken, de wachtwoorden daarin te hashen met SHA-512 en om de berekende hashwaarden te vergelijken met de gehashte wachtwoorden in het buitgemaakte wachtwoordenbestand. Aangezien de entropie van een wachtwoord gemiddeld zeer laag is, zal het geen probleem zijn om in no-time miljoenen wachtwoorden te achterhalen, temeer doordat er heel veel dubbele wachtwoorden in hun bestand zullen zitten (meer dan 1 persoon zal "123456" of "qwerty"' als wachtwoord gebruiken).

Precies en dat bedoelde ik natuurlijk met de-hash, maar ik had beter kraken kunnen zeggen. Zo doen krakers dat met alle gestolen hashes. En dat kost Hold dus ook enige tijd, als zij inderdaad alleen de hashes hebben.

Daarnaast kan Hold, door de simpele manier van slechts 1 SHA-512 hash slag te doen (en geen key derivation of iteraties), rainbow tables maken/kopen. Afhankelijk van de gebruikte teken categorieën (alleen kleine letters of ook hoofdletter en/of ook cijfers etc), moet dat voor alle wachtwoorden tot 7 a 9 tekens lukken. En ook voor langere wachtwoorden waarvoor gekraakte hashes te koop zijn!

Als iemand gestolen fietsen verkoopt zijn we het erover eens dat die persoon een heler is.

De Duitse overheid overweegt nu de handel in gestolen informatie strafbaar te maken, zie http://www.heise.de/security/meldung/Justizminister-will-gegen-Datenhehlerei-vorgehen-2288949.html.

Ze doen dat door een woordenboek te pakken en daar standaard wijzigingen op toe te passen. Bijvoorbeeld 0 en 0 omwisselen of met I, l en 1 te gaan spelen. Ook E en 3 en A en 4 zijn bekende vervangingen.

Naast natuurlijk de standaard toetsenbordreeksen zoals 1qsx2wdc e.d.

Peter

Ik wens ze veel succes met het opzoeken en raden van toekomstige wachtwoorden.

Ca6};6q#'{*?I5(C520gA;&-b.,9At;}MR[8zM#7bZi4T{:jmx0T';}o3k8"

Het raden kan juist achterwege blijven als zo'n lijst is gekraakt! Er zijn voldoende lijsten met reeds in gebruik zijnde wachtwoorden in klare tekst.

De Engelse taal heeft zo'n 150 duizend woorden. Dat is erg veel voor een westerse taal. IT services op Stanford University gebruikt een woordenlijst met 63 miljoen woorden. Dat zullen voor een deel mutaties zijn van worden in vele talen zoals 11:39 Anoniem aangeeft. Maar voor een deel moeten dat ook bestaande/gekraakte/gepubliceerde wachtwoorden zijn.

Als je echt
Ca6};6q#'{*?I5(C520gA;&-b.,9At;}MR[8zM#7bZi4T{:jmx0T';}o3k8"
gebruikt, zul je ontdekt hebben dat vele sites de wachtwoordlengte beperken. Ik bestelde net iets bij Dell en daar is de wachtwoordlengte beperkt tot vermoedelijk(!) 19 letters en cijfers.

Maar je impliciete boodschap is duidelijk. Als je wachtwoorden gebruikt van 15 willekeurige tekens lang, heb je
- een wachtwoord manager nodig en
- dan is er niets aan de hand als iemand de een lijst steelt met jouw wachtwoord hash, zelfs als de site een zwakke hash methode gebruikt.
- geen bescherming als een site wachtwoorden opslaat in leesbare tekst

Niet om je te bekritiseren, en het is vooral een theoretische discussie (en een check voor mijzelf, correct me if I'm wrong), maar dat gaat niet altijd op.

Hoe zwakker (in de zin van het aantal resulterende bits) de hash methode, hoe groter de kans op collisions. En dit gaat vooral spelen als de resulterende hash (in bits) korter is dan het wachtwoord (in bits).

Op een toetsenbord met USA-indeling tel ik 32 speciale karakters (exclusief spatie). Samen met cijfers, hoofd en kleine letters kom ik op 94 mogelijkheden per karakter. Een wachwoord van 15 karakters heeft dus 94^15 = ruim 3e29 mogelijkheden.

Een MD5 hash is 128 bits lang, kent dus 2^128 = ruim 3e38 mogelijkheden, dus veel meer dan een wachtwoord van 15 karakters. Echter, een wachtwoord van 60 karakters (zoals Ca6};6q#'{*?I5(C520gA;&-b.,9At;}MR[8zM#7bZi4T{:jmx0T';}o3k8") is met ruim 2e119 mogelijkheden aanzienlijk "langer" dan MD5.

M.a.w., als je weet dat MD5 als hash wordt gebruikt is een wachtwoord langer dan ca. 20 karakters (uitgaande van de genoemde 94 mogelijkheden per karakter) dus niet zinvol. Echter, door het astronomische getal van ruim 3e38 mogelijkheden van MD5 is de kans op collisions, zelfs in een tabel van enkele miljarden unieke wachtwoorden, uiterst klein.

Maar, stel dat iemand als hash methode CRC16 besluit te gebruiken! Ik weet het, dat is geen cryptografische hash, maar qua beveiliging van de applicatie zelf is het zo gek nog niet (zeker indien gecombineerd met account-lockout): het is beter dan een 4-cijferige pincode en de bedenker zou kunnen argumenteren dat het wachtwoord niet plaintext wordt opgeslagen (op zich juist).

Echter, als de database in handen van een aanvaller valt, dan hoeft die aanvaller slechts een rainbow table met 65536 wachtwoorden met bijbehorende (unieke) CRC16 hashes te genereren om op elk account in te kunnen loggen, dus ook op jouw account. De kans daarbij dat het door de aanvaller gegenereerde wachtwoord even lang is of zelfs maar lijkt op het door jou verzonnen 15-karakters lange wachtwoord, is uiterst klein...

Kortom, je bent altijd afhankelijk van de applicatiemaker, ook als hij jouw wachtwoord niet plaintext opslaat.

Een veiliger alternatief voor wachtwoorden in webapplicaties is het door de gebruiker genereren van een asymmetrisch sleutelpaar en het verstrekken van een public key (desgewenst een unieke key per website). De server stelt vast dat de gebruiker is wie hij zegt te zijn door een random getal te versleutelen met de public key; alleen de bezitter van de bijbehorende private key kan deze ontsleutelen en plaintext terugzenden (de gebruiker ontsluit die private key met een lokaal gebruikt wachtwoord). Mits met voldoende randomness gegenereerd maakt het niet uit als public keys gestolen worden...

Op zich aardig, maar in de discussies over die gelekte 1 miljard accountgegevens lijkt de aandacht volledig naar wachtwoorden uit te gaan. Een wachtwoord kan ik wijzigen, bij veel van mijn persoonlijke gegevens (waaronder e-mail adres) is dat aanzienlijk lastiger.

M.a.w. ook al voeren we een beter alternatief in voor wachtwoorden, degelijke beveiliging van gegevens in webapplicaties blijft noodzakelijk. Dat schiet nu ernstig tekort, en dat is het probleem dat we moeten aanpakken - in plaats van elke week een nog betere password verhaspelingmethode verzinnen en gebruikers overstelpen met wachtwoordadviezen.

Inderdaad voor een deel een theoretische discussie, maar wel met praktische consequenties zoals je aangeeft. En mijn opmerking was vanuit de praktijk, niemand gebruikt zo'n voorbeeld van 80 willekeurige tekens denk ik. Ik ben het met je eens v.w.b. de grote lijn van je verhaal.
Hoewel hash collisions niet een specialiteit van mij is, toch nog een paar aanvullende opmerkingen vanuit die praktijk.

- Boven de 20 tekens gebruik ik wel, maar alleen als passphrase met alleen kleine letters

- De volgende getallen gelden als als elke letter een random keuze is. Dat is niet zo bij een wachtzin, maar voor deze discussie lijkt mij dat niet belangrijk.

- Voor langere wachtwoorden lijkt mij de Stanford richtlijn als zeer praktisch:
http://itservices.stanford.edu/service/accounts/passwords#rules:

Als 8-11 lang: mixed case letters, numbers, & symbols, 11 tekens geeft dan: ~5E21 mogelijke wachtwoorden
Als 12-15: mixed case letters & numbers, 15 tekens geeft dan: ~7E26 mogelijkheden
Als 16-19: mixed case letters: ~4E32 mogelijkheden
Als 20+: no restrictions: een wachtzinvan 30 lower case letters geeft: ~3E42 mogelijke wachtwoorden

- In die richtlijn zit al iets inbegrepen dat het boven de x tekens geen zin heeft om nog langere wachtwoorden te gebruiken. Dat strookt met jouw opmerking: 1 reden is hash collisions die je zou kunnen krijgen.

- De vraag is dan als dit de geldige maxima zijn, kunnen zich daarbij in de praktijk al collisions voordoen? Hierdoor zou het aantal mogelijke wachtwoorden dat voor een brute force aanval moet worden afgegaan, kleiner worden.

- Moderne hash algoritmen schijnen bij deze aantallen collision vrij te zijn. Bij oudere methode als MD5, treedt vermoedelijk een collision op na de helft van het aantal mogelijke hashes, dus na 2^27= 1E38 hashes. Dat zou dan kunnen optreden in de buurt van een wachtwoord lengte van boven de 16 tekens van de Stanford richtlijn.

- Vermoedelijk kan je zeggen dat het bovengenoemde aantal mogelijkheden maximaal 1E38 is. Maar dan vervalt de garantie die brute force nu juist wel levert. Maar toch, 1E38 levert voor snelle hashes op prof. apparatuur een gemiddelde kraaktijd van eeuwen op. Dat strookt dan weer met mijn opmerking dat als je een sterk wachtwoord hebt, je geen zorgen hoeft te maken, ook al gebruikt een site een zwakke hash methode voor opslag van wachtwoord hashes..

Wel een interessant gezichtspunt als dit allemaal waar is. Ik zal mijn generatie en analyse tool SimThrow mogelijk aanpassen na wat meer leeswerk, of heb jij misschien referenties over aantallen collisions bij oudere methoden?
Ik heb overigens in mijn tool wel rekening gehouden met andere collisions (nu alleen nog inbegrepen in de beta versie,http://itura.nl/simthrow.html ), namelijk die in woorden lijsten voor passphrases, bijvoorbeeld de woorden 'kon' en 'Ing' vormen samen 'koning' waardoor de sterkte van de wachtzin met 1 woord afneemt.

Vooraf, bij wachtwoordhashes die gebruikmaken van MD5 en beter, spelen collisions, voor zover ik weet, in de praktijk geen enkele rol. Hopelijk heb ik jou niet op een dwaalspoor gezet! Ik probeer e.e.a. toe te lichten, voor zover mijn kennis hierover reikt.

De kans neemt af, maar collision-vrij kan niet. Immers, de defintie van een hash-functie is dat deze, ongeacht de input en haar lengte, een getal van een vast aantal bits oplevert. Aangezien er een oneindig aantal verschillende inputs mogelijk is en een beperkt aantal outputs, moeten er collisions bestaan.

Dat is zonder rekening te houden met de "Birthday Paradox". D.w.z. de kans dat in een groep mensen (bijv. een schoolklas) twee personen op dezelfde dag jarig zijn (collision); volgens http://en.wikipedia.org/wiki/Birthday_attack is de kans 70% dat in een groep van 30 personen er twee op dezelfde dag jarig zijn. Die kans is veel groter dan dat iemand in een groep mensen toevallig op dezelfde dag jarig is als jij.

Door die Birthday Paradox zullen collisions statistisch gezien veel eerder optreden dan bij de helft van 2^128 hashes (een aanvaller heeft hier in de praktijk echter niets aan).

In http://stackoverflow.com/questions/14973197/what-is-the-probability-of-md5-collision-if-i-pass-in-232-sets-of-string vraagt iemand hoe groot de kans is op collisions bij ruim 4 miljard met MD5 gehaste strings. In het antwoord (dat ik niet heb gecontroleerd) valt te lezen dat, hoewel de kans met 2.7E-20 nog steeds extreem klein genoemd kan worden, deze wel 9 ordes groter is dan de vragensteller vermoedde.

Daarnaast zijn wetenschappers vaak op zoek naar een methode om de collision-resistance van cryptografische hash functies te vinden. Onderin het grijze boxje rechtsbovenaan https://en.wikipedia.org/wiki/MD5 staat dat het mogelijk is om met een gewone computer binnen 1 seconde twee inputs te genereren die dezelfde MD5 hash opleveren. Maar, voor zover ik overzie, ook hier heeft een wachtwoordaanvaller niets aan.

Ik ga nu wat theoretiseren, correct me if I'm wrong. Collisions in wachtwoordhashes vormen een risico als een aanvaller een redelijke kans heeft om in te loggen op jouw account met een ander wachtwoord dat toevallig dezelfde hash oplevert. Aangezien die aanvaller op jouw account probeert in te loggen geldt de Birthday Paradox niet.

Stel dat een webapplicatie wachtwoorden afkapt door slechts de eerste 128 bits van wachtwoorden plaintext op te slaan. Dan zal een brute-force aanvaller statistisch gezien na de helft van de mogelijkheden het wachtwoord hebben geraden. Indien een MD5 hash van een wachtwoord is opgeslagen, is de succeskans groter omdat ook andere wachtwoorden tot dezelfde hash kunnen leiden. Hoeveel groter weet ik niet, maar hoewel MD5 zwaar gebroken is op het gebied van collision resistance, verwacht ik dat dit effect verwaarloosbaar zal zijn (maar dat kan ik niet onderbouwen). Duidelijk is wel dat hoe zwakker de hash, hoe groter die kans is.

Extreem voorbeeld ter illustratie: stel als "hash" wordt de pariteit van het wachtwoord opgeslagen (odd of even). Dan heeft een aanvaller 50% kans om binnen te komen met het eerste willekeurige wachtwoord. Als hij het wachtwoordalgoritme kent komt hij bij de tweede poging gegarandeerd binnen.

Wat ik met het CRC16 voorbeeld in mijn vorige bijdrage probeerde uit te leggen is dat het bij zeer korte hashes extreem eenvoudig wordt om 100% gevulde rainbow tables te maken.

Dat hangt van de definitie van "zwakke hash" af. Ik heb er geen gegevens over maar vermoed dat de meeste webapplicaties, na eerder passwords plaintext te hebben opgeslagen, direct zijn overgestapt op MD5. Aan de andere kant sluit ik niet uit dat ontwikkelaars zelf "hash functies" hebben bedacht die aanzienlijk zwakker zijn dan MD5 (zie ook hieronder).

Het is de vraag waar je je tegen probeert te wapenen; ik neem aan de diefstal van een database met "gehashte" wachtwoorden. In bijv. password-protected Powerpoint files wordt een CRC32 hash van het wachtwoord opgeslagen (bron: http://msdn.microsoft.com/en-us/library/ff385916%28v=office.12%29.aspx); een 100% gevulde rainbow table daarvoor genereren is niet moeilijk. In de 2e bijdrage van http://forums.devnetwork.net/viewtopic.php?f=1&t=94511&start=15 suggereert ook iemand dat hij ook CRC32 gebruikt.

Zelf heb ik de Excel password cracker uit http://www.theofficeexperts.com/VBASamples/Excel02.htm gebruikt toen ik een protected sheet moest bewerken en ik de auteur niet kon bereiken. Ik kwam er zo in met een vreemd ogend wachtwoord. Later kreeg ik het oorspronkelijk wachtwoord van de auteur, dat leek er van geen kanten op. Een collision dus.

In http://www.insidepro.com/hashes.php?lang=eng zijn verschillende (ook zwakke) password hash-algoritmes te zien, ik sluit niet uit dat deze hier en daar nog worden toegepast.

In http://en.wikipedia.org/wiki/Comparison_of_cryptographic_hash_functions#Cryptanalysis zie je de collision resistance van cryptografische hashes met een digest-size van 128 bits en groter. Gegevens van zwakkere hashes heb ik niet.

Ik ken geen methode om als gebruiker vast te stellen welke hashmethode, al dan niet met salt, een website gebruikt. Ik vrees dan ook dat je alleen maar kunt hopen dat een fatsoenlijk algoritme gebruikt wordt, maar veel belangrijker, dat de website zo beveiiligd is dat derden geen toegang hebben tot de gegevens (waaronder al dan niet gehashte en gesalte wachtwoorden).

Het waren er 60 en je moest eens weten,..

Tijd voor een Poll? : "Hoe lang is jouw langste wachtwoord bestaande uit qwillekeurige tekens?"
(bij benadering, 1-10/10-20/20-30/30-40/40-50/50-60)

Complexe wachtwoorden langer dan 15 willekeurige tekens zijn prima te onthouden, daar heb je echt geen wachtwoordmanager voor nodig.
Wel blijven oefenen en vaak gebruiken; de kracht van de herhaling.

http://www.wired.com/2014/07/how-to-teach-humans-to-remember-really-complex-passwords/

Maar als een wachtwoord van 20 willekeurige tekens genoeg is is dat zeker een aanrader, en nog gewoon te onthouden ook.

Dank je voor de uitgebreide referenties en uitleg. Fijn dat je niet altijd naar security.stackexchange moet gaan voor goede informatie. Ik heb geprobeerd bijval te krijgen voor het idee dat wij als gebruikers web sites vragen wat zij gebruiken (bijvoorbeeld voorafgaande aan de registratie).
Een paar parameters als lengte, character sets, hash methode, implementatie bibliotheek, salt zou al een goede indruk geven. Dan kan je daarna rekenen of een analyse programma gebruiken. Altijd maar 20 tekens of 6 woorden gebruiken (zoals Diceware nu aanbeveelt) vind ik ook vervelend als 4 woorden voldoet ook afhankelijk van wat je beschermt.

Ik kon erop wachten :-)
Goed idee, hoe verwerk je het aantal wachtwoorden, want dat lijkt mij ook van belang. zoiets van
"Als je meeer dan 10 wachtwoorden hebt, hoe lang is jouw langste wachtwoord bestaande uit echt willekeurige tekens?"
En ik zou zoiets nemen als 1-6,7-10,11-15,16-20,21-30,31-40,41-100
Ook 50 van dat soort wachtwoorden? Maar ik zal de referentie gaan lezen.