Pfffff, alweer????? (zie: vrijdag 13 mei. 14.18 uur.

Beide niet, aangezien ze nu openbaar zijn.

Wat denk je te bereiken met het antwoord ?

We hebben hier om de zoveel tijd een gezellige neuzeldiscussie over een heel klein en mooi definieerbaar stukje security , namelijk de brute-force/dictionary bestendigheid van (de hash van) een string van <n> karakters uit een alfabet van <m> tekens , en meestal met de aanname dat elk karakter met uniforme waarschijnlijkheid gekozen is.

Rondom je vraag moeten we vermoedelijk ook de aanname doen dat er sprake is van het nemen van de hash van deze wachtwoorden, en dat het aanvalsmodel gaat om een aanvaller die over de hashes beschikt, oneindig vaak mag testen, over aannemelijke tot ongelofelijke hoeveelheden rekenkracht beschikt en dan probeert deze wachtwoorden te raden.

Als je wat wijzer wilt worden over dit onderwerp, ga dan zelf

1 - klein beetje wiskunde leren over combinaties/permutaties (havo/vwo niveau)
2 - download en bestudeer een (open source) password cracker, en ga kijken hoe de kandidaat-wachtwoorden gegenereerd worden .

Als je 2 gedaan hebt, kun je een wat beter natte-vingergevoel krijgen voor de reikwijdte van een dictionary search .
( (1) geeft je houvast voor de bovengrens zoekruimte op basis van brute force en (2) over wat je sneller/efficienter kunt doen om wachtwoorden die mensen typisch kiezen te vinden, en waarbij je dus 'vaak' wachtwoorden vindt van een lengte die met brute force onbereikbaar is, )

Nee haha ik gebruik deze wachtwoorden uiteraard niet maar iemand heeft aan mij gevraagt welke wachtwoordgenerator website het beste is ( ik zou nooit zoiets doen ) Maar daar kwamen deze 2 uit dus ik vraag welke heeft een betere wachtwoord

Compleet onzinnige vraag. Gebruik je het wachtwoord in een router met een lek in de WPS dan kun je het zo lang maken als je wil, het komt er toch uit. Gebruik je het bij een slechte organisatie zoals bijvoorbeeld "replacedirect.nl" (zie berichtgeving in de media) dan kun je je wachtwoord 64 karakters maken, maar die lui onderhouden d'r boeltje zo slecht dat hackers er met exploits in kunnen breken. Gebruik je het in een RAR file dan zal het wel sterk zijn. Belangrijkste is dat je niet overal hetzelfde wachtwoord gebruikt en dat het niet eenvoudig te social engineren is (je hond heet Bob en is 12 en je wachtwoord is bob12).
De vraag is net zo onzinnig als de vraag:"Wat is een betere auto, een Lamborghini of een Fiat500. Als je wil gaan racen zou ik de Lamborghini nemen, als je in een parkeergarage in Amsterdam wil gaan parkeren zou ik de Fiat 500 nemen ;)

Je zal eerst moeten defineren wat beter is. Is de een beter als de ander, hij moeilijker te raden is, moeilijker af te kijken, moeilijker te bruteforcen. Beter kan ook zijn om te onthouden, op te schrijven, in te typen met 1 hand.

@21:26: Als je echt conservatief bent, gebruik je de RNG van GnuPG. Dat is een van de oudste en meest gepeerreviewde random number generators die je kunt vinden. Verder zou ik een een dobbelsteen gebruiken (te verkrijgen bij speelgoedwinkels).

Ik gebruik GnuPG 1.4.x met de -e en -a optie:
https://www.gnupg.org/faq/gnupg-faq.html#common_commands
https://www.gnupg.org/faq/gnupg-faq.html#ascii_armor

Eerst moeten we een GPG sleutel genereren (ik gebruik hier Ubuntu, maar onder Windows werkt het ook):

De passphrase op deze key mag vergeten worden en zeer complex zijn. Denk er wel aan dat de overheid in de toekomst misschien om deze passphrase kan vragen, dus maak het ook weer niet te complex zodat die niet meer te achterhalen is (met brute force eventueel door dezelfde overheid).

Nu moeten we iets encrypten (maakt niet uit wat omdat de session key random zal zijn en bij elke encrypt de resulterende ascii-armor weer anders zal zijn hierdoor). Ik gebruik een willekeurige .exe hiervoor:

We hebben nu een .asc bestand aangemaakt waaruit ik met de dobbelsteen een wachtwoord zal kiezen. Belangrijk! Het begin en het einde van de .asc file zijn niet random. Het midden wel.

Ik begin op een willekeurige plaats in de .asc file en gooi hierna 8 keer met de dobbelsteen (
6 3 6 5 3 2 3 1). Na elke keer gooien ga ik 1 tot 6 posities naar rechts. '+' en '/' sla ik over. Alle hoofdletters, kleine letters en cijfers worden ongeveer even vaak gebruikt bij ascii-armor.

Ik krijg nu het wachtwoord 'yjuB4J57O'. Als je vindt dat er te veel cijfers in zitten, gooi je opnieuw met de dobbelsteen. Net zolang tot het wachtwoord aan je eisen voldoet.

Je moet oppassen met 0 en O en met 1, l en I. Deze kunnen op elkaar lijken.

Het is ook belangrijk om de .asc file op een veilige manier te wipen en te zorgen dat die niet in Windows Search of de cloud terecht komt. Bij een SSD kan dit problematisch zijn.

Mijn advies is om het resulterende wachtwoord op te schrijven of uit te printen. Tenminste tot je die zo vaak gebruikt hebt dat je die uit je hoofd kent. Bewaar dit papiertje niet bij je computer maar verberg die ergens waar inbrekers deze niet kunnen vinden. De entropie van een enkel teken uit [0..9][A..Z][a..z] is 2log(10+26+26) => 5,954 bits. Je wilt waarschijnlijk iets van 80 bits per wachtwoord voor belangrijke zaken (zoals een masterpassword of je Steam account). Misschien iets van 128 bits voor het wachtwoord op WPA2 bij je WiFi (hoef je maar een keer per apparaat in te tikken).

Van leestekens ben ik niet zo'n fan omdat die kunnen leiden tot wachtwoorden als ë?123 in plaats van "e'c123 zonder dat je kunt zien dat dit gebeurt omdat je alleen *** ziet op je scherm.

In het algemeen kun je zeggen dat computers die als server opereren niet geschikt zijn voor het genereren van wachtwoorden omdat die te weinig entropie hebben.

[knip ontzettend omslachtige manier om via gpg encryptie van een file uiteindelijk de gpg sessie key en aes als RNG te gebruiken, en daar weer met een dobbelsteen wat letters uit te kiezen.

Ik heb twee technische zorgpuntjes waarvan ik niet meteen durf te zeggen dat ze geen probleem zijn .
1 - ik weet niet direct [en had geen zin om het op te zoeken] of de gecrypte output van gpg mogelijk wat header/block structuur bevat . Dat zouden mogelijk wat voorspelbare bytes op bepaalde plekken zijn.
Zolang die onafhankelijk zijn van de inhoud van de gecrypte data is het geen zwakheid in GPG, maar wel een zwakheid wanneer je de gecrypte output wilt gebruiken als random data .
Theoretisch : stel dat de eerste 16 bytes altijd GPG_V1.0_AES_SHA zijn , dan zijn die bytes niet bruikbaar als random data.
De feitelijke content (aes output ) is wel statistisch random .
Idem als de file een vorm van blokstructuur heeft waarbij elke 256 bytes er een setje bytes volgen die een blok-volgnummer bevatten .

Analoog : Als je een *file* vol random data op een harddisk schrijft, en je gaat daarna werken met een _image dump_ van die harddisk .

Het merendeel van de data in de image dump zal dan de random content zijn van je file, maar daartussen zit de normale en beslist niet random structuur van file system meta data.

Is dat het geval bij gpg files ?
Ik weet het niet.
De constructie houdt er niet expliciet rekening mee, en de poster heeft er geen woord over gezegd.


2 - Ik twijfel ook of base64 letters geen correlatie hebben met buren tot afstand 4 .
Base64 doet een mapping van 3 bytes op 4 letters . Gemiddeld over de file zal bij random input de verdeling wel glad zijn, maar ik twijfel of er geen correlatie en afwijkende frequentie zit tussen letters en hun opvolgende buren .

Wellicht dat de aanbevolen dobbelsteen dat weer mitigeert, maar het heeft _alle_ kenmerken van een hobbyisten constructie, en als je nou toch probeert de crypto/random echt goed te doen zou ik dat vermijden .
Is het daardoor kraakbaar / raadbaar - weet ik niet - maar ik

M.i. kun je beter 32 bytes output van /dev/random op een linux systeem nemen . Dat geeft je 256 bits pure entropie.
Je kunt er direct de base64 output van nemen om het om te zetten naar een printbare string, of een sha2-512 hash, eigenlijk ook alleen om een vast en printbaar output formaat te krijgen.

[knip gpg constructie]

Dat is in zijn algemeenheid niet juist. De linux /dev/random generator heeft beschikbaar over meer bronnen om entropie uit te oogsten dan alleen user input .
Het zijn met name net opgestarte embedded systemen, zeker degene zonder hardware rng in de cpu waar het verzamelen van voldoende entropie wel een echt probleem is .
(denk settop boxen, wifi routers e.d. die entropie nodig hebben voor ssh/ssl keys )

De beste manier om _goede_ antwoorden te krijgen is het posten van foute informatie....

Beide wachtwoorden zien er lekker complex uit, maar dat zegt niets over de entropie van het wachtwoord. Het is mogelijk dat site A iedere keer dezelfde string oplepelt (of een zwakke 16 bits PRNG gebruikt) terwijl site B gebruik maakt van een entropiepool van 1024 bits, regelmatig gemengd met timing data uit de kernel.

Hazewindenhondenlullenlerentasje_1mafkees , gemakkelijk te onthouden en veilig.

Volgens deze site: https://howsecureismypassword.net/
It would take a computer about

586 SEPTENDECILLION YEARS
to crack your password

Your password is over sixteen characters long.
Never forget your long, secure password by using a password manager


Jouw eerste password slechts 19 SEPTILLION YEARS en het tweede password 13 DECILLION YEARS

Er vanuitgaande dat niemand weet hoe je tot je wachtwoord bent gekomen:

)HOyPkvx=-XQ^!x*![=N)Lf'SjE
Lengte: 27 karakters
Hoofdletters: ja
Kleine letters: ja
Cijfers: nee
Herkenbare combinaties: nee

D3U@oP6j66*Ef##H6$@*8Eb
Lengte: 23 karakters
Hoofdletters: ja
Kleine letters: ja
Cijfers: ja
Herkenbare combinaties: nee

Het lijkt er dus op dat randomgenerator 1 geen cijfers gebruikt.
Dit maakt het wachtwoord zwakker.
Maar het is 4 karakters langer, en dat maakt het juist weer sterker.
Als je het gaat uitrekenen, maakt dit de verzwakking wegens het gebrek aan cijfers meer dan goed.
)HOyPkvx=-XQ^!x*![=N)Lf'SjE blijkt dan duidelijk sterker,
zelfs als een aanvaller zou weten dat er geen cijfers in voorkomen!

(maar zoals al gezegd: beide wachtwoorden zijn nu superzwak, omdat ze op internet gepubliceert zijn...)

Goeroehoedjes

@13:52:
Bij punt 1: Helpt dit? Anders is er altijd nog de officiële RFC..


Bij punt 2: Of je een zeer lange reeks van random nullen en enen nu in groepjes van 8 bits of 6 bits weergeeft, zal mijns inziens niet uit maken. Mocht je gelijk hebben, dan zou ascii-armor voor pgp nog verder gecomprimeerd kunnen worden voor e-mail dan nu het geval is.

Ja Taxus, dat is heel nuttig ...... de kennis van anonieme respondenten ;)

Het feit *dat* gpg die metadata kan laten zien bewijst natuurlijk dat er inderdaad wat relatief voorspelbare data in de file erbij zit, en dat niet *alle* output bytes van een gecrypte gpg file random zijn .
Dat er minimaal een header voorzit wist ik ook wel.

Zoiets mag je _echt niet_ serieus voorstellen als heel erg veilige random bron .
Ja - de gpg random generator is erg goed gedaan . Maar alle garanties daarvan vervallen als je behalve het resultaat ervan ook een hele berg beslist-niet-random plaintext _ook_ gebruikt .
Er zijn wel manieren om entropie van meerdere bronnen te mixen zodanig dat je geen entropie verliest, maar dat was niet te zien in deze constructie .

Beschouw dit als een voorbeeld dat crypto bouwen _niet voor amateurs_ is .
Iets verzinnen wat je zelf erg ingewikkeld vindt en geen aanval voor kunt vinden kan vrijwel iedereen.
Iets verzinnen waar ook echt geen aanval voor _is_ , is heel andere koek .

Als je dat wilt leren moet je een studie met veel wiskunde en cryptografie gaan doen. En vooral heel veel andere algorithmen analyseren . En breken . Alleen dan krijg je wat inzicht en gevoel voor dingen die wel of niet veilig zijn.
Veel constructies verzinnen is niet zo nuttig - je ziet je eigen fouten toch niet, en het aantal mensen dat ze voor je kan (en wil) aanwijzen is vrij beperkt .

Vergelijk het met (veilig/secure) programmeren - wat je moet vermijden snap je vooral als je veel tijd besteed hebt aan het reverse engineeren en pentesten van andere code .

Op crypto gebied ben ik overigens ook op z'n best een redelijke amateur - net goed genoeg om hier een hoop risico's te zien, en enigszins bekend met de standaard literatuur .

[knip gpg detail output]


Dat is misschien te kort door de bocht . De mate van compressibiliteit is wel enigszins een indicator voor entropie, maar niet zo heel goed.
Bot voorbeeld , de output van een vrij slechte rng zal door een compressieprogramma toch niet gecomprimeerd worden.
Je kunt makkelijk correlaties en bias hebben in data welke niet door een compressieprogramma benut worden .

Wat ik me afvroeg is of bij base64 (e.a.) mogelijkerwijs sommige karaktercombinaties niet kunnen voorkomen, en er dus een frequentie bias zou zitten op bepaalde karakters of karaktergroepen .

Afgezien van het padding karakter (= ) _denk ik _ nu dat dat niet het geval is, omdat 4*6 = 3*8 .
Oftewel , het lezen van een groep van drie bytes als vier 6-bit getallen komt precies uit .

@21:33: Een vlugge google search vertelt mij dat AES256 bestand is tegen plain-text attacks. Ik hoef dan ook geen AES256 te ontwerpen, alleen maar toe te passen. En dan nog niet eens in programmeer code.

Zelf heb ik veel minder vertrouwen in password managers (behalve misschien die van Bruce Schneier). En zeker niet in websites die een wachtwoord voor je genereren! Zo'n website kan namelijk al zijn entropie kwijtraken bij zware belasting (bijvoorbeeld bij een DDoS op hun SSL pagina). En je wachtwoord wordt dan voorspelbaar voor een aanvaller als de NSA. Ook moet je de hardware RNG van Intel maar net vertrouwen. Je kan niet even de CPU open schroeven om te kijken of er geen rare (voorspelbare micro-) code in zit. Ook moet je zo'n wachtwoord site maar vertrouwen, dat ze geen kopietje maken van je nieuwe wachtwoord en naar de AIVD doorsturen.. Had onze overheid niet een wachtwoord generatie site een paar jaar geleden? Ook weer met de verplichte leestekens erin?

Ik had bij mijn eerste post nog moeten vermelden dat je met [Ctrl]-[C] het commando 'cat' kan stoppen. Anders gaat die wel een hele tijd door met scrollen. Het probleem met bijvoorbeeld Word is dat die je .asc file gaat opslaan op je harddisk (of erger; in de cloud). Het is moeilijk om dan nog je gegenereerde wachtwoord te achterhalen (~100000 mogelijke begin posities en dan 6^8 combinaties met dobbelsteen worpen). Moeilijk, maar wel te doen. Zeker met een zware PC.

XS4All had een paar jaar terug als suggestie 'mijn kat heet Sam, hij is 8 jaar oud'. Of zo iets. En daar dan de begin letters van en l33tsp3@k eroverheen. Daar is mijn methode toch zwaar superieur aan.
Ik blijf hem dan ook gebruiken (en gebruik hem ook al jaren). Mijn ouders ook voor de e-mail servers van hun provider enzo. Mail wachtwoorden zijn toch al toegankelijk via het Thunderbird programma, dus dan maakt opschrijven ook niet meer uit. Een backup van het wachtwoord van je hoofdaccount is ook wel handig! Anders moet je identiteitskaarten gaan faxen enzo om die weer te laten resetten (dat was vroeger zo bij XS4All).

https://www.grc.com/passwords.htm

Zie https://en.wikipedia.org/wiki/Diceware

Inderdaad is AES256 prima.


Als de nsa je zorg is, is jouw constructie echt te slecht.

Om iets te chargeren, je neemt
HeelVoorspelbareData_<heel erg random> Voorspelbaar <heel erg random>

En kiest daar je wachtwoord letters uit. En je hebt duidelijk niet door _dat_ je je random bron verdunt hebt met voorspelbare plaintext.


Ik stel zeker niet voor om een website te vertrouwen .
Ik zeg vooral dat het niet zo'n goed idee is om de kwaliteit van een goede rng (zoals gpg, en zoals de linux kernel /dev/random) te verdunnen met plaintext in een enorm omslachtige constructie .


Maar _waarom_ zo'n rommelige constructie als je alleen maar een paar dozijn random letters wilt hebben ?

Ik had al geschreven, neem 32 bytes van /dev/random (linux) , en gebruik de base64 of sha2-512 output daarvan.

dd if=/dev/random bs=1 count=32 | base64
Dan _heb_ je 256 bits entropie .


Het voordeel van de zin-met-beginletters is dat je kans hebt om het te onthouden .


Jouw computers, jouw keuze .
Het is beter dan Welkom123 en Secret456 .

Het is alleen minder goed dan je dacht, en minder goed dan de rng waar je mee begon. Zonde - als je toch een goede rng gebruikt en bereid bent heel lange wchtwoorden te gebruiken

Mijn vader zegt: als je een hamer hebt, lijkt alles op een spijker. GnuPG is mijn hamer :-)

Mensen hebben mij al eerder dd aangeraden voor random numbers, maar eerlijk gezegd vind ik dd doodeng. Omdat je er ook je hele harddisk mee kunt zero-en. Bovendien verschilt per linux/unix of je random of urandom (uit mijn hoofd) moet gebruiken. De ene is blocking, de andere niet.

In GnuPG zit ook een commando om de random pool leeg te trekken, dit is uit de man pagina:

Zo ingewikkeld is mijn methode trouwens niet. Je hoeft maar een keer een 'Wachtwoordgeneratie Key' sleutel aan te maken. Daarna kan je deze hergebruiken. Vroeger gebruikte ik zelfs GPG sleutels van anderen hiervoor (bijvoorbeeld Werner Koch). Zie een losse sleutel voor wachtwoordgeneratie als migitation. Als migitation waartegen weet ik echter (nog) niet...

Nou, bedankt voor het meedenken! Het zou goed zijn als meer mensen in ieder geval GnuPG gaan gebruiken, want zo moeilijk is het nou ook weer niet. Als je mijn eerste post leest, weet je hoe je een sleutel aanmaakt en iets encrypt naar die sleutel. Dit kan ook met een GUI, maar die gebruik ik zelf niet. Zou eigenlijk het liefst PGP 2.6.3i nog gebruiken, maar die is niet meer veilig :-/ (Hoewel, voor wachtwoordgeneratie maakt het denk ik niet uit als je nog een oude 16-bits MS-DOS machine hebt staan). De source van PGP 2.6.2 is uitgebracht in boekvorm om Amerikaanse export wetten te omzeilen. Auteur Phil Zimmermann heeft hier er een hoop 'gezeik' met de FBI door gehad! Iets wat je nu ook weer terugziet met Apple. De FBI leert het nooit...

''Welke is beter D3U@oP6j66*Ef##H6$@*8Eb of deze )HOyPkvx=-XQ^!x*![=N)Lf'SjE''

Indien je wordt aangevallen met een keylogger, geen van beide ;)

I.P.V zo'n onmogelijk wachtwoord, kan je ook DiceWare gebruiken.
Het principe is simpel, Je kiest 7 willekeurige woorden met een dobbelsteen. Dit is vrij makkelijk te onthouden en bevat veel characters. Als de aanvaller weet dat je DiceWare hebt gebruikt dan is het nog steeds 6600^7 combinaties

/dev/random (en /dev/urandom) kun je als gewone user lezen, de disk-block devices kun je als user niet lezen/schrijven.

Als je het als user doet _kun_ je dus niet je hele harddisk zero'en .
Verder doet 'dd' helemaal niet 'zomaar' dingen met harddisk block devices - de output van dd gaat gewoon naar stdout, of naar een via 'of' (output file) opgegeven file .

Inderdaad wordt 'dd' vaak gebruikt om image dumps van disk devices te maken, of te schrijven - dan is de 'if' (input file) of de 'of' (output file) een disk device (/dev/sda bijvoorbeeld ).
Wanneer je dat doet, als root, moet je inderdaad goed opletten welke data je van of naar wel device stuurt .

Maar net zo goed als je zou moeten oppassen wanneer je cat file >/dev/sda zou doen als root .

Kortom - 'dd' is niet gevaarlijk . 'dd' als root, met disk devices als input/output parameters kan dat zijn .

/dev/random levert alleen zoveel bits output als er entropie in de entropie pool zit.
/dev/urandom is levert zoveel bits output als gevraagd worden, waarbij de entropie pool als seed gebruikt wordt en AES als erg veilige pseudo-rng (met random seed) gebruikt wordt.

In system call termen heeft de term 'blocking' een andere betekenis dan je bedoelt [zie de manpage van random(4) .


Nogmaals :
dd if=/dev/random bs=1 count=32 | base64
of jouw hele epistel.

makepasswd , pwgen/secpwgen en mkpasswd zijn ook prima opties .

Echt, even de hamer wegleggen en een keertje oefenen met een schroefboormachine is heel nuttig.

Als we onszelf gaan herhalen, is dit misschien een mooi punt om onze discussie te stoppen. Jij hebt een voorkeur voor CPRNG, ik voor GnuPG 1.4.x (wat overigens intern ook /dev/random gebruikt als dat er is op je operating system). Ook heb ik het gevoel meer controle te hebben met GnuPG door bijvoorbeeld het symmetrische algoritme te kunnen kiezen (wat op het moment gewoon AES256 blijft).
En we vinden allebei goede wachtwoorden heel belangrijk, laat dat duidelijk zijn :-) Dit is een beetje een PC/Mac discussie aan het worden ;-) Hoewel het topic van deze draad hier ook wel om vraagt.

je eindigt niet met een "!" dus het is beide niet zo sterk :)

Je doet de moeite om een schatting te maken, maar je doet wel minstens een aanname over de situatie die mogelijk niet opgaat. Namelijk dat beide websites (zie de toevoeging van 15-05-2016, 21:26 door Anoniem) over een goede RNG beschikken en die goed gebruiken. Zoals al is opgemerkt (zie 16-05-2016, 14:06 door MathFox) weten we dat niet. Het is onmogelijk om uit één voorbeeldwachtwoord per website af te leiden hoe sterk hun wachtwoordgenerator is.

En dan is entropie een lastig begrip. Je hebt om de sterkte van de wachtwoorden uit te rekenen vermoedelijk gebruik gemaakt van de formulie entropie = wachtwoordlengte * log(aantal tekens in gebruikte tekenset) / log(2) bits. Los van dat die formule al de aanname bevat dat de tekens in het wachtwoord toevallig en onderling onafhankelijk zijn geldt ook nog eens dat de entropie zoals die voor een aanvaller geldt afhangt van hoe de aanvaller te werk gaat. Als bijvoorbeeld een van de gebruikte websites én populair is én een zwakte bevat die de aanvaller misbruikt en exploiteert zou voor hem wel eens een andere entropiewaarde kunnen gelden dan hier is berekend.

Dat verschil laat zich beter met een wachtzin dan met een wachtwoord uitleggen. Neem deze wachtzin:

kunstcollectie tsjirpte wedstrijdpaard

Die heb ik willekeurig gekozen uit een Nederlandse woordenlijst met alleen kleine letters die 327749 woorden bevat (een voor de gelegenheid bewerkte versie van /usr/share/dict/dutch uit het Debian-pakket wdutch; dit waren de bovenste drie woorden die sort -R opleverde). Als een aanvaller dezelfde woordenlijst zou gebruiken om wachtwoorden te kraken dan moet hij de juiste 3 woorden uit die lijst van 327749 selecteren om een treffer te hebben. De wachtwoordlengte is dan niet het aantal tekens maar het aantal woorden, dát zijn de eenheden die deze aanvaller combineert, en het is niet de lengte van de gebruikte tekenset die telt maar de lengte van het gebruikte woordenboek. De entropieberekening wordt dan:

entropie = 3 * log(327749) / log(2) = 55 bits

Als de aanvaller zou proberen om wachtzinnen te kraken zonder woordenboek en alleen kleine letters en spaties zou uitproberen dan zou hij de juiste 38 tekens uit een verzameling van 27 moeten kiezen en dan wordt de berekening:

entropie = 38 * log(27) / log(2) = 181 bits

Maar als de aanvaller niet uitgaat van wachtzinnen maar van een verzameling 97 tekens (hoofd- en kleine letters, cijfers, leestekens, spatie...), dan moet hij de juiste 38 tekens kiezen uit een lijst van 97, en dan wordt de berekening:

entropie = 38 * log(97) / log(2) = 251 bits

De entropie is 55, 181 of 251 bits, afhankelijk van de berekening (en als je een andere variant bedenkt levert die weer wat anders op). De berekening gaat niet uit van hoe het wachtwoord is opgebouwd maar van hoe de aanvaller het probeert te kraken. De aanvalsmethode bepaalt dus de entropie. Het lastige is natuurlijk dat je nooit weet hoe een aanvaller precies te werk zal gaan.

Terug naar de wachtwoorden van de vraagsteller. Het eerste wachtwoord bevat geen cijfers, en het lijkt alsof de generator geen cijfers gebruikt, maar hoeveel moeite de aanvaller moet doen om het te kraken hangt af van de vraag of hij wel of geen cijfers uitprobeert (en welke andere tekens natuurlijk). En het hangt af van de vraag of hij random wachtwoorden uitprobeert of op de hoogte is van zwaktes in populaire generatoren en daardoor uit een veel kleinere verzameling mogelijkheden kan putten.

Wachtzinnen kunnen opvallend zwak uitpakken als een aanvaller een woordenboek gebruikt. Bedenk wel dat als woorden gebruikt worden die niet in het woordenboek van de aanvaller voorkomen de aanval meteen niet meer werkt, de entropie is vanuit het perspectief van die woordenboekaanval dan meteen oneindig. Een wachtzin met onzinwoorden als krablovamda zovrokneutje boktatadrijps zal dus sterker zijn dan de eerder genoemde wachtzin (ze zijn even lang). Als de aanvaller dan terugvalt op het proberen van kleine letters en spaties zit hij op die 181 bits entropie uit de tweede berekening. Maar ik heb wel eens geprobeerd te schatten wat de entropie is als een aanval op basis van lettergrepen wordt gedaan (aaneengeschakeld met behulp van Markov-ketens, voor wie dat wat zegt), en dat leverde als vuistregel op dat je 1,6 bits per niet-spatieteken kan rekenen als alleen kleine letters en spaties worden gebruikt. Dan kom je maar een paar bits hoger uit dan de 55 bits uit de eerste berekening.

Het beoordelen van wachtwoordsterktes is al met al weerbarstige materie met veel onzekerheden. Je kan het beeld aanzienlijk simpeler maken door van wachtwoordgeneratoren uit te gaan die willekeurige tekens genereren uit bijvoorbeeld een verzameling van 97. Dan zijn er geen woordenboeken waar de aanvaller op terug kan vallen of patronen als lettergrepen die uitgebuit kunnen worden. Wel blijft de onzekerheid over of de generator geen fouten bevat die misbruikt kunnen worden. Daar doe je niets aan, als je zo'n generator gebruikt loop je dat risico.

Maak indien mogenlijk vanje inlog naam ook een wachtwoord, J.Jansen wordt Acg23ghSGze56.

@ Vandaag, 13:57 door Anoniem:
Er zit veel waarheid in je verhaal.
De veiligheid van een wachtwoord hangt inderdaad mede af van wat een aanvaller al weet over het wachtwoord, bijv.:
- uit welke verzameling(en) tekens bestaat het?
- hoe lang is het?
- op welke wijze is het wachtwoord gegenereerd?
- etc.

Echter in de meeste gevallen weet een aanvaller in de praktijk helemaal niets over je wachtwoord.
En dus ook niet hoe goed de RNG van de wachtwoordgenerator was die je hebt gebruikt.
Maar je hebt gelijk dat je daar nog wel een beetje rekening mee zult moeten houden.
(bijvoorbeeld: zou die "mooie" wachtwoordgenerator stiekem ontworpen zijn door een "crack"-website van dezelfde
maker?... Het is sowieso een goed idee om nooit je wachtwoorden van internet te halen!)
En verder zoals Anoniem 11:14 antwoordde: " Indien je wordt aangevallen met een keylogger, geen van beide ;) "

Dit zijn echter de uitzonderingen. Meestal weet een aanvaller weinig tot niets.
(zodra je het vermoeden hebt dat iemand iets van je wachtwoord weet, is het beter om het (drastisch) te wijzigen)
Dat de aanvaller niets van je wachtwoord weet, was daarom ook mijn uitgangspunt in mijn bericht van 16-05-2016, 15:17:

"Er vanuitgaande dat niemand weet hoe je tot je wachtwoord bent gekomen:"
en later: "......zelfs als een aanvaller zou weten dat er geen cijfers in voorkomen!"

Ik hield er dus al rekening mee.
Maar welbedankt dat je nog even voorgerekend hebt waarom dit dus zo belangrijk is.

Het is trouwens niet het enige waar men rekening mee dient te houden.
Soms worden wachtwoorden op de server opgeslagen en/of verwerkt in gehashte/gesalte vorm van gelijke lengte
zoals bij WPA2. Het kan dus zo zijn, dat de server alleen maar die hash (altijd van gelijke lengte) kent, en niet het wachtwoord zelf. Dat is wel zo veilig met het oog op mogelijke hacks waarbij die wachtwoordhashes kunnen uitlekken:
zo weet immers een aanvaller zelfs de lengte van jouw wachtwoord niet!

Maar korte en veelvoorkomende wachtwoorden kunnen dan vaak nog steeds vlot d.m.v. brute force en m.b.v. woordenboeken gehackt worden.
Eén nadeel: afhankelijk van hoe één en ander precies is geïmplementeerd, kan het gebeuren dat bijzonder lange wachtwoorden een toevallige collision hebben met een veel korter wachtwoord dat met brute force kan worden ontdekt.
De veiligheid hangt dus ook nog af van de manier waarop je wachtwoord in de server(s) worden opgeslagen en verwerkt
en ook van hoe hackbestendig die server is, en hoe integer de mensen zijn die de website hebben ontworpen,
en de mensen die het beheren/onderhouden...

Met betrekking tot WPA2:
Daarom kwam ik laatst bij een nader onder de loep nemen van wachtwoorden voor WPA2 tot mijn tips:
Kies voor WPA2 niet een te korte wachtwoord/wachtzin, maar liever ook weer niet te lang.
En kies liefst een "wachtonzin" bestaande uit allemaal volkomen willekeurige karakters met minstens één willekeurige hoofdletter, kleine letter, cijfer en leesteken erin, en dit wachtwoord ook periodiek te wijzigen. (bijv. 2 of 4x per jaar)
Dan ben je redelijk gegarandeerd dat woordenboek aanvallen je wachtwoord niet zullen vinden, en ook brute force aanvallen niet zullen slagen. (hoewel met toenemende rekenkracht m.b.v. nieuwe chips met hardwarematig aangedreven hashing voor nog geen 2 dollar per stuk, is het moeilijk om te voorspellen hoe lang WPA2 nog veilig is...)
Meer informatie in: https://www.security.nl/posting/458926#posting460653

Goeroehoedjes