De TPM is vooral voor DRM bedoeld, het doet vooral werk om bedrijven te beschermen tegen gebruikers.

Het enige wat "het uitsluiten van simpele PIN codes" doet is het systeem onveiliger maken, omdat immers het totaal aantal mogelijkheden verminderd wordt en dus de kans dat je die PIN goed "raadt" binnen het aantal beschikbare pogingen vergroot wordt.
Claims als "het is niet veilig om je geboortejaar als PIN te gebruiken" snijden geen hout.
De "aanvaller" weet niet dat je je geboortejaar gebruikt hebt. Dus dit geeft hem geen informatie over je PIN.
En het aantal pogingen dat je hebt om de goede code in te tikken is klein, dus je kunt niet zomaar allerlei voor de hand liggende codes gaan proberen.

Hm, ik denk dat als je de echt _allereerste_ raad-pogingen blokkeert (0000 , 1234, e.d.) dat wel een netto winst is.

Ook al weet de aanvaller niks - het is een poging waard , en mensen die gewoon geen zin hebben in WEER een kutcode nemen zoiets.


Een vier of vijf cijfer PIN moet het qua security toch hebben van een heel snelle lockout (3-10 pogingen)

Maar goed - ook al weet een aanvaller niks - mensen kiezen nou eenmaal typisch vindbare passwords, als je er genoeg mag proberen.

Een aanvaller "weet" ook niet dat je een normaal word met een paar vervangen letters (g3h31m ) neemt - maar dat soort permutaties zitten niet voor niks in dictionary crackers omdat het overgrote deel van de password-kiezers nou eenmaal niet verder gaat.

Ik denk dat de windows 'verboden combinaties' een mix zijn van enig reeel security voordeel (000, 1234) en de noodzaak om _iets_ gedaan te hebben en niet eindeloos lastig gevallen te worden door alle betweters die menen te weten dat geboorte data altijd verboden moeten worden "want dat weet iedereen" .

De kans dat iemand die je pincode probeert te raden en die je geboortejaar kent die ook uitprobeert is wel degelijk groter dan de kans dat die iets iets volkomen willekeurigs kiest. En ik heb al meer dan eens gezien dat bij pincodes voor toegang tot installaties die door meerdere monteurs bediend werden briljante codes als "1234" gebruikt werden. Het voegt wel degelijk iets toe om een code te kiezen die niet zo'n makkelijk patroon volgt en niet aan iets of iemand te relateren is, zoals een geboortejaar. Als je wel dat soort codes gebruikt wordt de kans dat iemand goed gokt aanzienlijk groter dan wanneer je echt iets willekeurigs kiest.

CPU's en GPU's hebben vaak vier cijfers als type-aanduiding. Een game PC met een Nvidia 4080, dat getal zal ik als eerste proberen en daarna die van de CPU. Omdat we het hier toch altijd over een lokale aanval hebben met de lokale hardware gebonden TPM. De pincode staat als het goed is niet in de cloud en als die in de cloud staat dan ben je online en kun je online een remote aanval uitvoeren.

TS

Kevin Mitnick was ooit zo'n beruchte hacker dat hij niet alleen tot een gevangenisstraf werd veroordeeld, maar ook een tijdlang geen IT apparatuur mocht gebruiken. Als je zijn boeken leest, merk je dat zijn aanvallen voor 95% uit social engineering bestonden, meestal via telefoongesprekken. Dus ja, een aanvaller kan weten wat je geboortejaar is en er is een (te) grote groep gebruikers die hun geboortejaar als PIN gebruiken. Deze gebruikers moet je tegen zichzelf beschermen.

Dat heeft die Windows pincode ook!
Als je te vaak de verkeerde kiest wordt de TPM gewist en moet je de recovery key invoeren.
Als je die dan niet (meer) hebt ben je je data kwijt.
Hardstikke fijn die privacy!


Dat is een TOTAAL ANDER scenario.
De reden dat dit zo gesteld wordt is dat het vaak voorkomt dat er gehashte passwords gelekt worden en dat je dan met een dictionary met dat soort "zwakke wachtwoorden" het wachtwoord eenvoudig zou kunnen vinden.

Echter als de hash niet lekt en het wachtwoord kan alleen door "proberen" gevonden worden (dus niet door een offline aanval maar via het login mechanisme) dan is het aantal pogingen een goede beveiliging tegen dit soort wachtwoorden.
En hetzelfde geldt voor pincodes.

Nee, het is helemaal analoog.

11 aug 13:20 stelde eigenlijk dat a priori als de aanvaller niks weet alle pincodes even waarschijnlijk zijn.

Bij gebruiker-gekozen codes (of het nu pin is, of een password) is dat gewoon niet zo , en kiezen mensen 'onthoudbare' combinaties , die dus raadbaar zijn.

Of heel simpel , en ietsje complexer (passwordjuli2024) . De dictionary crackers kunnen ook online testen (zet je ssh poort maar open) , maar dan is het aantal raad-pogingen heel veel kleiner dan een offline test op een hash .
Desondanks - 1x per seconde 8 weken lang loopt ook door een hoop mogelijkheden.

Hoe dan ook - bij vier of vijf cijfer pincodes zijn er wat 'prettige patronen' die mensen veel vaker dan statistisch verwacht kiezen , en evenzeer zijn er bij 6-20 cijfer-en-letter-en-leesteken combinaties óók patronen die mensen graag kiezen .


gegeven dat mensen zelden een voldoende random keuze maken is een limiet op het aantal pogingen erg noodzakelijk.

Welnee!! Als je een 4-cijferige pincode hebt (ik denk dat deze Microsoft pincodes meestal geconfigureerd staan op 6 of meer cijfers) dan zijn er 10000 mogelijkheden en je hebt 5 pogingen om te raden dus 5/10000 kans.
Op het moment dat je pincodes gaat "uitsluiten" op een bekende manier, dan maak je die 10000 kleiner en de kans dus groter.

Je kunt wel beweren "ja zal wel 0000 of 1111 of 1234 of 4321 of 2468 of het geboortejaar zijn of de postcode of dit of dat" maar als je niet weet wat er gekozen is kun je dat ook niet invullen en je bent zo door je 5 pogingen heen.



Je moet wel erg dom bezig zijn als je heel veel loginpogingen toelaat zonder lockout!

Doe dat niet zo dom autistisch .

Mensen kiezen gewoon GEEN RANDOM PINCODES. Dat is een heel erg empirisch gegeven.

Ook al heb je maar vijf pogingen , de kans op succes met '0000' en '1234' is heel wat groter dan 1/10.000 .

Met het uitsluiten van een klein deel van de veel gekozen codes dwing je een wat uniformere spreiding over de resterende zoekruimte af.

Die zoekruimte moet dan groot genoeg blijven zijn dat de kans op succes met drie of vijf pogingen de statistiek weer benadert .

Als je pincodes kunt _toewijzen_ (in plaats van laten kiezen door gebruikers) is er inderdaad niks mis met het toewijzen van een 'domme' pincode .
In dat geval zou je min of meer uit marketing/perceptie overweging alleen (mensen klagen dat ze 0000 gekregen hebben) de 'al te domme' pincodes uitzonderen.
Evenzeer is bij een loterij 1234567890 net zo goed of slecht als iedere andere combinatie , ook al voelt het als 'slecht' lot want "dat kan nooit gebeuren" .

(uit andere overweging : bij loterijen die de prijs delen door het aantal mensen dat een lot of combinatie koos moet je andermans gelukscombinaties mijden - want dan deel je de prijs met meer mensen ).

Maar een aanvaller die weet dat mensen zelf een code hebben mogen kiezen , vergroot z'n kans op succes heel sterk door in dat geval "typische" codes eerst (of alleen) te proberen.
Precies daarop zijn alle dictionary crackers geoptimaliseerd. Een rondje brute force voor zo ver als je kunt komen is een last resort , maar de eerste en snelste resultaten komen uit dictionary woorden en simpele permutaties ervan.
Soms zelfs zo snel dat het ook on-line kan - de scan-ruis op Internet doet dat. En het werkt in genoeg gevallen.


Voor een _garantie_ op succes heb je voldoende pogingen nodig, maar voor een _kans_ op succes is een handjevol pogingen ook goed.


Na hoeveel pogingen mag van jou een gmail account gelocked worden ? En voor hoe lang ?
Het vervelende van een strakke lockout is het ook een denial of service op de werkelijke gebruiker kan geven , eventueel bewust. .
Wat ga je daarvoor doen ?
In een kleine setup is het antwoord "bel de helpdesk" . Dat schaalt niet.

Het punt is dat van die makkelijk te raden codes de kans dat die gebruikt zijn niet 1/10000 per code is maar aanzienlijk groter. Dan is de kans dat die 5 pogingen doel treffen ook veel groter.

Het is waar dat als je die uitsluit de kans op de niet uitgesloten codes groter wordt (in dit geval ongeveer 1% groter). Je maakt alleen een denkfout als je de situatie beoordeelt alsof alle codes gelijkwaardig zijn. Als zoveel mensen voor makkelijke codes kiezen, die dus ook makkelijk te raden zijn, dat de toename van ellende daardoor groter is dan die 1%, dan verbeter je de situatie door die codes wel uit te sluiten. Je moet alle factoren die meespelen meewegen, en daar niet selectief in zijn.

Als je al een pincode van voldoende lengte zou mogen kiezen, dan zou ik dit doen met toevalsgetallen die in lijsten zijn gepubliceerd en in de boeken staan van de mathematische statistiek.

Hoe denken jullie daarover?

Ik ga hier zeker in mee, mensen hebben vaak een voorkeurscode die wordt uitgebreid of logisch opgevolgd.

6 cijfers nodig, dan de gebruikelijke 4 + 00 , of 00 + gebruikelijke 4
Pw met maanden
Pw hobby op interesse gerelateerd

etc etc.

De berekeningsformule kan ik helaas niet geven.

Hier is zo'n boek als PDF uit 2002, en ze noemen het zelfs als mogelijke toepassing in de inleiding:
https://www.crockford.com/image/million.pdf
Leef je uit ;-)

Het verrast me dat zo'n boek in 2002 nog is gemaakt. Zoals het boek zelf aangeeft is het al sinds de jaren 1980 overbodig omdat er toen goedkope computers beschikbaar zijn gekomen die prima toevalsgetallen kunnen produceren. Vandaag de dag bevatten besturingssystemen standaard generatoren van toevalsgetallen en pseudo-toevalsgetallen die geschikt zijn voor gebruik in cryptografische toepassingen (en die lat ligt hoger dan voor statistische toepassingen, al zal het voor een viercijferige pincode denk ik geen merkbaar verschil maken).

Als je Python op je systeem hebt kan je hiermee viercijferige pincodes genereren:

Verander range(4) in bijvoorbeeld range(6) voor zescijferige pincodes. De "secrets"-module maakt via faciliteiten van het besturingssysteem (Windows, Linux, Unix, waaronder vast ook OS/X) toevalsgetallen die aan de eisen van cryptografische toepassingen voldoen.

Het lijkt me niet geweldig.

Ook al zijn dergelijke reeksen inderdaad (ooit) random uniform gemaakt - juist het feit *dat* ze gepubliceerd zijn (en ook nog in jouw boekenkast staan) maakt ze beduidend minder geschikt.

Als je echt random getal nodig hebt, dan maak je dat . De computer (dev/random) doet dat prima.

Zelf een dobbelsteen gooien is ook goed, ook al duurt het dan even voordat je 'voldoende lange' getallen hebt .
Nog meer als je bias-removal doet . (zie von Neumann trick om met een 'biased coin' toch unbiased resultaat te krijgen)
https://en.wikipedia.org/wiki/Fair_coin

Als je experimenten/testen doet die random getallen vereisen maar toch herhaalbaar moeten zijn is zo'n boek perfect.
Voor zo'n geval kun je ook een pseudo-RNG gebruiken met een bekende seed - dan is de uitkomt ook bruikbaar (maar duidelijk niet true-random) .

Als je met beperkte informatie om op te slaan/te onthouden toch een lange reeks onvoorspelbare uitkomsten wilt zijn er een hoop opties - allerlei pseudo-RNGs, of gewoon een crypto cipher . Of , in jouw geval - de pagina en kolom van je boek waar je begint.

Even voor de duidelijkheid: De OP heeft het over pincodes bij Windows Helo. Dat betekent dus lokaal inloggen. Alle opmerkingen over toegang via het netwerk en wachtwoorden hebben hier dus niet mee te maken.


Het nadeel van "lokaal" is dat de aanvaller veel meer weet van het potentiele slachtoffer dan een willekeurige aanvaller die een wachtwoord via het netwerk probeert. Pincodes komen ook niet in gehashte databases terecht.


Omdat het een lokale aanval betreft, kun je 4 pogingen doen. Dan wacht je tot het slachtoffer zelf weer heeft ingelogd. De teller reset en je kunt zonder problemen weer 4 pogingen doen.

Peter

Helemaal eens, maar de TPM is hiermee niets anders dan de T2 van Apple. Zowel de TPM als de T2 zijn zowel te gebruiken voor encryptie als digital rights management. Daarnaast zijn ze, met wat meer kennis, te gebruiken als "watermerk".

En eerlijk is eerlijk, met de geopolitieke situatie ook een prima instrument om bepaalde regio's komende maanden beter te monitoren en bovenal: uit te kunnen sluiten ... We gaan meer en meer naar een twee (of drie) deling van de wereld geopolitiek, maar ook een verdere splitsing in "gepriviligeerde', '(ten dele) gepriviligeerde pleb', 'pleb' en 'persona non grata'.

Voor niet iedereen een probleem, maar ik vermoed dat het vrije computergebruik z'n langste tijd heeft gehad. We gaan meer naar een iOS/Android/PS4-5 model waarbij software ook regio-gebonden gebruikt gaat kunnen worden. TPM (en T2) is daarbij slechts een stuk in de keten, maar een belangrijk stuk.

Natuurlijk beveiliging is hier het sleutelwoord, alleen is hetgeen wat nu precies beveiligd moet worden, alsmede wie nu feitelijk hier verder afzwakt richting de rol van gebruiker met bijzonder beperkte rechten, is dus de (eind)gebruiker.

Ik kwam deze onlangs tegen: https://informationisbeautiful.net/visualizations/most-common-pin-codes/

Er zit wat in.....

Die van mij staan er gelukkig niet bij.

Nice.
Was nog mooier geweest met URL tags.

https://informationisbeautiful.net/visualizations/most-common-pin-codes/
En de uitleg van de maker is ook boeiend.

http://www.datagenetics.com/blog/september32012/index.html

Hè bah! (BASIC). In Haskell:


Output:

Geinig maar ik zou die generateTable functie eruit hebben gelaten (less is more; die list comprehension is al hartstikke leesbaar). Gewoon:

Het is wel goed om je variabelen te declareren voordat je ze gebruikt. Dan weet de compiler (of de lezer van de broncode) welk type alles is.

In mijn BASIC voorbeeld doe ik het ook niet, GWBASIC dwingt dat niet af. Het zou wel beter zijn geweest als ik het wel had gedaan. En misschien ook wat duidelijker namen (INT Delta in plaats van B), maar INT() is een functie in GWBASIC dus dat werkt vast niet.


lol,
TS

Oh, dat ben ik zeker met je eens, maar die functie was zo summier, dat voegt eigenlijk niets toe.

In JSD/JSP: Declareer altijd alle variabelen.
Ook al is de functie nog zo summier, in een grotere structuur werpt het zijn vruchten af.
Zelfs in BASIC.

Nou... Gelukkig maar zijn alle variabelen in bovenstaande code gedeclareerd.

Hmmm. Oké.