Inderdaad een heel sterk wachtwoord, maar:
1) Zelf kan ik zo'n wachtwoord onmogelijk onthouden als ik het niet elke dag intik. Binnen de kortste keren weet ik niet meer welke letters ik ge-leat-speaked heb en na een week niet intikken weet ik alleen nog dat het iets was met m'n vakantie in Peru;

2) Bij veel diensten is de max. wachwoordlengte beperkt tot bijv. 16 karakters en heb je niets aan dit advies;

3) Op mobiele devices nauwelijks foutloos in te voeren, vooral als je niet ziet wat je typt.

Mijn advies: gebruik een wachtwoordmanager zoals KeePass en bescherm de toegang daarvan met een sterk wachtwoord, en laat de wachtwoordmanager random wachwoorden genereren.

Bij IOT devices kun je het advies van Deral Heiland wel gebruiken, maar schrijf dan het wachtwoord op een sticker die je achterop het apparaat plakt. Dat geldt bijv. ook voor de admin en WiFi wachtwoorden van je modem.

Misschien dat één keer de eerste is? Ik gebruik ongeveer drie verschillende wachtwoorden (door elkaar) en dat lukt al meer dan twintig jaar.

Het kan volgens mij toch noch makkelijker Belangrijk is dat er een teken voorkomt uit een grote set, bij voorkeur als laatste.

"Mijn favoriete vakantie was in Peru$"

een lineaire brute force moet om dit te kraken toch de volledige set inclusief $ gaan genereren en zal pas op de laatste mogelijkheid inclusief de $ de juiste hash genereren - het is niet nodig dat dat op meerdere or eerdere plaatsen te doen?

En zo ben je de hele dag met de settings van je apparaten aan het pielen, in plaats van er gewoon iets mee te doen.

Mijn Windows Vista/7 laptop ondersteund slechts een wifi-wachtwoord van 25 digits. Ik heb geprobeerd een wachtwoord van 30 digits in te voeren in het wachtwoord-veld,maar ik kon er maar 25 in kwijt,dus moest ik m'n zorgvuldig samengestelde wachtwoord aanpassen/inkorten.

Passphrases zijn idd beter maar lastig omdat we zo veel verschillend accounts hebben. Een password manager kan uitkomst bieden maar ja het is uiteindelijk weer software. De thuis gebruiker doet er verstandig aan om wachtwoorden op te schrijven. Stop het papier in een boek in de boekenkast indien je bang bent voor inbrekers. Kies een simpel wachtwoord voor niet kritieke logins en de rest doe je via papier of pw manager.

Passphrases ipv passwords gebruiken, wat een ge-wel-dige tip. Onder welke steen heeft deze 'expert' gelegen? Negen van de tien applicaties kunnen die lengte van wachtwoorden niet eens aan. Dus als je deze briljante tip al zou willen gebruiken lukt je dat in de praktijk nauwelijk. Ook het vervangen van een a door een @ enzo is al zo oud als de weg naar Rome.

Echt een geweldige expert deze expert.

Gaat naar zolder nog wat andere ouwe rommel opzoeken, het is Halloween...

Enne.. een exper die bij een amerikaans beveilingsbedrijf werkt..

Dit kan ik wel deels bevestigen, alleen het probleem is dat niet elke website of diest een wachtwoord van 32 karakters ondersteund. Overigens probeer ik het altijd wel. Zo hebben mijn hotmail en bank account een wachtwoord van 145 karakters.

Ik denk dat je adviezen voor keuze van wachtwoorden niet door een security expert moet laten geven maar door een
expert op het gebied van het menselijk geheugen. Uit het bovenstaande blijkt wel waarom dat is.

"security experts" denken dat ze goede adviezen geven maar in werkelijkheid zijn hun adviezen juist contraproductief.
Dat hebben ze zelf niet in de gaten.

Dan moet je niet tegen dit soort ongein aanlopen:

Meneer Heiland (what's in a name) geeft onvolledige informatie. 32 karakters is al een stuk veiliger, maar doe ook het volgende:
1. Zorg dat minstens 1 woord uit de reeks niet in woord/taal-databases voorkomt. Dus gebruik een onbekende eigennaam of een verzonnen woord.
2. Zet tussen alle woorden die je gebruikt een " - " (gewoon streepje).

https://sites.google.com/site/easylinuxtipsproject/password

Judas

Dien bug-reports in. Serieus. Beleefd, met linkjes naar dit soort adviezen. Als mensen dat net zo massaal zouden doen als ze op fora klagen dat goede suggesties zinloos zijn zou het wel degelijk effect hebben.

Een goed advies zou zijn:
- hang geen zaken aan internet die dat functioneel niet nodig hebben.
Waarom een automatische update functie met vaste gecodeerde user/passwoord nodig is?
- Passwords zijn zo 20-e eeuw ( van een paar decennia terug) dat moet echt beter kunnen.
waarom je daaraan vasthoudt alsof het stoommachines zijn in nieuwere tijd, geen idee.

Eindelijk een medestander. Ik wacht op meer. Want: ook het gepiel met updates, archivering, back ups - het kost idioot veel tijd, ik doe veel minder met m'n computer dan 15 jaar terug.

O help, daar gaan we weer... Nog maar eens:

Elk wifi-netwerk wachtwoord wordt in de wifi-router omgezet in zijn -tig voudige SHA1 hash afgeleide van dat wachtwoord. Dat zijn dus 20 bytes omdat de (bij WPA2 gebruikte) SHA1 hash "by design" 20 bytes output geeft.
Daar gaan dan nog eens het aantal karakters van af ter grootte van de netwerknaam, en zo'n 4 karakters die onderscheid tussen meerdere routers maken, zodat je wachtwoord slechts op één router werkt,
en niet per ongeluk ook op een totaal andere router die toevallig precies hetzelfde wachtwoord heeft ingesteld...
Deze 2 zaken worden namelijk ook onderscheiden m.b.v. dat ene operationele wachtwoord van 20 bytes in totaal.

Daarom liever wifi-wachtwoorden niet langer kiezen dan: (16 - "het aantal karakters gebruikt voor netwerknaam").
Anders loop je risico dat er als bijprodukt één of meer wachtwoorden van veel minder karakters óók toegang gaat geven
tot je wifi, omdat het kortere wachtwoord dan immers precies dezelfde SHA1 uitkomst geeft.
En dat onbedoelde kortere wachtwoord kon wel eens veel gemakkelijker te kraken zijn. (omdat het korter is, zijn hackers met brute-force natuurlijk veel eerder klaar)

Het is bij WPA2 immers niet het ingegeven wachtwoord, maar een deel van een met opzet ingewikkeld berekende SHA1 hash uitkomst die in de praktijk door het systeem als het "operational" wifi-wachtwoord wordt gebruikt.

In het algemeen:
Je weet pas zeker of een heeel lang wachtwoord veiliger is, als je weet hoe een systeem met je wachtwoord omgaat!

(SHA1 hash kon ook wel eens ten grondslag liggen aan het feit dat ING een wachtwoord tot max. 20 karakters aan kan)


Goeroehoedjes

Dat is geen goed advies.

Wat je moet bereiken is dat je _netto_ zeker zoveel 'random' bits in je password hebt zitten als dat er na hashing gebruikt worden.
Als je je password echt random kiest zou dat net kunnen met evenveel karakters als de hash lang is.
[- of ietsje meer, omdat je toegestane karakters uit een set van 6..7 bits komen ]

Maar omdat het kiezen en onthouden van echt random woorden erg lastig is, kies je een langere zin , die bij elkaar ook ~ 160 bits entropie bevat - hopelijk .
En dat is precies waarom uberhaupt een hash gebruikt wordt , om uit een willekeurig korte of lange input een representatieve bitreeks van vaste lengte te halen .

Je advies dat bij gebruik van een langere wachtzin er een (groter) risico bestaat dat er vindbaar korter wachtwoord bestaat met dezelfde hash is gevaarlijke onzin.
Wat je noemt oh help daar gaan we weer .

Hashes hebben collisions, als de input langer is dan de hash. Soit. Die zijn nog steeds onvindbaar bij een goede hash zoals
SHA-1 .
De vrij korte woorden daarintegen die mensen kiezen als "heel erg moeilijk random " daarintegen zijn uitstekend vindbaar .

Bij een goed opgezet hashingalgoritme (en dat is SHA1) is het praktisch onmogelijk om te berekenen wat de input moet zijn om een gelijke output te verkrijgen, dat is het hele idee achter hashing. Ja, er is kans op een hash collision. Nee, die kans is extreem klein. Ergens in de ordegroote 10 ^ -45 https://stackoverflow.com/a/1867252.

Jouw suggestie volgend, zou ik (met mijn SSID van 10 karakters) dus een maximale wachtwoordlengte van 6 tekens moeten kiezen. Een klein beetje potente GPU heeft dat in een paar seconden gebruteforced. Een wachtwoord van 32 tekens daarentegen, duurt met dezelfde GPU eeuwen. (Moet je natuurlijk wel WPS uit hebben staan, anders is het achterhalen van het wachtwoord alsnog een peuleschil.)

@ Vandaag, 12:37 door wizzkizz

Goeie poging, maar je uitgangspunt is verkeerd.
https://stackoverflow.com/a/1867252 gaat over een andere situatie.
Denk er nog maar eens goed over na. Ik zal proberen het later nog wat nauwkeuriger uit te leggen.
(tenzij je het zelf al hebt gevonden en gepost uiteraard ;-)

Goeroehoedjes

Ik schreef 12:04 .

Inderdaad gaat de stackoverflow link over de birthday paradox en het vinden van een collision. Dat is relatief gezien het makkelijkst bij hashes, maar dat is inderdaad niet het scenario van het vinden van een andere input met dezelfde hash uitkomst - dat heet een first pre-image .

First pre-image : gegeven een hash output, vind enige input die dat als resultaat geeft.
[gegeven y , vind een x zodanig dat h(x) = y ]

Second pre-image : gegeven een hash input, vind een andere input met dezelfde hash uitkomst .
[gegeven x , vind een x' zodanig dat h(x) = h(x') ]

Collision : vind een willekeurig paar inputs met dezelfde hash uitkomst .
(vind een paar x en x' zodanig dat h(x) = h(x') )

Nu mag jij uitleggen waarom de WPA2 password functie een vindbaar first pre-image heeft als je lange passphrases zou gebruiken.

Iemand weleens van dice ware gehoord?
https://www.rempe.us/diceware/#eff

Ik heb tientallen wachtwoorden voor tal van zaken, maar heb nog nooit een wachtwoord manager gebruikt omdat het wachtwoord van de wachtwoordmanager dan vreselijk belangrijk is. Als de software van de wachtwoord manager op een of andere manier faalt, of als dat wachtwoord gestolen wordt, dan heb ik een heel groot probleem en veel werk. Het zonder wachtwoordmanager doen is veel werk maar in mijn ogen veel veiliger.

Ik gebruik al jaren Haha$DitIsZoMakkelijkTeOnth0uden

WPA2 heeft wel degelijk een mogelijkheid voor een 256 bits sterke key. Daarvoor moet je een sleutel opgeven van 64 hexadecimale tekens. (0..9,A..F) . T/m 63 tekens werkt het hash algoritme mee.

De SSID relatie met de sleutel, is er toch alleen om het gebruik van rainbow tables tegen gaan, door dit als 'salt' te gebruiken? Zie https://www.renderlab.net/projects/WPA-tables/ dat je echt een unieke netwerk naam moet nemen. (Of een sterk wachtwoord dan werken die tabellen ook niet.)
Het wachtwoord wordt door die netwarknaam voor andere aanvallen niet sterker of zwakker van.De SSID naam lengte aftrekken van de 160-bits 'lengte' voor het wachtwoord is onzin.

-- toegevoegd SSID

Ik gebruik gewoon een passphrase met daarna een willekeurig woord/reeks wat bij desbetreffende dienst past.

D1tWachtw0ordisv0or=Vogeltje! voor bijvoorbeeld Twitter. Zo heb je toch unieke wachtwoorden en is de kans dus ook een stuk kleiner dat ze met een gelekt wachtwoord uit een database andere diensten kunnen 'hacken'.

Hoe WPA2 ongeveer werkt heb ik al eens nagezocht: https://www.security.nl/posting/460653
Er gaat niet alleen een wachtwoord door (een flink aantal iteraties van) de sha1 hash heen.
Nee, bij WPA2 is het je wachtwoord + SSID(netwerknaam) + 4 routeronderscheidende bytes.

De sha1-functie heeft in beginsel 160 binaire ingangen en 160 binaire uitgangen.
(wordt wel weergegeven als 5x32 bytes: https://en.wikipedia.org/wiki/SHA-1 (zie plaatje))
Je kunt dus 2^160 verschillende ingangscombinaties aanbieden die in het gunstigste geval
theoretisch zouden kunnen leiden tot 2^160 verschillende uitgangscombinaties.

In werkelijkheid zijn er al collisions, en is de sha1 functie wat dit betreft niet perfect.
Dan moet het wel zo zijn dat verschillende ingangscombinaties dezelfde uitgangscombinatie oplevert:
d.w.z.: een collision.
Zoals wizzkizz 30-10-2016, 12:37 al zei: de kans op zo'n type collision is bijzonder klein.
Voor het gemak laat ik het daarom verder buiten beschouwing.

Het probleem is echter dat je met een erg lang wachtwoord veel meer collisions gaat krijgen:
Het "hashen" van karakters gebeurt immers in een algoritme met blokken van 64 bytes (=512 bits)
input met als hash-resultaat slechts 20 bytes output. (meer uitgangen heeft de SHA1-functie niet)
Dit moet wel leiden tot een enorme berg collissions, want zonder collisions
zouden 2^512 verschillende ingangswaarden moeten leiden tot 2^512 verschillende uitgangswaarden.
Er zijn echter maar 2^160 verschillende uitgangswaarden beschikbaar!


Maar laten we uitgaan van een wachtwoord van 32 karakters (= 32 bytes) en kijken hoe dat uitpakt.
Bij elke 32 bytes (=256 bits) input ingevoerd aan een SHA1 blok-algoritme met 160-bit outputs
moeten 2^256 verschillende ingangscombinaties leiden tot 2^160 verschillende ingangscombinaties.
Dat lukt natuurlijk nooit.
Het kan niet anders dan tot heel veel collisions leiden, want je kunt 2^256 duiven
nooit zo in 2^160 hokjes kwijt met als eis dat er nooit meer dan 1 duif in elk hokje zit...
Er zullen daarom hokjes zijn met meerdere duiven ("Pigeon-hole" theorie)
Gemiddeld leidt iedere ingangswaarde dan maar liefst tot 2^(256-160-1) = 2^95 collisions,
en er hoeft er maar ééntje te zijn met een heel kort wachtwoord...

Waardoor het nog meevalt: we mogen als input niet alle mogelijke bitcombinaties gebruiken,
omdat de wachtwoorden bij WPA2 (verplicht) moeten bestaan uit (95) printbare ASCII tekens.
Van de 256 verschillende waarden die een byte kan aannemen, worden er dus maar 95 effectief gebruikt.
Dat schept voor een wachtwoord van 32 bytes: 95^32 mogelijkheden voor een wachtwoord.
95^32 is iets meer dan 2^210 mogelijkheden.
Er vormen zich dan toch nog gemiddeld ca. 2^(210-160-1) = ca.2^49 onbekende collisions
En daarvan hoeft er maar eentje te zijn met een hackbaar kort wachtwoord dat volledig
bestaat uit printbare ASCII karakters. (Of i.g.v. een hack, vervalt zelfs de voorwaarde
dat het volledig uit printbare ASCII karakters moet bestaan!)
(eigenlijk valt het nog slechter uit, omdat SSID +4 bytes niet bij de input zijn meergerekend)

Daarom geloof ik dat voor WPA2 een korte SSID van 3 of 4 karakters en dan een truly random wachtwoord
van 12 of 13 karakters om niet teveel risico te lopen op gevaarlijke collisions veel beter is.
Afhankelijk van de risico's af en toe mischien weer eens wijzigen.

Ik ben mij er van bewust dat er nog enkele schoonheidsfoutjes in staan, maar het gaat om het principe.
Mocht ik toch nog (grof) bepaalde zaken over het hoofd hebben gezien, dan laat ik mij graag verbeteren. ;-)

Goeroehoedjes

Het voornaamste wat je grof fout doet is de totaal ongefundeerde aanname dat er een niet-verwaarloosbare kans is dat de collision van een erg lange passphrase terecht komt op een woord wat binnen de zoekrange zit van een dictionary+permutatie zoeker .

Verder maak je de denkfout dat een lange string *veel* collisions heeft .
Dat is helemaal niet te verwachten - wel dat de _set van strings van lengte <veel>_ een grote set van collisions heeft, maar niet dat een enkele lange string ook meer dan enkele collisions heeft .

Voor een enkele gegeven input van 320 bit lengte kun je aannemen dat er _ook_ een 160 bit input is die dezelfde uitkomst heeft , als SHA-1 hash.
Je mag zeker _niet_ aannemen dat *die ene* 320 bit input een uitkomst heeft waarvoor *heel veel* 160-bit inputs bestaan.
Er volgt namelijk uit dat er uberhaupt 'heel veel' collisions zijn in de 160 bit input ruimte, en dat zou betekenen dat de hash feitelijk slecht is . (niet zo uniform)

En voor een andere 320 bit input is er ook 160 bit input die dezelfde uitkomst geeft. Misschien is dat dezelfde 160 bit input als voor de eerste 320 bit string.

De kans dat de 160-bit collision van een bepaalde langere input toevallig uitkomt op iets wat binnen de zoekruimte van dictionary+permutatie programma's zit is astronomisch klein - en dat is omdat 2^160 waanzinnig groot is, en de zoekruimte die bestreken wordt door dictionary en permutatie programma's gewoon een extreem klein percentage daarvan is.

Kennelijk begrijp je de "pigeon-hole" theorie niet.
Het is onmogelijk om 2^210 duiven in 2^160 hokjes te stoppen zonder dat er meerdere duiven in één hokje zitten.
Heb je zelf al eens nagedacht hoeveel duiven er dan gemiddeld in één hokje moeten zitten?...
("^" betekent machtsverheffen)
Evenzo kan je niet 2^210 verschillende ingangswaarden in 2^160 verschillende uitgangswaarden omzetten
zonder hetzelfde enorme aantal collisions.
Een woordenboek attack is natuurlijk niet verplicht. Gewoon brute force in dit geval, en de aanvaller kan aangepaste hardware gebruiken als de eis van de minimale wachtwoordlengte van 8 ASCII karakters in de weg zit.

Je kan het trouwens ook anders beredeneren. Heb je al eens uitgerekend wat de sterkte van een wachtwoord met 12 karakters is, waarbij je uit 95 willekeurige ASCII karakters mag kiezen?
Log(95x95x95x95x95x95x95x95x95x95x95x95) / Log(2) = bijna 79 bits!

En heb je al eens opgezocht wat de de sterkte van een SHA1 hash in de praktijk is?...
Conclusie: het heeft geen zin om een wachtwoord groter dan 12 á 13 karakters te kiezen omdat veiligheid wordt bepaald door de zwakste schakel. Vanwege het veel grotere aantal collisions zou ik zeggen dat het onverstandig is en een Russische roulette om nog veel langere wachtwoorden te kiezen dan 12 á 13 karakters.
Je zou alleen wel random karakters moeten kiezen, en geen bestaande woorden vanwege dictionary attacks.

Goeroehoedjes

Die begrijp ik uitstekend.
Maar het pigeonhole principle garandeert niet dat je makkelijk een second pre-image van een hash kunt vinden.

Ik heb al geschreven dat er *in de set van erg lange strings* dus veel collisions zitten - dat zijn de vele duiven.
Maar dat betekent helemaal niet dat één lange string veel korte strings heeft met dezelfde output .

Ik probeer niet om 100 duiven uniek in één van de tien hokjes te stoppen .

Ik kies één van de 100 duiven, en laat die in één van die tien hokjes vliegen . Ik moet nog steeds alle hokjes proberen om te zien waar die éne duif is uitgekomen .

Jij lijkt te denken dat als je sha-160 neemt van de volledige Shakespeare (paar miljoen bits) je _erg makkelijk_ tegen een korte input aan zou moeten lopen met dezelfde uitkomst .

Show me - kies een input, zo lang als je wilt . Neem de sha-1 hash. En vind daarna een korte input met dezelfde uitkomst.
(en publiceer dan je baan- en hashbrekende resultaat . Serieus - big time nieuws in de crypto wereld als je dat zou kunnen )

Oftewel - een second pre-image .
En *dat* is de vraag die van belang is voor het vinden van een equivalente input voor jouw lang gekozen password .
Dat is niet makkelijk . *Dat* er een andere input bestaat van 160 bits met dezelfde uitkomst als die ene langere string kun je wel verwachten , maar helemaal niet dat die vindbaar is.

Dat je in de set van alle teksten van een paar miljoen bits veel collisions hebt is een Duh. Maar het vinden van het exacte duplicaat voor één bepaalde input is wat moeilijk is.
Het vinden van tweetal willekeurige inputs met dezelfde hashwaarde is iets anders - ook lastig (orde 2^80 werk), maar dat is niet de vraag voor het vinden van een andere input die bij een gegeven hash uitkomst hoort .


Get real en denk na. Reken uit hoeveel bits van de input ruimte bereikbaar zijn voor een brute force of dictionary attack.
Je kunt maar een extreem klein percentage van de mogelijkheden testen.

Dat is zo, en voor wie echt random letters/cijfers kiest zijn 12+ karakters voldoende.
De primaire reden om langere strings te gebruiken is dat je dan iets hebt wat hopelijk voldoende entropie bevat en toch onthoudbaar is .


Je advies dat lange strings *onveiliger* zijn wegens collisions is volkomen onjuist.

Lang password cq passphrase?
Niet goed genoeg: Two-factor-authentication!

Lastig om aan een smartcard met officiële certificaten te komen?
Het bananen-koninkrijk Der Nederlanden loopt idd redelijk achter in vergelijking met omringende landen, maar toch:
1) Rijkspas
2) UZI-pas (Electronisch Patienten Dossier)
3) Estlandse eID (voor iedereen beschikbaar, internationaal officieel erkend)

De discussie gaat in detail mijn kennis te boven. Maar, kan je zeggen dat de sterkte van welke WiFi key dan ook, dus maximaal 160 bits is? Dat betekent dat alle zinnen t/m 9 willekeurig gekozen woorden uit een woordenboek met 100.000 woorden nog steeds passen binnen die 160 bits (~~100.000^9= ~150 bits).

En als je een ander woordenboek gebruikt (bijvoorbeeld alleen letters&cijfers), je nog steeds gemiddeld 50% van 2^160 (1E24) mogelijkheden moet afzoeken om die ene collision te vinden? Dat is toch precies wat sterkte en brute force betekenen? Wel nieuw voor mij is dat je dan wachtzinnen in theorie kan aanvallen met domme brute force pogingen gebaseerd op (tekens)wachtwoorden.Maar niets weerhoudt Goeroehoedjes dat nog eens te bevestigd te krijgen op een site als https://security.stackexchange.com/questions
Je mag daar namelijk naast vragen, ook bevindingen of theorieën plaatsen.

bijgewerkt: 'je' in de aanhaling verklaard

Ten eerste snap je het pigeon-hole principe kennelijk nog steeds niet.
Met 32 bits wachtwoorden zijn er immers heel veel verschillende wachtwoord-inputs mogelijk, maar beduidend minder verschillende hash-outputs.
Dit betekent dus dat heel veel verschillende wachtwoorden ( van minder dan 32 karakters) tot eenzelfde hash-output moeten leiden. Dit noem ik: collisions. En die heb je dus ontieglijk veel bij zulke lange wachtwoorden.

De extra "natuurlijke" sha1 collisions even buiten beschouwing latend:
Als 210^2 verschillende wachtwoorden moeten worden "omgetoverd" tot 2^160 verschillende hashes,
dan zijn er gemiddeld 2^50 verschillende wachtwoorden die tot precies dezelfde hash moeten leiden!
Reken er dus maar op dat elk wachtwoord van 32 karakters maar liefst 2^50 collisions heeft met andere wachtwoorden.
En dat is gigantisch veel méér dan wanneer je een wachtwoord van 12 karakters gebruikt.

Verder doet het er niet toe dat je nog steeds moeilijk kunt weten welke input er tot één bepaalde output zal leiden.
Wat er nl. toe doet, is of er toevallig één van die enorme hoeveelheid collisions in een brute force hackbare inputrange valt!

Vergis je niet: Met een off-line brute force hack van 2 miljoen wachtwoorden per seconde heb je na één uur al ca. 2^32 verschillende wachtwoorden getest om te controleren of het misschien één van de 2^50 collisions is die óók toegang geeft tot het netwerk. Voor zo'n aanval met die tijdsduur is je wachtwoord van 32 ascii karakters dus nog maar 18 bits sterk.
Maar een wachtwoord van 12 karakters heeft veel minder last van collisions die het wachtwoord verzwakken!
Dát is wat ik bedoel.

(bij voorkeur zal men niet met uitsluitend ASCII karakters "brute forcen", maar met alle mogelijke (256) bytewaarden.
De meeste collisions zullen nl. niet bestaan uit wachtwoorden met enkel en alleen maar ASCII karakters.
Er is dan wel een router-mod nodig die al deze waarden accepteert. (bijv. wachtwoord-invoer in hex-waarden 0 t/m F,
waarbij 2 hexwaarden samen 1 byte vormen))


Voor al diegenen die 32-byte wachtwoorden willen gebruiken hoop ik dat ik het mis heb,
maar zelf ben ik wel overtuigd dat ik mij zal houden aan de regel ca. (16-netwerknaam) = max. wachtwoordlengte.
Inderdaad: netwerknaam kort houden dus, maar ook weer niet té kort of té voor de hand liggend, vanwege de mogelijkheid van het bestaan van rainbowtabellen.

Zoals ik eerder al zei: je weet pas zeker of een heeeel lang wachtwoord veiliger is, als je weet hoe het achterliggende systeem met jouw wachtwoord omgaat!
En WPA2 is dus een typisch voorbeeld waarbij erg lange wachtwoorden m.i. niet zinnig zijn, en niet zonder risico.
Random SSID van 3 of 4 karakters, en random wachtwoord van resp. 13 of 12 karakters lijkt mij vooralsnog het beste
om het aantal collisions (die je wachtwoord verzwakken) tot een minimum te beperken en toch een redelijk goede beveiliging te hebben.

Goeroehoedjes

Gegeven een willekeurige hashfunctie (met als resultaat een afgeleide van de input waarbij dat resultaat een vaste lengte heeft) en een willekeurige input, zijn er altijd oneindig veel andere inputs die hetzelde resultaat (dezelfde "hash") zullen opleveren.

Als je je een hashfunctie met een resultaatlengte van 1 bit voorstelt (pariteitsbit of een bitpositie naar keuze uit het resultaat van een willekeurige hashfunctie), kun je inzien dat, ongeacht de lengte van de input, je ongeveer 50% kans hebt op een "1" en op een "0" als resultaat (hierbij hashfuncties met een bewust ingebouwde bias buiten beschouwing latend (is dit correct NL of moet het toch een 't' zijn?)).

Bij een hashfunctie met een resultaat van 2 bits "lengte" (resultaat dus 0, 1, 2 of 3) is een kortere input (wachtwoord bijv.) mogelijk dan de lengte van de hash, namelijk 1 bit. Zelfs dan bestaat al de kans op een collision, d.w.z. dat beide mogelijke inputs (0 en 1) dezelfde hashwaarde opleveren (0, 1, 2 of 3). Met name bij een cryptografische hashfunctie, waarbij de output zo onvoorspelbaar mogelijk moet zijn op basis van de input, is dit het geval (bij een CRC-achtige hash, bedoeld om niet-opzettelijke beschadigingen te detecteren, wil je dat juist niet).

Conclusie: bij een perfecte cryptografische hash en 2 verschillende wachtwoorden is de kans op een collision onafhankelijk van de lengte van die wachtwoorden.

P.S. Niet ondenkbaar, maar wel heel sneu, is het als je een wachtwoord zoals "Mijn faVoriet3 vaKantie wa$ in Peru" maar ook iets als "$6fW&%0x" kiest en jouw wachtwoord toevallig dezelfde hash oplevert als "12345" of "Welkom01" zou doen. Hoe langer de hashlengte en hoe cryptografisch beter de hashfunctie, hoe kleiner de kans daarop natuurlijk is.

Dat heb ik toch niet ontkend ?
Ga nou eens nadenken over wat ik schrijf.

En probeer nou eens het verschil te begrijpen tussen _de set van wachtwoorden van lengte 32_ en "een enkel 32 karakter lang password"

En denk nou eens na waarom het publiceren van de hash van een dvd image van gigabytes groot *toch* een uitstekende manier is om een download te valideren .
Omdat er geen bruikbare manier is om een andere input te vinden die dezelfde hash heeft .

*ondanks* dat er een collision bestaat . En dat in de set van alle mogelijke images ter lengte van gigabytes inderdaad erg veel collisions zullen zitten.



Who cares ?
Je hoeft je niet eens te beperken in lengte . Als je de lengte nog langer maakt , kun je wel garanderen dat er nog meer inputs zijn die colliden .
In de set van DVD-lengte-files (4GB , 2^2^32 unieke images ) zijn nog veel meer onderlinge collisions .
So ?
Dan zou het makkelijk moeten zijn een ander image te vinden met dezelfde sha1 als redhet7.iso ?

Nope.

Het gaat er niet om dat er in een voldoende grote input ruimte gegarandeerd hash collisions bestaan, het gaat erom dat het *vinden* van een second pre-image (=input met gegegeven output) onmogelijk is.

Nee - de hele definitie van een hash kraken is het vinden van een input met een gegeven hash uitkomst.
Dat is wat moeilijk moet zijn.
En die zoekruimte /work factor is dus orde 2^160 .


Je brute force bereik is in de orde van 50-70,80 bits in het beste geval .

Je denkt dat dat je meer kansen op prijs krijgt omdat er veel langere inputs bestaat die noodzakelijkerwijs een collision moeten hebben .
Dat ze bestaan maakt ze niet makkelijk(er) vindbaar .

Zelfs als jij je wel beperkt tot 13 karakters, mag een aanvaller best een 40 byte input gebruiken - als die toevallig vindbaar/construeerbaar zou zijn .


Wordt je ook zenuwachtig van alle public key gebaseerde signatures ?
Dat zijn hashes van een relatief lang bericht (duizend+ bits lengte) , waarvan de hash waarde (gecrypt met de secret key van de verzender) de signature vormt.

Het makkelijk vinden van andere berichten (ssl certificaten, dvd images, updates) met dezelfde hash waarde zou een heel serieus probleem zijn - in jouw model zie je dat als risico .

Bedankt voor je reactie Erik, en "latend" moet wat mij betreft kunnen. Of misschien "latende"?... c|;-)
In elk geval een stuk beter dan latent (=verborgen, onzichtbaar)

Maar eh... ben je het met me eens dat een WPA2 wifi wachtwoord van 32 karakters bijna nooit veiliger is dan een
wachtwoord van laten we zeggen 14 á 16 willekeurig gekozen ASCII-karakters?
(deze keer uitgaande van de 96 wachtwoordbepalende bits (verkregen m.b.v. WPA2 - "multiple hash goocheltruuk")
die men uit de ether moet vissen om een off-line attack op het wachtwoord te kunnen (laten) doen).

Misschien hoeft een wachtwoord van 32 karakters niet per sé onveilig te zijn,
maar is niet veiliger dan zijn bijna onvermijdelijke collision met een wachtwoord dat minder karakters heeft lijkt mij,
omdat een botsend wachtwoord met minder karakters immers eveneens toegang geeft tot het wifi-netwerk.

Goeroehoedjes

Ik raad je aan om je eerst flink te verdiepen in de werking van WPA2. Dat is nog best lastig, zeg ik je uit ervaring.
Zo weet ik dat men tijdens de WPA2 handshake geen 160 bits maar 96 bits uit de ether opvangt,
om daarmee m.b.v. een off-line brute force attack het oorspronkelijke wifi-wachtwoord te kunnen bepalen.

Op die grond zijn er dus in principe 2^96 verschillende wachtwoorden mogelijk, én al hun collisions.
Ik weet niet zeker of SSID dan nog ergens meebepalend is voor die 96 bits. Afhankelijk van hoe die vork in de steel zit
zou dat nog wat uit kunnen maken.

Men roept wel vaak:"hoe meer karakters, des te sterker het wachtwoord".
Waarom? Omdat je met meer karakters meer verschillende wachtwoorden kunt vormen. (dit aantal stijgt drastisch met het toenemen van het aantal bits, want dit gaat exponentieel)
En naar mate er meer wachtwoorden mogelijk zijn, wordt het uiteraard steeds moeilijker om een wachtwoord te raden.
Vandaar.

Maar als er hashes in het spel zijn gaat dit op den duur naar mate wachtwoorden langer zijn niet meer op!
Een hash heeft immers maar een beperkt aantal uitgangen. Deze hash is kenmerkend voor je wachtwoord.
Je kan de boel met je wachtwoord daarom nooit sterker maken dan de beperking die voornamelijk wordt bepaald door het aantal bits van de toegepaste hash. Bestaan er dus zoals kennelijk bij WPA2 2^96 mogelijke wachtwoordhashes,
dan staat dat voor 2^96 mogelijke wachtwoorden. (maar met een wachtwoordcollision kan je ook inloggen)

Als je begint met wachtwoorden van 1 karakter, vervolgens 2,3,4 karakters etc., dan heb je dus bij ca.15 karakters
zo langzamerhand wel 2^96 mogelijkheden gehad. Wachtwoorden die nog langer zijn, en vrijwel zeker alle wachtwoorden met een lengte van 32 karakters, moeten dus wel botsen met een wachtwoord met veel minder karakters.
Daarom zijn wachtwoorden van 32 karakters gemiddeld niet veiliger dan een zelf verzonnen fancy wachtwoord
van bijv. 16 karakters dat alle woordenboek aanvallen kan doorstaan.
Of wachtwoorden van 32 ASCII karakters onveilig zijn, valt reëel misschien dan nog wel wat mee.
Maar als je op grond van je wachtwoord 210 bits sterkte verwacht, en in werkelijkheid is het hooguit 96 bits sterk,
dan valt dat wel even tegen...

Goeroehoedjes

Ik denk dat anoniem gelijk heeft. En wel:
- Uit het ongerijmde: anders was dit WPA2 'issue' (meer een vraag) allang op Internet gepubliceerd.
- Door de redenering: collisions ja, maar 'vind die duif maar'.
- Bij de redenering als 'misschien is de hash van een lange zin wel gelijk aan die van een zeer kort wachtwoord', ontbreekt de kansberekening. Ook bij een slimme brute force aanval op een normale hash kan de eerste poging de juiste zijn. Maar de kans is uit te rekenen en zeer klein bij een lang wachtwoord.
Ik vond wel als aardigheidje dat sommige (PBKDF2 !) collisions gemakkelijk te genereren zijn , zie:
https://crypto.stackexchange.com/questions/15218/is-pbkdf2-hmac-sha1-really-broken

Maar tot nu toe is buiten de discussie gebleven dat bij PBKDF2, niet het password wordt gehasht, maar het zout+teller ! Het password is de (secret) key voor HMAC binnen PBKDF2, zie:
PBKDF2 uses HMAC-SHA1 to generate keys, but what is the key for the HMAC? https://crypto.stackexchange.com/questions/10164/pbkdf2-uses-hmac-sha1-to-generate-keys-but-what-is-the-key-for-the-hmac?rq=1
en voor WiFi https://crypto.stackexchange.com/questions/28975/encryption-algorithm-used-in-wpa-wpa2

Ook nog interessant vond ik hoe WPA2 256 bits keys genereert, via PBKDF2. (wel met 'sterkte 160'):
https://stackoverflow.com/questions/14394803/how-can-pbkdf2-using-hmac-sha-1-return-more-than-20-bytes?rq=1
Hiervoor wordt de (iteratie) counter gebruikt die achter het zout geplakt wordt (er is dus geen device code)

Ik zie geen reden mijn lange wachtzin voor of mijn 10 tekens lange SSID aan te passen.

=== toegevoegd ref naar WIFi en iets betere beschrijving 'misschien'

Excuus voor het late antwoord, ik ben momenteel erg druk met m'n nieuwe baan + familiezaken.

Als 14 karakters een entropie biedt van 96 bits of meer en de karakterreeks onvoorspelbaar random is gegenereerd, heb je gelijk (ik heb dit nu even niet uitgerekend, hangt natuurlijk af van welke verschillende karakters je toestaat). Het is inderdaad "bijna nooit" omdat je altijd een (zij het extreem kleine) kans hebt op een collision met een hash (of ander type verhas(p)peling [1]) van "12345" of "admin".

Echter, als dat 14-karakter wachtwoord door de routerfabrikant op herleidbare (bij aanvallers bekende) wijze uit het uitgezonden MAC-adres is afgeleid of door een voorspelbare random number generator is gegenereerd, is dat wachtwoord hoogstwaarschijnlijk niet veiliger dan iets wat je zelf bedenkt.

En iets wat je zelf bedenkt is veel makkelijker door familie en vrienden over te nemen als het uit woorden bestaat die zij "blindelings" kunnen invoeren, bij voorkeur gescheiden door wat random leestekens (bijv. "Zingend+dood+vogeltje?"). En om zo'n wachtwoord veilig te krijgen moet het langer zijn dan jouw theoretisch kortst mogelijke, maar nauwelijks foutloos over te nemen, random wachtwoord.

Zoals wel vaker is mijn antwoord dus ja en nee :-)

[1] Verhaspelen kon wel eens een aardig woord zijn om aan een Nederlandstalige leek uit te leggen wat een "hash" is. Rekenkundig vind ik mod 10 (rest na deling door 10 met gehele getallen) een aardige uitleg van een niet-cryptografische hash; het resultaat is altijd 1 (decimaal) cijfer "breed".

@Anoniem Als je de verkeerde vraag stelt, krijg je een antwoord op die verkeerde vraag.

De vraag had moeten zijn:
Maar eh... ben je het met me eens dat een WPA2 wifi wachtwoord van 32 willekeurig gekozen ASCII-karakters bijna nooit veiliger is dan een wachtwoord van laten we zeggen 14 á 16 willekeurig gekozen ASCII-karakters?

Die vraag wil ik ook wel proberen te beantwoorden ;-)

Het heeft geen zin om een cryptografisch random wachtwoord te genereren dat langer is dan de entropie waarmee de afgeleide van dat wachtwoord wordt opgeslagen.

Kwaad kan dit, voor zover ik weet, echter niet (anders dan dat je pijn in je vingers kunt krijgen van het intikken van wachtwoorden die langer zijn dan strikt noodzakelijk en/of dat functies als Scrypt en PBKDF2 onnodig wat langer aan het crunchen zijn met als gevolg dat je iets langer moet wachten voordat je bent geauthenticeerd). M.a.w. ik ken geen steekhoudende argumenten waarom een langer-dan-zinvol wachtwoord onveiliger zou zijn dan wachtwoorden die net lang genoeg zijn.

Gevoelsmatig denk ik dat langere wachtwoorden iets veiliger zijn, want het is de vraag of je met een wachtwoord dat precies lang genoeg is, alle mogelijke afgeleide waarden kunt afdekken (hoe langer, hoe meer "coverage" vermoed ik). Maar dat kan ik niet onderbouwen.

Dank je,ondanks de drukte toch een antwoord. Het punt is dat bij WiFi/WPA2 je de lengte van het door WPA2 gebruikte wachtwoord voor een deel niet in de hand hebt. Dit omdat zout (SSID) en een iteratie teller (32 bits) op de een of andere manier worden toegevoegd aan je gekozen sterke wachtwoord (min. 22 tekens volgens te 802.11). Over de manier van toevoegen is hier geen geen duidelijkheid/overeenstemming. WPA2 zou voor de hashing dan gebruik maken van een langer wachtwoord met een entropie van > 160 bits.

En WiFi/WPA2 doet daar nog een schepje op door van een 160 bits SHA 1 hash een 256 bits key af te leiden via PBKDF2. Mogelijk is dat laatste te verklaren om compatibility te houden voor het geval van een 256 key. Een gebruiker kan kiezen een 256 bits key te gebruiken door 64 hex tekens als WiFi key te geven. In dat geval wordt hashing etc.niet toegepast.

Als ik jouw antwoord samenvat: voor zover je weet kan dat langere wachtwoord geen kwaad. 'Anoniem' is van het tegendeel overtuigd, vandaag de vraag.

Of WPA2 netto wat minder dan de volle 160 bits gebruikt doet er niet toe voor de discussie of langere wachtwoorden onveiliger zijn omdat het aantal collisions zou toenemen .

Ik betwijfel overigens of je gelijkt hebt over die 96 bits - ben je niet in de war met een tcpdump capture van 96 _bytes_ ?
De PBKDF2 die WPA2 gebruikt expandeerd uiteindelijk naar een 256 bit sleutel , met een sha-1 gebaseerde hmac .

Ik denk dat je ongelijk hebt over de netto ruimte van WPA2 - gezien de andere dingen die je stellig beweert en zeker onjuist zijn, zou ik hier ook graag een referentie voor zien.

Uit http://crypto.stackexchange.com/questions/28975/encryption-algorithm-used-in-wpa-wpa2 , en https://en.wikipedia.org/wiki/IEEE_802.11i-2004 kan ik geen 96 bit limiet halen.


Waar een hash goed voor is, is het extraheren van entropie uit willekeurig lange input .

Dat kan niet _meer_ zijn dan de lengte van de hash , maar het 'kiezen' en 'onthouden' van een x aantal random bits gaat makkelijker wanneer die entropie in een wat langer woord of zin zit .

Diceware , vaker genoemd op dit forum is daar een structurele manier voor - je zou de uitkomst van al je dobbelsteen worpen 'direct' kunnen onthouden , als een getal of als serie bytes, en toch maak je er een serie woorden uit een bekende lijst van - de zin wordt een stuk langer, maar bevat uiteindelijk 'slechts' de entropie van je serie dobbelsteen worpen .
Een goede hash behoudt die entropie .


Dat is een hele terugtocht van je stelling dat een langer wachtwoord _onveiliger_ zou zijn dan een wachtwoord ter lengte van de (netto) hash .

Ik heb hier niemand zien betogen dat een 32 byte wachtwoord (256 bit) , gebruikt op basis van een 160 bit hash _meer_ dan 160 bit 'security' zou opleveren .
_Jij_ hebt betoogd dat een 32 byte wachtwoord _minder_ security zou opleveren dan een ~20 byte wachtwoord 'wegens meer collisions' .

Ik heb _wel_ betoogd mensen die een passwoord moeten kiezen en onthouden meer kans hebben om ~160 bits entropie te
halen bij een langere passphrase dan wanneer ze een korte moeten kiezen en onthouden.

En natuurlijk is iemand die 20 echt random karakters kiest beter af qua security dan iemand met een lange maar bekende volzin ('In den beginne schiep..' ).

betreft: https://www.security.nl/posting/490722/Expert%3A+Gebruik+wachtwoord+van+minstens+32+karakters

Ha, antwoorden, fijn! :-)
En meer vragen en kritiek ook?... Terecht!
Hier mijn nieuwe bijdrage over dit onderwerp:

Uit: http://www.faqs.org/rfcs/rfc2104.html:
"The cryptographic strength of HMAC depends on the properties of the underlying hash function."

Een hash met HMAC berekenen doet men als volgt: H(K XOR opad, H(K XOR ipad, text)).

Hierin is "H" de gebruikte hashfunctie. Dus in geval van HMAC.SHA1 zoals gebruikt in PBFKDF2 (in WPA2):
(waarbij K wordt verondersteld het wachtwoord te zijn, en "text" de SSID, zie:
http://stackoverflow.com/questions/2465690/pbkdf2-hmac-sha1, krijgen we dan dus:

SHA1(password XOR opad, SHA1(password XOR ipad, SSID))

Uiteindelijk is HMAC-SHA1 dus ook maar gewoon een ordinaire SHA1 hash van één of ander "door elkaar geschud" gegeven. Voor verkrijgen van maximale security:
"In any case the minimal recommended length for K is L bytes (as the hash output length)"
(dit geldt in ieder geval voor een enkele HMAC-hash, maar levert mogelijk ook de sterkste PSK-waarde in WPA2 op(?))

Ik kan niet geloven dat door de hash een flink aantal malen te herhalen er opeens een PSK met sterkte 256 bits uitrolt.
(ik heb nl. de laatste financiële crisis meegemaakt met zijn obfuscerende derivaten...) ;-P
Laat ik het dus liever houden op een sterkte van 80 bit die "obfuscerend verdeeld zijn" over de 256 bit PSK.
Als iemand weet dat het heel anders is, dan hoor ik graag zijn (of haar~?) wijs bewijzend betoog.

----------------------------------------------------------------------------------------------------------------------------------------------------------

Voor wat betreft mijn bericht van 14-11-2016 00:43 : dit klopt inderdaad niet helemaal.
In mijn herinnering stond 96 bit, maar specifiek gaat het bij WPA2 over een MIC (Message Integrity Code) van 128 bit.
Bij WPA(1) is de MIC 64 bits; ik zat er dus met mijn 96 bits precies tussenin.

Om de MIC uit te rekenen wordt ook met HMAC.SHA1 gehasht, dus neem 128 bits maar weer met een bus zout.
Maar voor zover ik weet zijn er bij WPA2 geen wachtwoorden bekend met botsende MIC's.
Dus voor het grootste deel klopt het verder wel. Lees bijv.:
http://security.stackexchange.com/questions/66008/how-exactly-does-4-way-handshake-cracking-work:
stap 5: Computed MIC is compared to the MIC obtained at step 1.
If they match then candidate password is reported as correct.

Dat heb ik eerder inderdaad totaal verkeerd gedacht.
Sterker nog: geen 20 maar ik had eerder zelfs beweerd dat (16 - SSID-lengte) karakters veiliger is, en 3 of 4 chars.SSID.
Was toen nog onwetend dat kleinere wachtwoorden ook vele collisions hadden. Die zitten van nature al in SHA1.
Verder verkeek ik mij op de grote getallen, en kon ik destijds niet achter de exacte "salt" methode van SSID komen.

Een eye-opener was opeens dat elk wachtwoord gemiddeld wel ca. 2^80 collisions moet hebben!
Want 2^160 is een immens groot getal.
M.a.w.: het blijft zoeken als een speld in een hooiberg om van de 2^80 collisions in de hooiberg één te vinden.
Het is wel een hooiberg die ca. 2^80 keer zo groot is dan die 2^80 collisions van dat ene wachtwoord...(!!!)
De kans is daarom hoe dan ook ca. 1 op 2^80 per trial dat je een collission van een bepaald wachtwoord vindt.

Zelfs zware brute force attacks kunnen hier weinig mee, tenzij je bijzonder korte of gemakkelijk te raden wachtwoorden
zou kiezen. ("dictionary attacks")
Brute force attacks van honderdduizenden of zelfs miljoenen wachtwoorden per seconde hebben bijna geen kans
om binnen afzienbare tijd een origineel sterk wachtwoord met een sterkte van 80 bits te kraken.
Zeg nooit: "Nooit". Maar als het toch wordt gekraakt zou dat wel héééééééééél toevallig zijn:
1 miljard state-of-the-art WPA2-crack machines zouden daar gemiddeld 10 jaar mee bezig zijn!

Het zijn bijna altijd onze creatiefloze, te korte of te voorspelbare wachtwoordkeuzes, die maken dat het relatief
toch nog vaak lukt om een wachtwoord met een brute force dictionary attack succesvol te kraken.
En een toevallige collision van het wachtwoord binnen een "kraakbare" range van minder karakters is in theorie wel mogelijk, maar is veel onwaarschijnlijker dan ik eerst dacht. Het heeft nauwelijks invloed: te verwaarlozen.

Volgens mij is 13 random karakters al heel erg moeilijk om te kraken. log(95^13)/log(2)= ca. 85 bits
Bij de oorspronkelijke officiële WPA aanbeveling van 8-63 karakters is 8 karakters nu wel erg aan de lage kant
vanwege de sterke brute force mogelijkheden, waar ontwerpers oorspronkelijk geen rekening mee hadden gehouden.
Neem dus liefst 13 of meer karakters. Met 20 karakters zit je helemaal veilig.
Groter mag, maar heeft weinig zin, tenzij je je wachtwoord uit een nogal beperkt aantal karakters wilt kiezen.

Ik hoop dat u allen het hier nu wel grotendeels mee eens kan zijn,
maar als het toch weer heel erg anders blijkt te zijn, dan eet ik mijn hoedjes op! ;-)


Goeroehoedjes.