/dev/null - Overig

De verboden reeksen van Satya Nadella

10-08-2024, 19:53 door Anoniem, 27 reacties
Noodgedwongen ben ik mij aan het verdiepen in het Windows Hello systeem dat via de Trusted Platform Module (TPM) zijn werk doet om Windows gebruikers veilig te houden.

Op https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/faq staat uitgelegd dat een PIN code van vier cijfers geen constante 'delta' mag hebben.

Omdat ik niets anders te doen heb deze vakantie, heb ik in DOSBox in GWBASIC een programma geschreven om deze verboden reeksen weer te geven. Het is wel even wennen na al die decennia dat ik hiermee programmeer ervaring had.

10 FOR A = 0 TO 9
20 FOR B = 0 TO 9
30 PRINT USING "#"; A;
40 PRINT USING "#"; (A + B) MOD 10;
50 PRINT USING "#"; (A + 2*B) MOD 10;
60 PRINT USING "# "; (A + 3*B) MOD 10;
70 NEXT B
80 PRINT
90 NEXT A
100 END

Dit zijn de verboden reeksen van Satya Nadella. Er zitten best reeksen tussen die ik zelf zeer veilig zou vinden en die niet in een paar pogingen geraden kunnen worden voordat de TPM de zaak op slot doet.

0000 0123 0246 0369 0482 0505 0628 0741 0864 0987
1111 1234 1357 1470 1593 1616 1739 1852 1975 1098
2222 2345 2468 2581 2604 2727 2840 2963 2086 2109
3333 3456 3579 3692 3715 3838 3951 3074 3197 3210
4444 4567 4680 4703 4826 4949 4062 4185 4208 4321
5555 5678 5791 5814 5937 5050 5173 5296 5319 5432
6666 6789 6802 6925 6048 6161 6284 6307 6420 6543
7777 7890 7913 7036 7159 7272 7395 7418 7531 7654
8888 8901 8024 8147 8260 8383 8406 8529 8642 8765
9999 9012 9135 9258 9371 9494 9517 9630 9753 9876

Sommige toegestane pincodes zijn niet zo veilig. Iedereen die in de vorige eeuw geboren is, behalve in 1975, kan zijn geboortejaar gebruiken als PIN. Iedereen die in deze eeuw geboren is voor 2086 trouwens ook.

TS
Reacties (27)
10-08-2024, 23:20 door johanw
De TPM is vooral voor DRM bedoeld, het doet vooral werk om bedrijven te beschermen tegen gebruikers.
11-08-2024, 13:20 door Anoniem
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.
11-08-2024, 14:19 door Anoniem
Door Anoniem: 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.

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.


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.

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" .
11-08-2024, 15:26 door Anoniem
Door Anoniem: 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.
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.
12-08-2024, 11:39 door Anoniem
Door Anoniem: 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
12-08-2024, 11:49 door User2048
Door Anoniem: 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.
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.
12-08-2024, 14:23 door Anoniem
Door Anoniem:
Door Anoniem:
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.

Een vier of vijf cijfer PIN moet het qua security toch hebben van een heel snelle lockout (3-10 pogingen)
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!

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.

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.
12-08-2024, 15:58 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem:
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.

Een vier of vijf cijfer PIN moet het qua security toch hebben van een heel snelle lockout (3-10 pogingen)
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!

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.

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.

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 .


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.

gegeven dat mensen zelden een voldoende random keuze maken is een limiet op het aantal pogingen erg noodzakelijk.
12-08-2024, 18:22 door Anoniem
Door Anoniem:
Door Anoniem:
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.

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.

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.


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.

Je moet wel erg dom bezig zijn als je heel veel loginpogingen toelaat zonder lockout!
12-08-2024, 21:06 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem:
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.

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.

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.

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.


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.

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

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.
13-08-2024, 08:36 door Anoniem
Door Anoniem: 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..
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.
13-08-2024, 11:49 door Anoniem
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?
14-08-2024, 08:52 door Bitje-scheef
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.

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.
14-08-2024, 10:43 door Anoniem
Door Anoniem: 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?
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:

import secrets
print("".join(secrets.choice("0123456789") for i in range(4)))

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.
14-08-2024, 16:24 door Anoniem
Door Anoniem: 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?

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.
15-08-2024, 10:22 door -Peter-
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.

Door Anoniem:
Door Anoniem:
Door Anoniem:
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.

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.

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.

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.

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.

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

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
18-08-2024, 17:52 door Anoniem
Door johanw: De TPM is vooral voor DRM bedoeld, het doet vooral werk om bedrijven te beschermen tegen gebruikers.

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.
19-08-2024, 09:59 door Anoniem
Ik kwam deze onlangs tegen: https://informationisbeautiful.net/visualizations/most-common-pin-codes/

Er zit wat in.....
19-08-2024, 14:37 door Anoniem
Door Anoniem: 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.
19-08-2024, 15:45 door Anoniem
Door Anoniem: Ik kwam deze onlangs tegen: https://informationisbeautiful.net/visualizations/most-common-pin-codes/

Er zit wat in.....

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
19-08-2024, 17:50 door Xavier Ohole - Bijgewerkt: 19-08-2024, 17:56
Door Anoniem:Omdat ik niets anders te doen heb deze vakantie, heb ik in DOSBox in GWBASIC een programma geschreven om deze verboden reeksen weer te geven. Het is wel even wennen na al die decennia dat ik hiermee programmeer ervaring had.

Hè bah! (BASIC). In Haskell:

generateTable :: [(Int, Int, Int, Int)]
generateTable = [(a, (a + b) `mod` 10, (a + 2 * b) `mod` 10, (a + 3 * b) `mod` 10) | a <- [0 .. 9], b <- [0 .. 9]]

main :: IO ()
main = mapM_ print generateTable

Output:

(0,0,0,0)
...
(9,8,7,6)
22-08-2024, 07:54 door Krakatau
Door Xavier Ohole:
In Haskell:

generateTable :: [(Int, Int, Int, Int)]
generateTable = [(a, (a + b) `mod` 10, (a + 2 * b) `mod` 10, (a + 3 * b) `mod` 10) | a <- [0 .. 9], b <- [0 .. 9]]

main :: IO ()
main = mapM_ print generateTable

Output:

(0,0,0,0)
...
(9,8,7,6)

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

main :: IO ()
main = mapM_ print [(a, (a + b) `mod` 10, (a + 2 * b) `mod` 10, (a + 3 * b) `mod` 10) | a <- [0 .. 9], b <- [0 .. 9]]
22-08-2024, 14:18 door Anoniem
Door Krakatau: Geinig maar ik zou die generateTable functie eruit hebben gelaten (less is more; die list comprehension is al hartstikke leesbaar). Gewoon:

main :: IO ()
main = mapM_ print [(a, (a + b) `mod` 10, (a + 2 * b) `mod` 10, (a + 3 * b) `mod` 10) | a <- [0 .. 9], b <- [0 .. 9]]

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.

GW-BASIC 3.22
(C) Copyright Microsoft 1983,1984,1985,1986,1987
60300 Bytes free
Ok
10 int a
20 print a
30 end

run
Syntax error in 10
Ok
10 INT A

lol,
TS
22-08-2024, 22:51 door Krakatau
Door Anoniem:
Door Krakatau:
main :: IO ()
main = mapM_ print [(a, (a + b) `mod` 10, (a + 2 * b) `mod` 10, (a + 3 * b) `mod` 10) | a <- [0 .. 9], b <- [0 .. 9]]

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.

Oh, dat ben ik zeker met je eens, maar die functie was zo summier, dat voegt eigenlijk niets toe.
23-08-2024, 09:14 door Anoniem
Door Krakatau:
Door Anoniem:
Door Krakatau:
main :: IO ()
main = mapM_ print [(a, (a + b) `mod` 10, (a + 2 * b) `mod` 10, (a + 3 * b) `mod` 10) | a <- [0 .. 9], b <- [0 .. 9]]

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.

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.
24-08-2024, 08:27 door Krakatau
Door Anoniem:
Door Krakatau:
Door Anoniem:
Door Krakatau:
main :: IO ()
main = mapM_ print [(a, (a + b) `mod` 10, (a + 2 * b) `mod` 10, (a + 3 * b) `mod` 10) | a <- [0 .. 9], b <- [0 .. 9]]

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.

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.

Nou... Gelukkig maar zijn alle variabelen in bovenstaande code gedeclareerd.
25-08-2024, 09:43 door Xavier Ohole
Door Krakatau:
Door Xavier Ohole:
In Haskell:

generateTable :: [(Int, Int, Int, Int)]
generateTable = ...

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

main :: IO ()
main = mapM_ print [(a, (a + b) `mod` 10, (a + 2 * b) `mod` 10, (a + 3 * b) `mod` 10) | a <- [0 .. 9], b <- [0 .. 9]]

Hmmm. Oké.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.