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?

Het advies om bepaalde eenweg-algoritmes niet te gebruiken voor het hashen van wachtwoorden op servers:
• heeft niets te maken met collissions, én het
• heeft niets te maken met dat MD5 "gekraakt" is, én het
• heeft überhaupt niets met cryptografie te maken, máár het
• heeft alles te maken met dat mensen voorspelbare (incl. te korte) wachtwoorden gebruiken.

Hét grootste probleem hier is dat de meeste mensen wachtwoorden gebruiken die ooit in een "wachtwoorden-woordenboek" (password-dictionary) zijn terechtgekomen. Zodra criminelen een database met gehashte wachtwoorden in handen krijgen, hangt hun aapak er vanaf of er (per account) een platte-tekst salt (een random getal of reeks alfanummerieke karakters) is opgeslagen.

Een gevolg-probleem is dat op snelheid geoptimaliseerde software die hashes berekent bloedsnel is, vooral op moderne grafische kaarten. Het is dus onverstandig om welke snelle hashfunctie dan ook in te zetten voor "éénweg afgeleiden" van wachtwoorden.

Als zij deze nog niet hebben genereren de criminelen een rainbow-table voor het in de wachtwoord-database gebruikte hash-algoritme. Dat doen zij door van elk wachtwoord in bijvoorbeeld deze [1] 1000 password-dictionary de hash te berekenen, en vervolgens de output (hash) en input (wachtwoord) in een tabel te zetten.

[1] https://www.secureworks.com/-/media/images/insights/blog/lazy-passwords-become-rocket-fuel-for-emotet-smb-spreader/unredactedtable.pdf. Nb. in de praktijk worden gigantisch grotere password-dictionaries gebruikt, zie bijv. https://weakpass.com).

Indien de gehackte server MD5 gebruikte, dan begint die tabel mogelijk als volgt:

Vervolgens halen zij, één voor één, de hashes uit de gekopiejatte account-database en kijken of diezelfde hash vóórkomt in hun rainbow-table. Zo niet: helaas pindakaas, volgende proberen. Zo ja: wachtwoord bekend (en volgende proberen).

Voor elk "gereversed" wachtwoord zoeken de criminelen het e-mailadres van het slachtoffer erbij en kijken of zij daarmee, plus gevonden wachtwoord, ook op accounts op andere servers kunnen inloggen.

Nb. in theorie kunnen zo hash-collisions gevonden worden. In de praktijk is dat een broodje-aap-verhaal, want de kans dat twee verschillende wachtwoorden dezelfde MD5 opleveren is ruwweg 1 : 2^128 (dus 1 : meer dan 3 gevolgd door 38 nullen en bovendien is de kans ca. 0 dat het daarbij om twee realistische passwords gaat: zie de tabellen in https://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities).

Een rainbow table heeft geen zin in dit geval. Echter, moderne grafische kaarten worden steeds sneller in het berekenen van hashes.

In dit geval halen de criminelen ook, één voor één, de hashes en bijbehorende salts uit de gekopiejatte account-database. Maar nu voeren zij die inputs aan hashcat - die als derde input de gekozen dictionary gebruikt (voor hoe het verder gaat zie onder "zonder salt").

Effectief moet je dus, per account (hash + salt) dezelfde berekeningen doen alsof je een rainbow table zou maken (in zoverre, bij een "hit" ben je eerder klaar).

Leuk, maar dat kost natuurlijk jaren. Of niet? Uit https://gist.github.com/Chick3nman/09bac0775e6393468c2925c1e1363d5c (ingekort, afgerond en vereenvoudigd door mij):
Merk op: G (Giga) is 1.000.000.000.

Ter vergelijking (H/s i.p.v. GH/s):

Oftewel, bij MD5 met salt kun je, orde grootte, 10^11 hashes/seconde berekenen. Bij SHA-512 is dat 10^10. Bij dergelijke snelheden zet dat geen zoden aan de dijk.

Je kunt alleen significant afremmen door bewust traaggemaakte eenwegfuncties (zoals script en Argon2) te gebruiken. Daarbij moet voorkómen worden dat softwarematige-optimalisatie mogelijk is: in de praktijk betekent dit dat zulke routines CPU-performance en/of geheugen moeten vreten. Maar dáár hebben servereigenaren een bloedhekel aan, want dat kost hén geld.

Ik blijf het herhalen: gebruik UNIEKE (per account van jou) en zo lang mogelijke STERK RANDOM GEGENEREERDE wachtwoorden met zoveel mogelijk "entropie" (zoveel mogelijk toegestane tekens).

Voor jouw eigen accounts-veiligheid. En gebruik een wachtwoordmanager die op domeinnamen checkt - om de meeste vormen van phishing uit te sluiten. Een goede wachtwoordmanager zal ook prima random wachtwoorden kunnen genereren.

Nb. bij wachtwoordzinnen en voorspelbare randomness is de kans groter dat deze ooit gebruikt, gelekt en in een password-dictionary zijn opgenomen.

Wachtwoord lengte is maar deel van de beveilliging als je dit gebruikt voor diensten. Want dan ben je afhankelijk van hoe hun de wachtwoorden versleuteld opslaan. je 64 tellende multifactor beveiligde account kan in de praktijk onveiliger zijn dan een wachtwoord van 8 simpele cijfers. Dat is simpelweg de realiteit. Als je niet weet hoe de beveiliging gedaan wordt en welke preventie maatregele ze hebben is het simpel weg geluk hebben. Of vaker pech hebben.

Wij hanteren de wachtwoord sterkte moet hoger zijn dan de maximale tijd dat een verwerker doet over het informeren over een datalek, diefstal bij in gebruikname Daarbij gaan we uit van realistische berekeneningen wat je met on te market mogelijk nu zou kunnen bereiken. Quantum computers zijn op wachtwoord beleid geen relevante factor. Store Now Decrypt Later (SNDL) is simplweg niet een realistisch risico voor als het op wachtwoorden aangaat dat draait om de encryptie.

Iets wat vele niet snappen omdat ze niet werkelijk met dit vak of zelfs sector te maken klaarblijkelijk hebben is dat quantum computer risico niet wachtwoorden bruteforcen is maar de encryptie van de data. Fido is in dat geval net zo veilig als ƒ1d0. De beveiliging verantwoordelijkheid zit niet bij jou maar bij de verwerker van de informatie. (tenzij jij de verwerker bent) Waarom denk je dat we bezig zijn met post quantum cryptografie (PQC) als ontwikkeling. Als wachtwoord lengte het probleem zou oplossen dan zou men gewoon wettelijk verplicht worden om sterkere wachtwoorden te gebruiken. Gebeurt niet omdat het niet relevant aan deze dreiging is.


Los van quantum computers paar basis regels.
Gebruik nooit zelfde wachtwoorden voor meer dan 1 dienst.
Hergebruik geen wachtwoorden.
Gebruik nooit de zelfde mail adres voor aanmeldingen (maak gebruik van plus of subadressing)
Schrijf je in voor leverancier alerts.
Schrijf je in bij een dienst als bijvoorbeeld haveibeenpwned voor mail domein alerts aangaande datalekken.


Dus recap:
Wachtwoord veiligheid is primair afhakelijk van waar, hoe iets wordt opgeslagen de preventieve maatregelen bij verwerker en nette omgang van de gebruiker met de inlog. Wachtwoord sterkte is maar een fractie waar rekening mee moet worden gehouden en ligt veel te veel focus op.Je kan geen wachtwoordveiligheid garanderen *ooit* maar je kan wel de impact minimaliseren.

Rest van scenario is niet relevant omdat de theoretische quantum computer dreiging ligt bij cryptografisch kraken en niet wachtwoord bruteforcing. Lengte van het wachtwoord maakt dan ook bij succesvolle SNDL opslag niks uit enkel de cryptografishe sterkte van de encryptie *niet* het wachtwoord.

Quantum computers zouden in de praktijk bij bruteforcing van wachtwoord nog steeds tegen de zelfde obstakels van beveiliging aanlopen als coventionele bruteforcing en daardoor nutteloos zijn voor conventionele aanval. Als ik op mijn server jouw inkomende quantum computer connectie throttle en een MFA heb dan hoogtste wat je kan doen is mijn log net zo veel vervuilen als enige andere actor. Voor aanvaller in deze vorm dus nutteoos.

PQC is omtrent quantum het allerbelangrijkste wapen wat we nu aan het ontwikkelen zijn.
In de praktijk zal het gros van de mensen hier niks tot bijna niks van merken net als dat ze dat nu al niet doen met conventionele encryptie.

In hoeverre heeft de entropie enige invloed op de hash-uitkomst? Ik denk nul.

Stel je neem zo'n lang complex wachtwoord, waarbij de kans op een typfout erg groot is, zeker op een mobiel,
en je vergelijkt dat met een 2x zo lang wachtwoord, enkel a-z. Wie heeft de meeste unieke bits.

In het eerste geval heb je net geen 7 bits per karakter, in het tweede geval net geen 5. Dus meer
karakters uiteindelijk gaat het winnen.

En de laatste is toch echt veel makkelijker (en sneller en zonder fouten) in te kloppen.

Maar met een passwordmanager hoef je niks te tikken....Dus waarom moeilijk doen als het makkelijk kan? Phishing is veel meer een risico ook met zogenaamd 2FA(domeinnaam check)

Dat is wat nietszeggend.

De uitkomst van de hash wordt gewoon bepaald door de input.
De entropie is alleen een maat hoe moeilijk het is om die input te vinden door raden/proberen van aannamelijke kandidaten.


Met 'genoeg meer' wel ja.
Bij binaire input is er weinig entropie-per-karakter (0 of 1 ) - en dus moet het aantal bits vrij groot zijn (128, 256)
Het aantal ascii-tekens kan een stuk kleiner zijn .

Het aantal Chinese-karakters kan nog veel kleiner zijn voor een string met genoeg entropie.


Het gaat uiteindelijk om genoeg entropie in de totale string .
diceware (woorden uit een lijst kiezen met een dobbelsteen) is ook een uitruil van lange string (voor tik/onthoud-gemak) om toch "genoeg" entropie erin te hebben.

Wat is nu lang en lang genoeg??
Waar test ik dat??
(leek 007)

Dat vind ik een wel héél kromme, zo niet onjuiste, redenering.

In 128 bits (16 bytes) opslagruimte passen:

De ASCII karakterset was oorspronkelijk "7 bits", d.w.z. de 128 decimale waardes 0 t/m 127 werden gebruikt. Daarvan is een deel (0 t/m 31 en 127) gebruikt voor "control" (besturings) karakters, "non-printable".

Omdat we al snel met bytes (8 bits) zijn gaan werken zou je denken dat er 128 mogelijheden per byte bij zouden moeten komen. De bijbehorende tekens zijn echter slecht gestandaardiseerd, en in de tijd veranderd. Zo heeft ooit € de decimale waarde 128 gekregen.

De meeste servers staan slechts een deel van de mogelijke ASCII leestekens toe (of helemaal geen, of het wachtwoord mag er niet mee beginnen, enzovoorts). In de praktijk mag je blij zijn als er, naast cijfers en kleine/hoofdletters 10 leestekens zijn toegestaan en er geen andere beperkingen zijn (zoals minstens 1 leesteken, geen twee dezelfde karakters naast elkaar etc). Dan kom je op 10+26+26+10 = 72 mogelijke karakters per opslagbyte - dus 72^16 mogelijkheden bij 16 bytes = 521578814501447328359509917696 mogelijkheden.

Dat is 652.408.336 maal zo weinig als mogelijk is met 128 willekeurige bits.

In https://security.nl/posting/912963 schreef ik:
En daaronder lichtte ik toe waarom dat zo is.

Top, Dank! (er staan weinig topics op security.nl maar nu dus wel)

Blijkbaar te compact geschreven.

Wat ik bedoel uit te drukken is dat het aantal teken-posities groter moet zijn , naarmate het aantal verschillende tekens dat op een positie gebruikt mag worden kleiner is .

Er zijn veel binaire bits (1010010101010101) nodig om hetzelfde te bevatten als maar 4 hex-digits. Of maar twee (full ascii) tekens.

Het is misschien verwarrend dat binair typisch geschreven wordt in ascii tekens, alleen met maar twee uit de tekenset.

Ik liet een beetje open of "128 bits" dan wel "256 bits" aan entropie-waarde "genoeg" is . Natuurlijk zijn equivalente printable-ascii strings niet dezelfde lengte .

Een binair getal heeft de meeste posities/"cijfers" (bits) nodig , een decimaal getal ca 3.3 minder "cijfers" om hetzelfde uit te drukken, een hexadecimaal getal 4x minder "cijfers" (hex-digits ) dan binair.

30 jaar geleden nam ik die site al niet serieus, nu nog steeds niet. Steve Gibson was, is en blijft een nitwit die het net niet snapt met zijn onzin over blackholing.

Op https://drive.proton.me/urls/MVWQRHJRM8#Sr5gC40B7iUX is een test van de Apple standaard pseudo-random generator te vinden. Zoals te zien is in de test resultaten faalt de Apple pseudo-random generator totaal. Een goede true (quantum) random generator is aan te raden voor veilige onvoorspelbare passwords. Pseudo-random generatoren kunnen geen echt onvoorspelbare passwords genereren.

Waarom noem je dat de "Apple" standaard prng ?
Omdat je een stukje basis C op een Apple draaide ?

rand() is de klassieke PRNG in de libc - en vzviw vaak hetzelfde (snelle , maar kwalitatief matige) algorithme - LSFR .
Als je die code op Linux draait trek je dezelfde - misleidende - conclusie .

De glibc implementatie is dit
https://stackoverflow.com/questions/18634079/glibc-rand-function-implementation

Apple zal een andere libc gebruiken (geen gnu), maar zeer waarschijnlijk met een vergelijkbare generator.

rand() is net goed genoeg voor software die "iets" onvoorspelbaar moet zijn (spelletje en bewegingen van de computer speler of zo) .
De beperkingen worden al decennia beschreven in blogs en tutorials.

https://codeforces.com/blog/entry/61587

mooi dat jij ook doet - maar het is extreem misleidend om libc rand() aan te duiden als "Apple heeft slechte PRNG" .

Er zijn uitstekende PRNGs die - als ze een true random seed krijgen - cryptografische kwaliteit heel lange stromen pseudo-random getallen leveren. De rand() functie van libc is dat gewoonlijk niet (of nooit , weet niet of er uitzonderingen zijn).

Diverse OSen hebben ook een faciliteit om een true random getallen te leveren , bruikbaar als seed .
Die van Linux is bekend (en makkelijk vindbaar)
https://en.wikipedia.org/wiki//dev/random

ook Apple OSen hebben een vergelijkbare optie zo lees ik daar.

Welke is dat dan ? Een goede generator?

Een heel internet om primaire bronnen op te zoeken, en dan toch op een forum van onbekende anoniemen willen horen (en dan maar geloven ? ) dat MegaQuantumDuper 2000 een toppie PRNG is ?

Zucht.

Voor de meest zware toepassing (waarin een tegenstander probeert de volgende bit te voorspellen ) zoek je een CSPRNG - computationally secure pseudo random number generator.

(Voor dingen als monte-carlo simulaties heb je ook veel random numbers nodig, en ook van behoorlijke statistische kwaliteit, maar maak je je geen zorgen over een 'actieve aanvaller') .

lees
https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator

Veel zijn gebaseerd op encryptie algorithmen .
Als de 'seed' iets "true random" is zijn CSPRNGs het beste wat je kunt kiezen.

Helemaal true random is wat lastiger om in grote volumes te krijgen. Als je daarnaast zorgen hebt dat je true-random bron mogelijk een bias heeft is de boel door een CSPRNG halen de manier om daar geen risico mee te lopen - en een heel hoog output volume te krijgen.


https://crypto.stackexchange.com/questions/12436/what-is-the-difference-between-csprng-and-prng

De Mersenne twister is een bekende PRNG van behoorlijk goede kwaliteit - maar niet vanzelf voor cryptografische toepassingen.
https://en.wikipedia.org/wiki/Mersenne_Twister

Hedendaagse besturingssystemen onderhouden iets dat een "entropy pool" heet, die ontworpen is om onvoorspelbare data te bevatten. Er zijn allerlei hardware- en softwarecomponenten die in hun werking ruis produceren. Er treden ook verschillen in timing op, zelfs als je de computer ogenschijnlijk twee keer hetzelfde laat doen is de timing ervan niet identiek. Je besturingssysteem heeft toegang tot die zaken, en kleine verschillen zijn genoeg om die entropy pool elke keer een volstrekt andere inhoud te geven, en die ook voortdurend bij te werken, waardoor die domweg onvoorspelbaar is.

Die entropy pool wordt door het besturingssysteem gebruikt om random getallen te genereren. Als die nou de enige bron daarvoor zou zijn dan kan die makkelijk tijdelijk uitgeput raken als er te snel random getallen worden opgevraagd door allerlei applicaties, en blokkeert de opvraging tot het weer hersteld is, en daarmee het hele proces dat die opvraging doet. Dat wil je niet. Een "pseudo random number generator" (PRNG) heeft dat probleem niet, maar die heeft weer voorspelbaarheid als probleem: als je de interne staat van dat ding kent (of de "seed" waarmee die is geïnitialiseerd) kan je exact dezelfde reeks random getallen genereren. Dat haalt de benodigde onvoorspelbaarheid onderuit, en dat wil je dus ook niet.

De truc die wordt toegepast is om beide methodes te combineren. Als een toepassing random getallen aan de kernel vraagt krijgt die het volgende getal dat de PRNG produceert. Alleen wordt de interne staat van die PRNG voortdurend bijgewerkt vanuit de entropy pool, zodat de voorspelbaarheid van de PRNG voortdurend doorbroken wordt. Er blijven alleen, als de entropy pool tijdelijk is uitgeput, reeksen berekende random getallen over zodat het systeem niet blokkeert. De grap is dat die alleen voorspelbaar zijn voor wie de interne staat van de PRNG kent, en die is goed afgeschermd door de kernel. Effectief levert dat een systeem op dat én niet blokkeert én niet voorspelbaar is.

Die wachtwoorden die de website van Steve Gibson genereert zijn in wezen reeksen random getallen die op verschillende manieren in leesbare tekens zijn omgezet. Opmerkelijk in zijn beschrijving is dit stukje:
Volgens mij staat daar dat hij enkel een PRNG gebruikt, en dat een PRNG van hoge kwaliteit volstaat voor wachtwoorden. Maar dan doet hij iets niet wat het besturingssysteem op je eigen pc out-of-the-box wel doet. Je eigen pc doet het dus beter dan de website van Gibson. Het zou trouwens een fluitje van een cent zijn voor Gibson om de random getallen van het besturingssysteem van zijn server te gebruiken, maar kennelijk laat hij dat na. Dan ben je beter af met wat je eigen pc en besturingssysteem gewoon aan boord hebben dan met die website.

Het probleem met Steve Gibson is dat hij een groter talent heeft om wat hij doet sensationeel te presenteren dan om wat hij zo sensationeel presenteert werkelijk goed te doen.

Hoe gebruik je wat je eigen besturingssysteem kan? Installeer een lokaal wachtwoordbeheerprogramma, zoals KeePass of KeePassXC, en laat dat wachtwoorden voor je genereren. Zo'n programma zal de faciliteit voor random getallen van je besturingssysteem gebruiken en daarmee prima wachtwoorden genereren.

Nee, hehe, wie zou dat doen en waarom? Lijkt me nogal dom. Je kan toch zelf wel een wachtwoord bedenken?

Op https://www.idquantique.com kun je een goede true quantum randomgenerator kopen.
Deze true quantum random generator kun je delen in een grote groep.

Op https://drive.proton.me/urls/6F113ZQFX4#KjX1NulrcUS5 (Apple) en https://drive.proton.me/urls/FFXTYKA9JC#GvOY0mJ438RU (Linux) is software te downloaden waarmee sterke quantum random wachtwoorden gegenereerd kunnen worden en informatie beveiligd kan worden conform de Nederlandse Universiteitsstandaard met deze true quantum random generator.

Waarschijnlijk ten overvloede: Wachtwoorden gaan in het wachtwoord veld. Niet in het gebruikersnaam veld en zeker niet in de Google zoekmachine. Ook de laatste byte(s) van een hash wat tegenwoordig gebruikelijk is zou ik niet doen. Het geeft toch weer een hoop mogelijkheden die een aanvaller kan afkruisen. Je helpt een aanvaller hiermee. Doe dat niet.

Anoniem 10:42

Hou toch op met die FUD.

Elk apparaat dat veilige verbindingen via internet moet kunnen maken, moet een voldoende betrouwbare CSPRNG (*) aan boord hebben en die daadwerkelijk daarvoor gebruiken.

(*) Cryptographically Secure Pseudo Random Number Generator, zie https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator.

Da's best "gedoe" want met een algoritme kun je geen onvoorspelbare random getallen maken. Daarom maakt een goede CSPRNG gebruik van meerdere bronnen met zo lastig mogelijk voorspelbare gebeurtenissen.

Bijvoorbeeld uit https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange#Generalization_to_finite_cyclic_groups:
Nb. het Diffie-Hellman algoritme wordt onder meer gebruikt bij nagenoeg elke https-verbinding die je opzet met jouw webbrowser.

Het komt vóór dat er per ongeluk ernstige fouten in de broncode van CSPRNG's sluipen. Uit https://security.nl/posting/22449 (leesbaarder gemaakt en dead links verwijderd, dat vindt Bitwiper vast wel OK ;-):

Het komt óók voor dat CSPRNG's opzettelijk "gebackdoored" worden, zoals in https://xkcd.com/221. Maar ook minder opzichtig in de Dual_EC_DRBG. Waarna DAT achterdeurslot stiekem, door een onbekende derde partij, werd vervangen door een ANDER slot, zie https://security.nl/posting/455606.

Oftewel: het is groot nieuws als een CSPRNG voorspelbare "random" getallen produceert. Gelukkig zien we dat zelden.

Maar hoed je voor nieuwe "black boxes" die, op magische wijze en met FUD-woorden als "Quantum", worden geadverteerd. Beproefde methodes blijken meestal betrouwbaarder.

Waarom is dat een goede ?
Omdat ze vol met ronkende reclame vaak het woord quantum gebruiken ?

Ik heb een mooie RNG . ALs jij je email adres stuurt en zegt hoeveel bitten (exta service : secret keys voor ssh of tls) zal ik die voor je maken , goed ? Zo delen we samen mijn RNG.

Daarnaast : als er nou iets is wat je NIET moet doen is je super kritische security device in handen geven van een untrusted party (dan wel het daarvan lenen).



Researchers moeten papers produceren , en vooral op een hip onderwerp. Quantum. Qubits .

De wereld zit VOL met quantum processen die true random ruis produceren. Meestal ongewenst.
Die kun je samplen , al 75 jaar lang

https://en.wikipedia.org/wiki/Noise_generator
https://en.wikipedia.org/wiki/Johnson%E2%80%93Nyquist_noise

(historisch : https://en.wikipedia.org/wiki/A_Million_Random_Digits_with_100,000_Normal_Deviates .
1955, ook al gebaseerd op een true random bron .

Het vergt wel wat zorgvuldigheid om geen correlaties te introduceren bij het samplen van je true random bron , en ook om te blijven controleren dat die werkt, want na alle processing zie je het verschil niet meer tussen een kapotte en werkende random bron.

Maar het is totaal niet nodig om heel exotische of lastige bronnen te bouwen (radioactief, single-photon ).
Dat heeft heel sterk dezelfde lucht als audiofiele hifi - over the top claims om onwetenden emmers met geld uit de zak te kloppen. Een goede versterker is een opgelost probleem .

En een true random source ook.

lava lampen waren ook een hippe (en mooie) manier - videocamera erop en je hebt een bron met fors veel entropie .
https://en.wikipedia.org/wiki/Lavarand

Het is een mooi talking piece, en heel illustratief - maar niet 'noodzakelijk' of nog perfecter dan botweg rdrand.

Op https://blog.ledger.com/kaspersky-password-manager is te lezen hoe Kasperski de random generator in de password manager heeft gebruikt om zo passwords te kunnen achterhalen.

Hallo, spreek ik met ChatGPT?

Wat een ANONIEME WARTAAL weer. Je kunt niet eens "Kaspersky" overtikken en jouw enkele zin is onbegrijpelijk.

Wat was er aan de hand: antivirusboer Kaspersky maakte kennelijk tevens een wachtwoordmanager met een waardeloze PRNG (dat is, naar verluidt, ondertussen gerepareerd).

Zoals ik https://blog.ledger.com/kaspersky-password-manager lees, maakt KeePass niet zo'n stomme fout.

Heb je nog meer FUD?