Het laatste waar ik mij zorgen om maak.

Ik gebruik al jaren aaneen wachtwoorden uit de mixer van bovenstaande zoals (voorbeeld) $gy,)HsiEm,|€_uK die ik regelmatig verander en ga niet met een 16x50 kijker de weg afspeuren of ik beren zoals quantum computers zie. Die wachtwoorden bewaar ik niet in een cloud of anderszins digitaal, Waar dan wel? Wel, dát ga ik natuurlijk niet aan de grote klok hangen.

Bovendien - en dat kun je hier dagelijks lezen - exploiteren criminelen tegenwoordig vooral social engineering m.b.v. email of telefoon om je de stuipen op het lijf te jagen o.i.d. om iets ten nadele van jezelf te doen waar zij groot voordeel van hebben.

(en nu ga ik mijn koffie opdrinken voor die koud wordt.)

De eerste is per teken log 36 / log 2 is 5,17 bits entropie
De middelste is per teken log 95 / log 2 is 6,57 bits entropie
De laatste is per teken log 62 / log 2 is 5,94 bits entropie

Het aantal bits entropie vermenigvuldig je met het aantal tekens en je hebt de (maximale) sterkte van je wachtwoord in bits. Random tekens genereren met een computer is overigens het moeilijkste wat er is. Het kan random lijken voor een mens, maar dat hoeft niet zo te zijn. De RNG van bijvoorbeeld een Intel processor kan je niet controleren omdat dat verborgen is in de microcode op de chip. Een bedrijf als Intel doet zijn best dat te verbergen. Security by Obscurity heet dat. Je hoeft de RNG in de chip echter niet te gebruiken, bij bijvoorbeeld een Intel 8086 zaten geen crypto functies en toch werkte PGP daarop. Zo goed dat de FBI een rechtszaak tegen de maker begon om PGP te verbieden.

Voorbeeld: 2 ^ 6,57 is 95,0 mogelijkheden per teken (berekening klopt dus) en 6,57 * 63 is 414 bits entropie voor het hele wachtwoord. Dat is meer als het aantal mogelijkheden voor AES256. Vrij zinloos dus als je AES256 gebruikt met je wachtwoord :-)

Tekens in het middelste voorbeeld kunnen overigens grote problemen geven als je toetsenbord instellingen veranderen! Dit kan vaak al door per ongeluk een toetsencombinatie in te drukken als dat niet de bedoeling was.

De zoekruimte is groter naarmate de tekenset waaruit gekozen wordt groter is.

Dus inderdaad is 63 tekens uit "printable ascii" een grotere ruimte dan 63 tekens uit "alphanumerics" en zeker dan 64 tekens uit 16 karakters.
Maar dat doet allemaal de aanname dat de tekens ook echt random gekozen zijn.

Een quantum computer bestaat niet en gaat nog heel lang niet bestaan.
En is niet extra geschikt voor het zoeken van hash resultaten.

Verder zijn al die computer berekeningen alleen relevant wanneer de aanvaller op de een of andere manier de hash van dit password heeft, niet het password, en probeert het password erbij te zoeken.

Zoek maar bij hascat voor getallen van hoeveel woorden/zinnen per seconde te proberen zijn met een grote bak GPUs.
En hoe dat varieert met de gekozen hash (daar heb je zelf meestal geen invloed op - dat is de keuze van de site of service waar je het password voor gebruikt ).

Mensen - stop toch met dat fetishisme voor nog groter nog langer passworden en het fantaseren dat de NSA, de Aliens, of de Bilderbergers hun volledige capaciteiten inzetten om JOUW password en wat je dan zou moeten hebben.
Datzelfde geldt ook voor crypto algorithmen .

Neem een een stuk dertig true random karakters (idd printable ascii) , vooral uniek per site/service , en richt je zorgen op de manieren waarop echte hacks gebeuren . Erg zelden tot nooit is dat via een brute force van een serieus goed password.

Onveiligheid op andere vlakken compenseer je niet met een nog langer superrandom password .

Alles is te kraken, als er maar genoeg resources tegenaan gegooid worden. Je vraag moet dan ook zijn: wat is veilig genoeg?

Waar wil je de wachtwoorden voor gebruiken en wat zijn de bijbehorende dreigingen? Als dit jouw persoonlijke wachtwoorden zijn, dan lijkt meer dan 20 tekens mij al behoorlijk overkill. Dan gaat een willekeurige aanvaller met een Rainbow of Dictionary attack echt niet binnenkomen en zijn andere dreigingen (phishing, malware) veel waarschijnlijker.

Sterkte van een wachtwoord wordt niet alleen bepaalt door de keuze van het wachtwoord (al speelt dit een rol aangezien voorspelbare wachtwoorden sneller gekraakt kunnen worden dan wachtwoorden die random worden gegenereerd).

De implementatie aan de service kant is ook wezenlijk van belang. Welk hashing algoritme wordt gebruikt aan die kant (en hoe groot is de kans op collision), wordt er een salt (en eventueel pepper) gebruikt etc.

Als voorbeeld: als een site MD5 als hashing algoritme zou gebruiken (ik mag niet hopen dat er nog zulke sites zijn, maar het zou me niet verbazen), dan maakt de keuze van het wachtwoord niet veel meer uit aangezien de kans op collision bij dit algoritme zo groot is dat er gemakkelijk (middels een heel ander wachtwoord dan de door jou ingestelde) toegang zou kunnen worden verkregen.

Ervan uitgaande dat een site de toegang op een fatsoenlijke manier heeft geregeld, zou ik zeggen: laat een password manager voor iedere site een willekeurig password genereren, met een willekeur aan prntable ASCII characeters) van voldoende lengte. Deze hoeven niet zo lang te zijn als in bovenstaand voorbeeld; ik gebruik zelf op dit moment (daar waar sites dit toestaan) een lengte van 24.

Nee, dit lijken geen écht willekeurige tekens te zijn. Het is een string van 63 tekens die een mix gebruikt van hoofdletters (A-Z), kleine letters (a-z) en cijfers (0-9), maar zonder bepaalde tekens zoals de hoofdletter 'I', 'O' en het cijfer '1' (die vaak worden vermeden in mens-leesbare codes om verwarring te voorkomen). Dit patroon komt typisch voor voorbeelden van cryptografische sleutels of hashes, zoals een Bitcoin-adres of een private key in Base58-encoding.

Om dit te verifiëren:

Lengte en samenstelling: De string past perfect bij de conventies voor Bitcoin-gerelateerde strings (bijv. private keys zijn vaak ~51 tekens, maar variaties zoals WIF-formaat komen in de buurt van 51-52; dit zou een uitgebreide versie of een andere crypto-hash kunnen zijn).
Geen perfecte uniformiteit: Een eenvoudige statistische test (chi-kwadraat op tekenfrequenties) geeft een waarde van ~41, wat wijst op enige clustering (bijv. 'D' komt 5 keer voor, 't' 4 keer), maar niet extreem – het oogt nog steeds "random" op het eerste gezicht.
Geen exacte match met bekende strings: Een snelle controle toont geen directe hit op publieke databases, maar het formaat schreeuwt "crypto-voorbeeld".

Als dit uit een specifiek document of context komt (bijv. een tutorial over blockchain), is het waarschijnlijk een gegenereerd voorbeeld om privacy te bewaren

Online accounts zijn moeilijk te brute forcen omdat het dan moet plaatsvinden via een webinterface. Elke http request is expensive om nog maar te zwijgen over login throtteling. Het wordt pas gevaarlijk wanneer er een kopie vd hash beschikbaar komt bij criminelen. Daarnaast is quantum computing voorlopig og maar in staat om 4x zo snel een wachtwoord te kraken dan normaal. Een wachtwoord van meer dan 32 tekens, tekens zoals de middelste, voorlopig meer dan goed. Vraag jezelf af: waarom wilt een crimineel toegang tot jou data? En waarom is dat het waard om veel stroom, rekenkracht, geld aan te besteden? Ik zou zeggen beveiliging je gevoelige data met een zo lang mogelijk wachtwoord. De meeste services zijn al voorzien van een mail notificatie bij login. Het iS slim daar naar te kijken. Ik zou me voorlopig verder niet druk maken, zeker aangezien een datalek sneller tot resultaten, bij criminelen , leidt dan een wachtwoord te kraken en daarna daarmee in te loggen. Ondertussen goed in de gaten houden of er data lek is geweest bij diensten die je gebruikt. Concreet antwoord op je vraag: het duurt tientallen jaren om de wachtwoorden te kraken die je aangeeft, met vandaag beschikbare computers.

Een tip, mocht je lokale data willen beveiligen: Gebruik een usb stick (bijv. IronKey) die beveiligd is met een hardware wachtwoord voor gevoelige bestanden. Deze zijn niet met computers te kraken, in iedergeval niet dusdanig dat er een bruteforce op uitgevoerd kan worden. Daarnaast je bestanden beveiligen met een 32 bit wachtwoord, op die usb, en je zit voorlopig goed. Dit gebruik ik zelf ook.

Wat bedoel je met een zo lang mogelijk wachtwoord, is het middelste wachtwoord dan niet lang genoeg?
Deze dus > ~(y61J/0=>I2xy]Ru"<?oGbU;a&q}SuDs#4VAzVUGy-hzyqAh+$o3T`QUAs>BS5
(Ik wil het gaan gebruiken voor een e-maildienst als wachtwoord)

Op deze site kan het ook: https://www.whatsmyip.org/random-password-generator/ Je moet dan 63 tekens pakken.
Maar de vraag is, is deze ook zo veilig als de site van GRC.com???

Geen idee

Waar een sterk wachtwoord aan moet voldoen schreef ik 2 dagen geleden in https://security.nl/posting/912963.

Ze zijn allemaal even ONVEILIG, want ze zijn gepubliceerd op internet (zoek ze maar op met Google, helaas de beste zoekmachine voor dit soort items).

1) https://google.com/search?q=%22917090E2C10A5CA58D19128A87735C5F28C67E41A7F81C36A857A44FDBECB1EC%22

2) https://google.com/search?q=%27%7E%28y61J%2F0%3D%3EI2xy%5DRu%22%3C%3FoGbU%3Ba%26q%7DSuDs%234VAzVUGy-hzyqAh%2B%24o3T%60QUAs%3EBS5%27

3) https://google.com/search?q=%22cTNQXkbNgzEOvD7KpWRotIZceaa5rt4an70UtAAeXvDWT4dmeGHotDRDQ2DxnAV%22

Het is enorm onverstandig om gepubliceerde (voorbeeld-) wachtwoorden (opnieuw) te gebruiken.

Voor degenen die een door hen gekozen wachtwoord (zoals bovengenoemde) hashen en naar die hash zoeken op internet, publiceer ik meteen maar enkele hashes van elk:

1) 917090E2C10A5CA58D19128A87735C5F28C67E41A7F81C36A857A44FDBECB1EC
MD5: 55134d3a77ac0687d87b7859c45f81bb
SHA1: d1c2d90a300de52fd32245cde9728c85c0d8989e
SHA-256: 38275bab905f9d55c1c36eae5c1aaea3e0f6efb6ee1fa7d7710c27b4dda73325

2) ~(y61J/0=>I2xy]Ru"<?oGbU;a&q}SuDs#4VAzVUGy-hzyqAh+$o3T`QUAs>BS5
MD5: 5288ccffa80bdf3af8654ada2d78d1c7
SHA1: b8a62c16ffe546a2e42290f07cfe4b8c619b7b14
SHA-256: 3a5ea804014685cefd6c03ad90527b0672c198fdafc3389b818b16a9a621b787

3) cTNQXkbNgzEOvD7KpWRotIZceaa5rt4an70UtAAeXvDWT4dmeGHotDRDQ2DxnAV
MD5: 68a18f52684bf64041ecfe0061a3c517
SHA1: 0f3021491ff44298a35015f9b781fd4b6e854789
SHA-256: bfa5e8016435b5d85c965b239654038e8cc55cbef558de8b9f46057127f1e364
 

Je slaat de spijker regelrecht op z'n kop Erik!

Advies: gepubliceerde wachtwoorden moet je NOOIT gebruiken!

Om een passphraseof wachtzin te maken adviseert de AP het gebruik van Diceware.

https://www.security.nl/posting/819675/Autoriteit+Persoonsgegevens+pleit+voor+passphrases+als+wachtwoord


Samengevat: de beste manier om je wachtwoorden te bewaren

Neem een password manager of wachtwoordenbeheerder, liefst één van deze drie: Bitwarden, 1Password of KeePass

o Gebruik als wachtwoord een wachtzin of Diceware.
o Schrijf dit wachtwoord op en bewaar het op een veilige plek, zodat je nooit de toegang verliest.
o Laat de password manager willekeurige wachtwoorden minimaal 20 tekens genereren en opslaan.

https://www.laatjeniethackmaken.nl/#samengevat-de-beste-manier-om-je-wachtwoorden-te-bewaren

Hoe backup je KeePass en heb je een keyfile nodig naast password of is 25 tekens voldoende?