90 procent van DigiD-gebruikers gebruikt dienst zonder sms-authenticatie -update

Uit een woensdag gepubliceerd rapport van de Rekenkamer blijkt dat negentig procent van het DigiD-gebruik gebeurt zonder tweetrapsauthenticatie. De organisatie constateert verder dat de encryptie onvolledig is, maar dat dit een klein risico is.

In zijn bevindingen schrijft de Rekenkamer: "Van de circa 250 miljoen maal dat gebruik wordt gemaakt van DigiD, is dat in 90 procent van de gevallen met een eenvoudig wachtwoord én zonder sms. In veel gevallen is dit lage betrouwbaarheidsniveau niet conform de regels, bijvoorbeeld bij het raadplegen van fiscale of donorgegevens." Volgens de minister van Binnenlandse Zaken zijn organisaties zelf verantwoordelijk voor de toepassing van 'het juiste betrouwbaarheidsniveau'. Het inloggen met 'een extra controle via sms' is optioneel.

Daarnaast besteedt de Rekenkamer aandacht aan de encryptie van DigiD-gegevens. Deze bleek in de afgelopen jaren niet te voldoen aan de eisen. In 2016 is door middel van een audit vastgesteld dat er op het gebied van periodieke beveiligingsonderzoeken, en op dat van logging en analyse voldoende maatregelen zijn getroffen. De encryptie is nog steeds alleen gedeeltelijk en voldoet niet aan de geldende regels, maar het misbruik van de gegevens zou door andere veiligheidsmaatregelen 'tot een gering risico' beperkt zijn. De minister nam daarom in oktober 2016 de beslissing om het restrisico te aanvaarden. Encryptie moet volgens de minister worden toegepast in de opvolger van DigiD, die begin 2018 wordt verwacht, aldus de Rekenkamer.

Andere bevindingen uit het rapport van de Rekenkamer zijn dat er bij het rijk onvoldoende deskundigheid aanwezig is op verschillende gebieden, waaronder ict. Dat speelt ook bij de politie, waar ondanks verschillende wervingsrondes nog steeds te weinig ict-experts werkzaam zijn, waardoor groeiende recherchegebieden als internetcriminaliteit te weinig aandacht krijgen. De Rekenkamer constateerde dan ook voornamelijk problemen met de bedrijfsvoering van het rijk op het gebied van ict en informatiebeveiliging.

Aan dat laatste gebied moeten ministeries meer aandacht besteden. De Rekenkamer stelt: "Er is daarnaast bestuurlijke aandacht vereist om gevoelige gegevens van burgers over een strafrechtelijk verleden, orgaandonatie, belasting- of medische informatie beter te beschermen. En om identiteitsfraude, het hacken van systemen voor de bediening van bruggen en sluizen of andere kritieke systemen tegen te gaan."

Update, 15:14: Naar aanleiding van het bericht is enige verwarring ontstaan over de vraag of de Rekenkamer de sterkte of complexiteit van wachtwoorden heeft onderzocht. In afwachting van een officiële reactie vanuit de Rekenkamer is de tekst daarom aangepast om verwarring te voorkomen. In het oorspronkelijke artikel stond dat 90 procent van het gebruik van DigiD plaatsvindt met een zwak wachtwoord en zonder sms-authenticatie. De tekstdelen over zwakke wachtwoorden zijn voorlopig aangepast.

Update, 18:18: Een woordvoerder van de Rekenkamer heeft bevestigd dat de bewoording 'eenvoudig wachtwoord' slaat op de manier van inloggen en geen oordeel velt over de kwaliteit van het wachtwoord. De wijzigingen in het artikel blijven daarom van kracht.

Reacties (401)

[Grannd]

Ik heb vanaf het begin af aan die 'optionele 2-staps verificatie' niet begrepen.
Als je bij iemand anders' account in wil loggen en je heb alleen het wachtwoord, hoef je altijd dus gewoon ervoor te kiezen om de optionele 2-factor-authenticatie niet te gebruiken
Als burger heb je zelf niet de keus om 2-factor-authenticatie standaard aan te zetten voor elke inlogpoging dat moeten de instanties zelf verplichten.

En dan nu een paar jaar later komen we met een (duur?) onderzoek waaruit blijkt dat dat erin resulteert dat 90% van de mensen er geen gebruik van maakt...
De overheid en IT (Security), dat blijft altijd lachen.

Edit: Op basis van de reacties hieronder is het dus wel mogelijk om er zelf voor te kiezen dat je alleen in kan loggen dmv 2-factor authenticatie.
Maakt het verhaal iets logischer, de overheid heeft dus nog steeds een duidelijke taak mensen hierover te informeren maar zoals Martindo zegt denk ik dat verplicht stellen het enige nuttige zal zijn.
De mens kiest altijd de route van de minste weerstand, en elke keer je telefoon moeten pakken als je wil inloggen, daar zit toch niemand op te wachten.

[Reactie gewijzigd door Grannd op 24 juli 2024 21:19]

[Koenvh]

Het is wel degelijk mogelijk om zelf ervoor te kiezen om 2-factor-authenticatie altijd te vereisen. Als ik probeer in te loggen zonder krijg ik de melding:
"U heeft ingesteld altijd met niveau Midden te willen inloggen. U kunt niet inloggen zonder een juiste sms-code in te vullen."
Kun je zelf wijzigen door in te loggen bij Mijn DigiD

[Reactie gewijzigd door Koenvh op 24 juli 2024 21:19]

[jerkitout]

Ik moest wel even zoeken..

Voor andere mensen, hier is de link: https://mijn.digid.nl/inloggen_voorkeur

[Balachmar]

Held!
Ik had precies hetzelfde idee als de eerste poster.
Ik had deze optie ook niet gevonden, slecht menu design...

[Habana]

Thanks nooit geweten gelijke veranderd, bij mij stond beiden op actief, maar met instelling op basis, nu op niveau Midden, stom dat men dat niet duidelijk aangeeft bij het aan maken van je Digid, eigenlijk zou die keuze er ook helemaal niet moeten zijn, standaard 2-factor-authenticatie..

[casparvl]

Kijk, dit is nuttige info, dank!

Ik dacht oorspronkelijk dat het systeem wellicht zo was dat je voor minder kritische dingen gewoon met alleen wachtwoord kon volstaan - maar ik heb nog geen toepassing gevonden waarbij ik PER SE met 2-factor authenticatie moest inloggen, terwijl in feitte vrijwel álles wat ik met DigiD doe toch best kritisch is.

Ik ga het meteen instellen

Edit: Ik lees dat mijn oorspronkelijke gedachte op zich correct was, er zijn blijkbaar diensten die wél standaard niveau 'midden' vereisen. Ik ben ze alleen blijkbaar nog nooit tegengekomen... "Basis, ik wil inloggen met gebruikersnaam en wachtwoord tenzij de dienst anders vereist"

[Reactie gewijzigd door casparvl op 24 juli 2024 21:19]

[eelco74]

Er zijn een aantal zorgverzekeraars die voor sommige diensten 2 factor verplichten.

[Johnny]

Nog zo'n verwonderlijk iets van DigiD; wat moet een private onderneming met winstoogmerk zoals een zorgverzekeraar met een authenticatiesysteem voor overheidsdiensten?

[netman]

Voor zorgverzekering is tegenwoordig BSN vereist.

Digid is het enige middel waarmee het BSN kan worden geverifieerd.

[eelco74]

Dat heb je dan niet begrepen, want het is zowel voor de private als de publieke sector. Dus niet alleen overheid. Wel zo prettig voor de burger, om 1 toegangscode te hebben voor meerdere partijen. Niet alleen verzekeraars (zowel zorg als pensioen), maar ook gemeenten, provicies etc maken gebruik van DigiD.

een exacte lijst staat op DigiD.nl: https://www.digid.nl/over-digid/wie-doen-mee/

[batjes]

Ik kan mijn gemeente meuk zonder 2 factor, maar DUO is wel 2 factor voor nodig. Nu stuurt DUO de hele sessie langs amerikaanse servers want statistieken, dus daar is 2 factor ook gewoon nodig om onhackbaar te blijven.

Als je er voor kiest geen 2 factor te gebruiken, kan dit alsnog wel opgedwongen worden, afhankelijk van de overheiddienst.

[BStorm]

Wat bedoel je hier (meer precies) mee?

>> Hoe voorkom je met 2 factor authenticatie dat big data brother de boel hackt? En wat wordt dan zoal gehackt?

Sessie betekent iets van een datastroom over je internetverbinding, toch..?

[batjes]

Geen idee of het nu nog zo is, ik had 1/5-2 jaar geleden er melding van gemaakt bij de IT afdeling van DUO. Maar zodra je inlogt, wordt je sessie op duo.nl volledig omgeleid via nl.sitestat.com (dacht ik, zo uit mijn hoofd). Zonder 2 factor kunnen ze met een beetje moeite dus die login sessie kapen en dus je account overnemen.

[BStorm]

Login kapen en overnemen..
Da's er wel even niet de bedoeling nee

(met Dank voor de toelichting @batjes !)

[batjes]

Nee zeker niet, ik vond het echt zwaar overantwoord van een overheids dienst om zo sessies om te leiden naar het buitenland, enkel en alleen voor stats. Het was ook geen include of iets dergelijks, gewoon een volledige redirect naar nl.sitestat.com die je weer terug redirecte naar duo.nl, je zag hier ook niets van. Ik kwam er toevallig achter omdat ik nl.sitestat.com in mijn hosts had staan en dus gewoon totaal niet kon inloggen op DUO.

Je hoeft sessies niet om te leiden voor site statistieken. En al helemaal niet tijdens het inloggen zoals bij DUO gebeurd(e)

[omkelderman]

Als ik me goed herrinner is de DUO een voorbeeld van een dienst die 2fa vereist. Maar ik heb sinds enige tijd dit ook globaal aanstaan in de digid-instellingen, dus kan het nu niet meer controleren

[FrankHe]

Dank. Enkele jaren geleden heb ik naar deze functie gezocht maar nooit kunnen vinden. Vond het maar raar dat je dit niet in kon stellen. Anders slaat die SMS controle natuurlijk helemaal nergens op als die niet verplicht is. Kennelijk hebben ze het nu als nieuwe functie toegevoegd, dat werd tijd. Of het ligt aan mij en de mogelijkheid is er altijd al geweest alleen hebben ze het nu minder ver verstopt. Ik zou verwachten dat ze dit actief promoten. U heeft SMS controle ingesteld, wilt u dit voortaan 'verplicht' maken? Ja graag natuurlijk anders had ik niet alle moeite genomen om het te activeren. Duh.

[ninjazx9r98]

Dit is geen nieuw toegevoegde functie maar zit er al jaren in. Geen idee hoe lang precies maar denk dat ik het al zeker een jaar of vijf aan heb staan.

[Homerius]

Gelukkig is het sinds enige tijd mogelijk om aan te geven dat je altijd gebruik wil maken van de tweede factor:

Voorkeur inlogniveau

U kunt uw voorkeur inlogniveau aangeven en kiezen voor Basis of Midden. Als u kiest voor Basis, dan geeft u aan dat u wilt inloggen met gebruikersnaam en wachtwoord tenzij anders vereist is. Als u kiest voor Midden, dan logt u standaard in met de DigiD app of een extra controle via sms. De keuze voor inlogniveau Midden maakt uw DigiD veiliger.

In dat geval moet je dus altijd de sms-code invullen en is het niet meer mogelijk om met alleen gebruikersnaam en wachtwoord in te loggen.

De optie om tijdens het inloggen te kunnen kiezen voor "Ik wil inloggen met een extra controle via sms" is inderdaad absurd.

[FrankHe]

...
De optie om tijdens het inloggen te kunnen kiezen voor "Ik wil inloggen met een extra controle via sms" is inderdaad absurd.

Dank u, ik ben gelukkig niet de enige die deze keuze op z'n minst "opmerkelijk" vind.

[Martindo]

Ik vraag me af of de verplichte vorm ooit zal komen, maar als dat er wel komt dan begrijp ik deze manier wel. Het is een overgang. Zomaar van dag op dag aankondigen: "Je moet nu 2FA gebruiken!" zullen mensen van schrikken en heisa maken.

De mogelijkheid dat het aangeboden wordt, is al prachtig. En bij veel andere systemen is het ook optioneel: je moet het zelf inschakelen voor je het gebruiken kan. Daarbij heeft niet iedere Nederlander een mobiele telefoon, vooral de ouderen. Ik zie regelmatig oudere mensen met een oud Nokia 3310 (of iets wat erop lijkt) die met moeite de telefoon kunnen opnemen.

Ik denk dat de overheid daarom ook in een lastige situatie zit van het introduceren van 2FA. Je kunt niet garanderen dat iedere Nederlander de mogelijkheid en kennis heeft om 2FA te gebruiken. Genoeg ouderen die het mobiele telefoontje ergens in een la bewaren als ze niet de deur uitgaan. En dan moet je een compromis sluiten, optionele 2FA is daarin de beste mogelijkheid.

[Reactie gewijzigd door Martindo op 24 juli 2024 21:19]

[Anoniem: 636203]

Ik denk dat het uiteindelijk wel verplicht moet worden, want iedereen heeft een mobieltje en het kan niet zo moeilijk zijn om de 6 cijfers die je in een SMS binnenkrijgt in te typen.

De verbetering van de beveiliging met 2FA is enorm. Gezien de zeer persoonlijke gegevens waar de overheid over beschikt vind ik dat dit optimaal beschermd moet zijn.,

[incaz]

Niet iedereen heeft een mobieltje. En andere mensen hebben wellicht wel een mobieltje maar niet een telefoonnummer dat over langere tijd constant is. (Bij prepaid moet je immers steeds iets doen om je nummer te behouden, anders vervalt het. Niet erg als je dat mobieltje alleen maar in de kast hebt liggen voor af en toe - een prepaid kaartje als je op reis gaat is zo gekocht. Maar voor 2FA heb je daar dus niets aan.)

[Anoniem: 636203]

Nou en? Niet iedereen heeft een computer. Maar dat weerhoudt de overheid er niet van om alle contact met die zelfde overheid over te schakelen naar internet.

En ik denk dat het niet realistisch is om rekening te moeten houden met een paar kluizenaars die geen mobieltje hebben.

[incaz]

Er gaan geruchten rond dat lang, lang geleden de overheid ook een beetje in dienst van de mensen stond. Omdat de overheid nu al eisen stelt, hoeven we niet na te denken over de overige eisen is niet zo'n heel sterk uitgangspunt.

Maar goed, eigenlijk was mijn reactie simpeler. Jij stelde dat iedereen mobieltje heeft. Dat is niet waar.

[Anoniem: 636203]

Net zo goed als je nu ook geen besturingssysteem hoeft te maken voor mensen die nog nooit een computer hebben gebruikt (die zijn feitelijk bijna niet meer te vinden in het Westen), hoef je ook geen rekening te houden met een hele kleine minderheid die geen mobiele telefoon heeft. Hoeveel mensen zijn dat in heel NL? Een paar duizend? Hooguit zou ik zeggen.

Net zo goed vind ik dat gezeur over die 'gender neutral' toiletten nergens over gaan.

[Aardwolf]

Niet iedereen heeft een mobiel of kan daar mee overweg... Ik vind dan ook niet dat 2FA op die manier verplicht moet worden. 2FA kan je natuurlijk ook wel op andere manieren bereiken. Iets als de Rabobank doet met zo'n reader of een stick als key, etc... genoeg manieren.

Ik dacht tevens eens te hebben gelezen dat toegezonden tekst in SMS tevens prima te onderscheppen/ondermijnen is. Natuurlijk veiliger dan niks, maar ook niet heilig... dus daar moet over nagedacht worden als je het voor iedereen verplicht, ook ouderen en andere minder onderlegde mensen. Het moet veilig, makkelijk en foolproof zijn.

[Franckey]

...want iedereen heeft een mobieltje en het kan niet zo moeilijk zijn om de 6 cijfers die je in een SMS binnenkrijgt in te typen.

Nog handiger: Skype is op Windows 10 mobile bij mij de default SMS app. En omdat ik de SMS berichten laat synchroniseren met Skype op laptop en pc kan ik de authenticatie code gewoon copy/pasten.

[ninjazx9r98]

Als je 6 cijfers in een sms krijgt om in te loggen gaat er iets gruwelijk fout. Het zijn 9 karakters en het is een mengvorm van cijfers en hoofdletters.

[stresstak]

Ik zie regelmatig oudere mensen die met moeite de telefoon kunnen opnemen.

Het opnemen is niet per se de kunst, maar ik had geen plannen een mobiele telefoon aan te schaffen voor 1 sms per jaar.

[Maistah]

En dit is ook de vraag die ik mijzelf heb gesteld. Je kunt gewoon vaak kiezen: Inloggen met of zonder SMS authenticatie. Beiden werken. De toegevoegde waarde is er naar mijn mening niet. Als je namelijk misbruik wilt maken kun je gewoon 1-step auth gebruiken.

Met een 2-step auth zou de ww-sterkte niet eens zoveel uitmaken. Maar ja, ik vraag me af of ze het zelf wel begrijpen hoe het allemaal werkt.

[incaz]

Die keuze is echt onzinnig. Het heeft zin om dat per gebruiker op te slaan (zoals 'altijd sms-verificatie gebruiken') en om het op pagina-niveau in te stellen (voor een afspraak bij de gemeente zonder dat er verdere gegevens over de lijn gaan, en zonder negatieve consequenties, geeft inloggen alleen geen veiligheidsrisico's, en zou de sitebeheerder dus kunnen kiezen voor 'geen 2FA als de gebruiker niet altijd sm-verificatie heeft ingesteld') maar de keuze bieden per bezoek is echt volslagen onzinnig. Het brengt mensen alleen maar in verwarring. Die optie zou er gewoon uit moeten.

[Anoniem: 636203]

Niet als je 2FA in heb gesteld. Dan kan je daarna niet meer met alleen een wachtwoord inloggen, want anders heeft het natuurlijk geen enkel nut.

[Erulezz]

Ik weet niet of dit bij alle instanties ook werkt maar ik heb laatst mijn beveiligingsniveau van "midden" naar "hoog" veranderd. Voorheen kreeg ik inderdaad de keuze om in te met alleen een wachtwoord of met een wachtwoord + sms code (wie heeft dit ooit verzonnen??). Maar sinds ik dat heb ingesteld op "hoog" krijg ik nu altijd een SMS code.

[brinkdinges]

Is het optionele gebruik van een sms wellicht bedoeld voor inloggen op PC's die je niet vertrouwt? Zodat je thuis kunt inloggen met alleen een wachtwoord en in een internetcafé de extra controle van een sms kunt gebruiken?

[Jace / TBL]

Dat is inderdaad compleet debiel.

Wat ik onlangs echter begreep is dat de betreffende overheidsinstantie die gegevens stuurt of opvraagt via DigiD, ervoor kan kiezen om voor bepaalde 'gevoelige' of 'hele belangrijke' gegevens 2FA verplicht te stellen.
Dus om bij bepaalde gegevens te komen is inloggen met alleen een password dan niet voldoende, dan moet je ook 2FA gebruiken. Nog nooit zelf tegengekomen trouwens, dus alleen van horen zeggen.

Maar alsnog vrij debiel natuurlijk dat je zelf als gebruiker niet kunt instellen dat die 2FA gewoon altijd verplicht is, voor je eigen veiligheid.

[Aardwolf]

Maar alsnog vrij debiel natuurlijk dat je zelf als gebruiker niet kunt instellen dat die 2FA gewoon altijd verplicht is, voor je eigen veiligheid.

Dat kan toch al jaren?

[hydex]

Dit klopt niet. Net zelf getest wanneer je bij Mijn.digid.nl kiest voor altijd sms inlog en je logt in met de optie gebruikersnaam wachtwoord wordt daarna altijd alsnog om een sms code gevraagd

[SneezyThunder91]

Hoe weten zij dat het met een zwak wachtwoord is? Kunnen zij de wachtwoorden inzien dan? Als dat zo is vind ik dat nog schokkender dan dit nieuwsbericht.

[Reactie gewijzigd door SneezyThunder91 op 24 juli 2024 21:19]

[duqu]

We wachten nog op antwoord op die vraag!

[Bitmaster]

En ze moeten niet zeuren, maar de verplichte moeilijkheidsgraad forceren.

[Pim_t]

Maar ook dat is arbitrair.
Een lang wachtwoord is bijvoorbeeld veiliger dan een wachtwoord met vreemde karakters.

[Kirupa]

Dan helpt het toch om een lang wachtwoord (hogere moeilijkheidsgraad) te forceren?

[Rob_03]

Wat daarbij helpt is een enorme shit load aan mensen die het vooral "kul" vinden.

Onlangs een verandering doorgevoerd in het aanmaken van een account. WW
Van minimaal 6 tekens naar voor nieuwe gebruikers "nieuw noodzakelijk" WW dat dient te bestaan uit.

1: minimaal 1 keer @#$% etc
2: minimaal 1 keer een Hoofdletter
3: minimaal 12 tekens lang te zijn

Optioneel is inderdaad ook nog eens sms verificatie.

Als voorbeeld geven we dan nog iets als een Aad#1234forMike

Grofweg gesteld:
30% snapt het niet
60% vindt het onzin
10% stelt geen vragen

En ik schat dat slechts 5% de 2 trap gebruikt.

Als commercieel product is het al een drama om te forceren. Indien je geen berucht Google of Facebook login gebruikt.

Kan je nagaan wat er gebeurd met een DigiD als je toegang blokkeert vanwege dit verhaal.

Edit: en met de mededeling "vooral "kul" bedoel ik dus dat men meent dat een dergelijk moeilijk WW helemaal niet nodig is en ze zelf eisen te kunnen kiezen wat nodig is.

[Reactie gewijzigd door Rob_03 op 23 juli 2024 13:34]

[PuzzleSolver]

Mensen blijven mensen, dus als je ze vraagt om nummers in te voeren zal dat voor 90% hun geboortejaar zijn. Vraag je om speciale karakters dan wordt dat vaak een ! op het eind. Vraag je om een hoofdletter dan beginnen ze hun wachtwoord met een hoofdletter. En de overige 10% had al een veilig wachtwoord waarvan een aantal nu niet meer aan de voorwaarden voldoet en zo schiet zoiets compleet z'n doel voorbij.

Net zoals geforceerd wachtwoordwijzigingen vereisen, ING forceerde mij b.v. m'n wachtwoord te wijzigen toen ik met een tablet op een camping wifi in Italië probeerde te bankieren. Wachtwoord wijzigen is iets wat je doet nadat een wachtwoord gecompromitteerd is, niet preventief omdat het misschien gecompromitteerd is. Als je al niet wist waarom het oude wachtwoord niet meer veilig zou zijn hoe kan je dat dan van een nieuw wachtwoord welk weten. Het moment dat je het wachtwoord wijzigt is sowieso een grotere kans om het wachtwoord te compromitteren aangezien het oude ww en het nieuwe ww(2x) wordt ingetypt. Laat staan wat sommige idiote sites over de lijn sturen tijdens deze actie.

[Reactie gewijzigd door PuzzleSolver op 24 juli 2024 21:19]

[hydex]

Het hele idee van beveiligingsexperts om een wachtwoord aan de bovengestelde eisen laten voldoen slaat compleet zijn doel voorbij.

1. Gebruikers kunnen dit wachtwoord niet onthouden dus schrijven het ergens op. (potentieel beveiligingsrisico)
2. Gebruikers die het niet hebben opgeschreven gaan een nieuw wachtwoord aanvragen. Procedure kost dagen voordat je een nieuwe per brief hebt ontvangen

Nee dan ben ik toch meer een voorstander van 2 traps authenticatie.

[Pim_t]

Wat ik heel vaag vind is dat ik bij het inloggen op de belasting site de keuze heb om wel of niet met de 2-trap in te loggen. Het feit dat ik het op dat moment wel gebruikt maakt het niet eenvoudiger, want ik kan mijn belastingen invullen zonder het te gebruiken.... terwijl ik wel heb ingesteld dat die 2-trap zou werken.

Dat moet dus niet op het moment van inloggen worden gevraagd maar bij het account aanmaken of de account instellingen. En dan daar naar handelen en niet een andere mogelijkheid bieden.

[hydex]

Wanneer je inlogt op mijn.digid.nl
kun je bij het tabblad inlogmethoden bij de optie Voorkeur inlogniveau wijzigen de basis veranderen in midden dat betekent dat je daarna alleen nog kunt inloggen via sms of de digid App die werkt met qr code scannen.
Kortom 2-traps authenticatie. Dit geldt ook voor websites die alleen de basis vragen. Vanaf dat moment moet je altijd met sms code in combinatie met gebruikersnaam en wachtwoord inloggen. De website zelf weet niet dat je sms aan hebt staan dus zal nog steeds aan je vragen alleen je gebruikersnaam of wachtwoord in te vullen. Wanneer je vervolgens inlogt wordt daarna alsnog om een sms code gevraagd.

De reden dat de belastingdienst jou de mogelijkheid geeft om met alleen wachtwoord en inlognaam in te loggen of sms is een instelling in DigiD die de Belastingdienst gekozen heeft. Wanneer je bijv inlogt op mijn.digid.nl dan heb je de keuze tussen inlognaam wachtwoord, sms of DigiD app. Een overheidsinstelling kan ook kiezen om het af te dwingen door alleen de optie sms aan te bieden

[Reactie gewijzigd door hydex op 24 juli 2024 21:19]

[MikeyMan]

Kul vind ik het niet, maar een irritatiefactor wel. Als ik alleen al naar mijn werk kijk heb ik daar ongeveer tien verschillende wachtwoord / gebruikersnaam combinaties. En dan ook nog eens allemaal met een andere wachtwoordvereiste en verlooptermijn. Snap dat het nodig is, maar ik kan dat allemaal niet onthouden, en moet het dus elders bij gaan houden.

[RobIII]

En daar zijn nou precies wachtwoordmanagers voor uitgevonden (Lastpass, KeePass, etc. etc.)

[toeschouwer]

Nadeel hiervan is dat je zelf niks meer onthoud.
Kan lastig zijn als je de manager niet bij de hand hebt.

[RobIII]

De meeste van die dingen kun je ook prima op je mobiel installeren (en synchroniseren met je desktop/laptop/browser/whatever). Ik gebruik al een jaar of 5 LastPass en weet, inderdaad, eigenlijk nog maar 1 of 2 wachtwoorden uit m'n hoofd; de rest is allemaal een brei van 15+ random tekens (tenzij sites die achterlijk eisen als "max. 8 tekens" hebben ). Bijkomend voordeel is dat élke site een eigen wachtwoord heeft; komt dat wachtwoord (of de hash of whatever) door een hack o.i.d. op straat te liggen voor die site is er niets aan de hand; alle andere sites hebben immers een ander wachtwoord.

[Anoniem: 120539]

En dus hoef ik alleen nog maar het daarvoor gebruikte account te achterhalen...

[RobIII]

Al heb je mijn master-password: je hebt mijn TOTP code nog niet dus je kunt er nog geen kont mee TFA mensen! TFA!

Verder neem je natuurlijk een fatsoenlijk master wachtwoord, schrijf je dat niet op, zet je 't niet in e-mail etc. En mocht je, om welke reden dan ook, dat wachtwoord toch eens ergens hebben laten slingeren kun je 't (afhankelijk van hoe groot de kans is dat iemand het te pakken heeft gekregen) gewoon veranderen naar iets nieuws of gebruik maken van het overzicht van opgeslagen wachtwoorden om alles na te lopen en wachtwoord te wijzigen en zeker te weten dat je niet een site vergeet (en daarbij natuurlijk ook je master wachtwoord te wijzigen).

Ik ben onlangs verhuisd en toen kwam LastPass ook goed van pas omdat ik even door alle sites (webshops e.d.) heen kon klikken en zodoende mijn adres kon wijzigen naar mijn nieuwe adres en daarmee 99% zeker zijn dat ik niet nog ergens een site vergeten ben. Het is dan maar een bijkomend handigheidje van een wachtwoordmanager, maar toch.

En voordat iemand anders weer bezwaren gaat maken: lees je eens in hoe een (degelijke!) wachtwoordmanager (zoals bijvoorbeeld LastPass werkt). Al hack je LastPass.com en download je mijn Vault: je kunt er niks mee omdat 't gewoon een encrypted blob (AES256) is met (in mijn geval) meer dan 150+K iteraties PBKDF2-SHA256 op het master-password.

[Reactie gewijzigd door RobIII op 24 juli 2024 21:19]

[Raphire]

Dit kun je makkelijk oplossen met een zeer moeilijk masterpassword en 2fa.

Heb zelf een masterpassword op mijn passwordmanager van meer dan 25 characters en een 2fa met fysieke key.

Dit heb ik liever dan hetzelfde wachtwoord op meerdere sites en instanties, zo kreeg ik vandaag een mail van edmodo over een breach daar. (een website die ik al erg lang niet meer gebruik maar wel een account heb).

[Reactie gewijzigd door Raphire op 24 juli 2024 21:19]

[Rob_03]

Ben ik ook wel met je eens. Zelfs met deze gebruikers ben ik het ook wel eens. Het is lastig maar dat is dus het hele punt.

Leuk deze berichten en een reactie als "Volgens de minister van Binnenlandse Zaken zijn organisaties zelf verantwoordelijk voor de toepassing van 'het juiste betrouwbaarheidsniveau".

Het wordt gebracht als een DigiD probleem maar in werkelijkheid zit het probleem bij de gebruiker die niet gebruikt wat wel voorhanden is.

[Raphire]

De gemiddelde burger ziet niet in hoe gevaarlijk het is dat je een makkelijk te raden en kort wachtwoord hebt. Want: "wie wil mij nou hacken"

[kmf]

En dan natuurlijk 1x in de maand een nieuw wachtwoord forceren natuurlijk he? En het mag niet een combinatie zijn dat lijkt op de wachtwoorden die je de afgelopen 5 jaar gebruikt hebt.

Wat je dan ziet is dat mensen dan gewoon Wchtwrd!1 doen en voor volgende maand Wchtwrd@2. En als je het helemaal moeilijk maakt, dan gaan ze allemaal lekker afspreken om gewoon wachtwoord te laten verlopen en jou te vragen om het te resetten net zolang tot de baas er ook genoeg van heeft en minder strikte regels te doen gebruiken.

https://xkcd.com/936/

[dormamu]

Helaas klopt die strip niet. Met een dictionary attack is dat wachtwoord juist veel makkelijker en sneller te kraken.

[blissard]

Volgens mij niet. Een woordenboek aanval op een wachtwoord van 30 letters kost nog steeds veel te veel tijd.
https://nakedsecurity.sop...es-what-you-need-to-know/

[Reactie gewijzigd door blissard op 24 juli 2024 21:19]

[dormamu]

Volgens mij niet. Een woordenboek aanval op een wachtwoord van 30 letters kost nog steeds veel te veel tijd.
https://nakedsecurity.sop...es-what-you-need-to-know/

Het hele idee van een dictionary attack is juist dat de lengte van het woord geen impact heeft op de tijd nodig voor het kraken van het wachtwoord.

[blissard]

Wel als het meerdere woorden zijn. Als in een zin bijvoorbeeld

[dormamu]

Vooruit, ik zal het je wiskundig aantonen.
Correct horse battery staple. Zijn vier woorden. Er zijn 47000 woorden in de Engels taal.
Dictionary attack is 47000^4=E18
Tr0ub4dor&3 zijn elf tekens inclusief hoofdletters en kleine letters. Een brute Force op tekens is
96^11=E21

Tr0ub4dor&3 is dus moeilijker te kraken.

[blissard]

Oké, ik wist niet dat het in het Engels moest zijn maar wat je zegt klopt hoor. Alleen is een zin als: mein pasword est correct horse battery staple. Waarschijnlijk makkelijker te onthouden en net zo veilig

[TDeK]

Het is ook gewoon onzin, die eisen. Gelukkig vindt NIST dat ook: https://nakedsecurity.sop...es-what-you-need-to-know/
No composition rules

[Reactie gewijzigd door TDeK op 24 juli 2024 21:19]

[Rob_03]

Ben ik ook wel mee eens maar zoals aangegeven ging het om het forceren van een dergelijk WW en de gevolgen.

Het was overigens 6 met vrije keuze maar een beetje met de hype mee als het mis gaat, de bekende "6 tekens accepteren " toch maar hiervoor gekozen.

[tom.cx]

Het grappige is eigenlijk dat het beveilings laatst een heel ander advies heeft gegeven na eigen onderzoek.

http://www.disprimo.be/new-password-guidelines

[dormamu]

Excuses. Verkeerde persoon

[Reactie gewijzigd door dormamu op 24 juli 2024 21:19]

[Byron010]

Waarom altijd de of/beter dan vergelijking en niet beide?

[Ryan1981]

Idd ik heb een lang wachtwoord met vreemde karakters.

[TDeK]

Vreemde karakters, of écht vreemde karakter? Δσηξτ of Дшвчы? Dát maakt het kraken pas moeilijk!
Dit is daarom ook één van de NIST aanbevelingen: https://nakedsecurity.sop...es-what-you-need-to-know/
Applications must allow all printable ASCII characters, including spaces, and should accept all UNICODE characters, too, including emoji!

[Ge Someone]

Het invoeren daarvan is niet altijd mogelijk en/of makkelijk.

Ik vond nog iets anders opvallends in het gelinkte artikel van NIST

Additionally, and this is a big change: SMS should no longer be used in two-factor authentication

Ze vinden SMS verkeer niet veilig (SIM swaps, mobile phone number portability, malware that can redirect text messages; attacks against the mobile phone network)

[Ge Someone]

En "lang" is ook arbitrair net als het in het artikel genoemde "zwak".

[jdh009]

Nadeel bij sommige sites is ook dat een wachtwoord soms maar 8 tot 16 tekens max lang mag zijn. Komt de veiligheid nooit ten goede. Dus lang is niet overal een optie helaas.

[Reactie gewijzigd door jdh009 op 24 juli 2024 21:19]

[freaky]

Beetje te kort door de bocht gesteld.

J8.v)M!& is veiliger dan
gehaktballen

Heeft niet alleen met entropy te maken, maar ook met dictionary attacks.

En geen idee hoe ze het hebben vastgesteld, maar als ze de (geanomiseerde) hashes hebben gekregen en die door john the ripper oid hebben gehaald kun je dat vrij snel zien.

Weleens gedaan met de wachtwoord hashes van FTP accounts op een shared webserver met ~120 accounts en dat was redelijk schokkend. Iets meer dan 30% was binnen 20 minuten achterhaalt. Had bijna 90% na 3 uur. De rest duurde te lang (na 3 dagen afgebroken). Waren salted SHA-256 hashes overigens, liep wel op wat dikke videokaarten.

[YangWenli]

Of gewoon tweetraps authenticatie verplichten. Maar dat kan misschien wettelijk niet omdat niet iedereen een telefoon heeft?

[tweaknico]

Soms is een telefoon geen tweede trap. (Als je vanaf te telefoon contact zoekt op 't internet is er geen 2FA als een SMS binnen moet komen.
De SMS kan eerder door software uitgelezen worden dan dat jij die kan gebruiken op een telefoon.

Een een SMS faken is ook geen groot probleem, voor <1500$ kun je de apparatuur in China bestellen. (je krijgt dan een Laptop met extra's een Stingray achtig apparaat).

[Franckey]

Soms is een telefoon geen tweede trap. (Als je vanaf te telefoon contact zoekt op 't internet is er geen 2FA als een SMS binnen moet komen.
...

Dat is misschien minder veilig, maar volgens de definitie is het wel 2FA. Daarvoor moet je namelijk iets weten (een password) en iets hebben (een device waarop je de verificatie code ontvangt).

[tweaknico]

Beide onafhankelijk van het object dat je gebruikt om informatie te benaderen.
Bij toegang vanaf de telefoon zijn de telefoon en de telefoon niet onafhankelijk van elkaar, met een kans op misbruik door andere apps op de telefoon.

[Stry]

Ik had een erg veilig en mooi lang wachtwoord, totdat ze een jaar of twee geleden met dat gezeur aankwamen dat er een cijfer en ander karakter verplicht waren. Nu heb ik nog steeds een redelijk veilig wachtwoord, maar minder veilig dan hiervoor, simpelweg omdat het minder makkelijk is om een lang wachtwoord met $@5##x ofzo te onthouden.

[satya]

Dat geeft meerdere problemen.

- verplichte aanschaf van een mobiele telefoon
- een eventuele prepaid is niet anoniem meer, vanwege koppeling mobiele nummer aan persoonsgegevens.
- verwerking van de gegevens door derden, bv belastingconsulent

[emnich]

In het rapport wordt afzonderlijk gesproken over 90% zonder SMS en 10% met SMS:

Bijvoorbeeld slechts 10% van de raadplegingen met DigiD vindt plaats met wachtwoord én SMS.

Van de circa 250 miljoen maal dat gebruik wordt gemaakt van DigiD, is dat in 90% van de gevallen met een eenvoudig wachtwoord én zonder SMS (tweewegauthenticatie).

Het `eenvoudig` slaat m.i. meer op het feit dat alléén een wachtwoord wordt gebruikt dan op de kwaliteit van het wachtwoord.

[Kiwivogel]

Het debiele is ook dat ik terwijl ik SMS verificatie heb er ook gewoon voor kan kiezen om met alleen wachtwoord in te loggen (niet op alle sites maar wel op een deel). Volslagen krankjorem

[JDVB]

Maar je kunt ook instellen dat sms authenticatie altijd verplicht is, dat is wat ik gedaan heb. Wanneer ik dan in probeer te loggen zonder sms authenticatie krijg ik netjes een melding dat de sms authenticatie toch wel verplicht is.
De standaard selectie om zonder sms authenticatie in te loggen laat ik dan ook altijd staan zoals die staat, dat heeft effectief voor mij toch geen verschil maar is wel weer een klikje minder.

Verder lijkt het me niet krankjorem om een slechts in bepaalde gevallen de sms authentificatie af te dwingen wanneer dit ingesteld is. Het is in het geheel optioneel, dit biedt slechts een extra optie tussen nooit en altijd in.

[Reactie gewijzigd door JDVB op 24 juli 2024 21:19]

[blissard]

Krijgen ze direct als commentaar dat niet iedereen een mobiele telefoon heeft.

[dutch79]

Precies dat. Het is optioneel. Verbaast mij ook nog steeds. Logisch dat bijna iedereen voor de makkelijkste weg kiest dan. Op deze manier is de implementatie van 2-traps authenticatie vrij zinloos.

[bogy]

ik hoop dat, uit naam van de veiligheid, jullie in nederland het systeem erven dat wij in belgie al verschillende jaren in gebruik hebben; de digitale id-kaart.
Voor zij die niet weten wat het is; dit is gewoon je identiteitskaart waarop een chip zit, en in die chip zitten naast jouw persoonlijke data nog een tweetal persoonlijke digitale certificaten die ontrengeld kunnen worden met een pin-code. Met die certificaten kan je je identiteit bevestigen (Authentication certificaat) en dus bv inloggen op overheids-sites of bij het ziekenfonds of bewijzen dat jij het bent wanneer je online bij de bank een rekening opent ofzo. Met het tweede certificaat (Signature-certificaat) kan je documenten digitaal ondertekenen, deze digitale handtekening heeft dezelfde rechtsgeldigheid als een gewone handtekening.
Als je dus bv een pdf maakt van je word-document kan je deze digitaal ondertekenen (acrobat ondersteunt dit) met je signature certificaat en je kan ook gewoon instellen dat het document niet meer mag gewijzigd worden. Wordt er toch nog iets gewijzigd aan het document, dan vervalt de handtekening automatisch. Je kan ook je uitgaande mails handtekenen enzo; het is wel zo dat je bij elke toepassing van het certificaat je pin-code moet ingeven om het certificaat te unlocken én je id-kaart moet intussen ook in de cardreader zitten; maar dat spreekt voor zich.

Dit systeem werkt enorm goed, is zeer veilig en de 'extra' kosten zijn tegenwoordig quasi nihil; want we kunnen dezelfde cardreader gebruiken die de bank ons geeft (tenminste een aantal banken toch) om met internetbankieren te werken; De Vasco Digipass 870, oa Belfius bank deelt deze uit. Het systeem werkt zowel op windows als op linux als op apple computers. Je hoort je ID-kaart in principe altijd bij je te hebben dus je hebt altijd en overal toegang tot je beveiligde gegevens.

[Leooow]

Dat kan inderdaad, maar dan kom je op een ander stuk van de gegevens dan als je inlogt via sms verificatie. Zodat je boekhouder bijvoorbeeld bij bepaalde info kan. Die hoeft niet alles in te zien.

[YopY]

Wat zou mijn boekhouder met mijn digID accountgegevens moeten dan? Lijkt me ook niet de bedoeling dat je logingegevens kunt delen. Eerder dat je een partij beperkte toegang geeft tot je gegevens.

[hydex]

Daar gebruik je DigiD machtigen voor. https://machtigen.digid.nl

[Leooow]

Klopt, volgens mij hebben ze dat pas recent toegevoegd

[NLKornolio]

Inderdaad dat was er paar jaar geleden nog niet. Bij aankoop nieuw huis zij hypotheek advieseur ik zal ook wel je belasting doen. Mag ik jouw digid code, laat maar doe hu zelf wel.

[Leooow]

Dan kan hij bijvoorbeeld je belastinggegevens downloaden

[bkor]

Je kan dat ergens in de DigiD instellingen verplichten. Dat dit niet automatisch gaat is nogal vreemd.

[emnich]

Je kan dat instellen zoals in deze reactie verteld wordt.

[Game_overrr]

Dit. Dat verbaaste mij ook erg. Je zou toch verwachten dat ze dit enigzins verplicht gaan stellen

[WitchHunter]

Als `eenvoudig` zou slaan op authenticate zonder SMS zou er toch geen nadruk op de `én` gelegd worden?

is dat in 90% van de gevallen met een eenvoudig wachtwoord én zonder SMS

[emnich]

Maar anders betekent het dat vrijwel iedereen die zonder SMS doet het met een zwak wachtwoord doet. Dat lijkt me ook weet niet waar. En áls dat waar zou zijn dan zou er wel staan dat vrijwel iedereen een zwak wachtwoord gebruikt.

Ik ben het met je eens dat het er raar staat maar bij wachtwoorden gebruik je toch vaker zwak dan eenvoudig. Maar we wachten de reactie van de rekenkamer af.

[-weenie-]

Bij het inloggen controleren of deze aan bepaalde voorwaarden voldoet. Dit vastleggen als boolean in de database.

[Jace / TBL]

Ik zie dat in de javascript anders nergens staan. Kortom, mijn password gaat wel degelijk leesbaar hun kant op.

[Thomqa]

Wachtwoorden worden altijd "plain text" in het http request pakketje gestopt. Als je hem zou encrypten/hashen (met javascript) voordat je hem in je request stopt dan is je gehashde wachtwoord essentieel je nieuwe wachtwoord en biedt dus geen enkele extra vorm van veiligheid. Zie ook http://stackoverflow.com/...encryption-at-client-side.

Server side kunnen ze dan inderdaad geautomatiseerd de wachtwoorden analyseren en geanonimiseerde statistieken opslaan.

edit: Het http pakketje wordt natuurlijk wel versleuteld zodat je wachtwoord niet te sniffen valt.

[Reactie gewijzigd door Thomqa op 24 juli 2024 21:19]

[Anoniem: 42901]

Soms is SSL/TLS niet voldoende. Dan kan je bijvoorbeeld SRP gebruiken als protocol daar bovenop.

Dus paswoorden hoeven niet leesbaar uitgewisseld te worden.

[Reactie gewijzigd door Anoniem: 42901 op 24 juli 2024 21:19]

[Thomqa]

Inderdaad, de challenge response methode zou gebruikt kunnen worden. Hoewel je dat niet vaak in het wild tegen komt. Heb jij toevallig voorbeelden van websites die het gebruiken?

[Anoniem: 42901]

Ik heb helaas geen voorbeelden, maar het lijkt me logisch dat cruciale zaken (zoals DigiD) zo beveiligd worden. Zeker gezien er een optie is om zonder 2FA te authen.

[Thomqa]

Ik denk dat het hier juist totaal geen toegevoegde waarde heeft. SSL/TLS beschermd de communicatie tussen de client en server al tegen afluisteren. Deze vorm van encryptie wordt constant bijgewerkt en aangepast aan de huidige rekenkracht. Het risico dat je wachtwoord "van de lijn" wordt verkregen is minimaal.

Daarnaast is het wel of niet gebruiken van 2FA totaal niet relevant hieraan. 2FA is vooral bedoelt om te beschermen tegen het geval dat een aanvaller op een andere manier het wachtwoord verkrijgt (bijvoorbeeld social engineering of een client side keylogger). Deze problemen heb je nog steeds bij een Challenge Response methode.

[Anoniem: 42901]

SSL/TLS is vaak voldoende, maar je kan niet 100% voorkomen dat een certificaatboer een certificaat uitgeeft van een domein dat hij niet in beheer heeft.
Een voorbeeld waarbij het fout ging is DigiNotar.

Natuurlijk worden de slechte certificaatboeren geblacklist, maar dan is het al te laat.

Met SRP (of een ander goed crypto-protocol over SSL) kan je dus de schade mitigeren.

[Anoniem: 42901]

En laten we Digest authentication niet vergeten!
[edit] Amazon hun API authenticatie heeft hier een variant op:
http://docs.aws.amazon.co...v/RESTAuthentication.html

[Reactie gewijzigd door Anoniem: 42901 op 24 juli 2024 21:19]

[Anoniem: 84766]

Hoe moeten ze anders je ww controleren? Van je ww maken ze weer een hash en ze vergelijken de hash. Ww kunnen ze bij login analyseren op sterkte.

[Jace / TBL]

Precies zoals je zegt, ze moeten van je password direct een hash maken (zowel bij het registreren als inloggen) en alleen die hashes vergelijken. Het password zelf hoeft nooit ergens te worden bewaard.

[eekhoorn12]

Ze bewaren het password ook niet.

Wat er gebeurd is dit:
Jij voert ww in op de website -> Browser stuurt die bij inloggen naar hun server toe -> Server ontvangt wachtwoord -> Server hashed jou wachtwoord en vergelijkt die met de hash die ze hebben opgeslagen.

Dus ze slaan nergens je plain text wachtwoord op, maar ze hebben wel een mogelijkheid om bij inloggen je wachtwoord te gebruiken. Dit doen alle sites anders werkt het niet. Wat ze dus ook op die plek kunnen doen is kijken of je wachtwoord zwak of sterk is, en dan ergens opslaan of je een sterk of zwak wachtwoord hebt.

Ze slaan dus nergens in plain text je wachtwoord op.

[poehee]

"Dus ze slaan nergens je plain text wachtwoord op"

Dat kun je toch niet weten tenzij je inzage hebt in de server processen?

[eekhoorn12]

Dat kunnen we niet zeker weten inderdaad.

Maar als ze een beetje moderne development practices volgen, waar ik wel een beetje van uit ga. Slaan ze deze nergens op

[Stoelpoot]

Hoe zou je op deze manier een salt bijhouden, zonder deze ook over de lijn te versturen? En op die manier ook direct de salt aan een gebruiker te linken. omdat je die pas kan sturen als je de gebruiker kent? Wat dus ook direct een mogelijkheid geeft tot gebruikersnamen gokken zonder request limits op te roepen?

[freaky]

Salt wordt opgeslagen.

Bijv. op linux uit een /etc/shadow

vicky:$6$pdtyTfc9q2IFIOPs$x8nEfeR36RwY1EnGZQ1zxbFXlOtlRmo5HApbMdfFphu5g3v6Kx5QjQTAmIVti/seGAXsLgfp5JL7DwtCSWgC21:17304:0:99999:7:::

Mocht je het willen proberen, deze aangemaakte test account heeft als wachtwoord Vicky (ja dat is niet veilig - het is demo hier ).

$6$ geeft de encryptie methodiek aan, $6$ staat voor SHA-512.
pdtyTfc9q2IFIOPs is de salt
x8nEfeR36RwY1EnGZQ1zxbFXlOtlRmo5HApbMdfFphu5g3v6Kx5QjQTAmIVti/seGAXsLgfp5JL7DwtCSWgC21 is de hash over salt+wachtwoord.

~ # python
Python 2.7.13 (default, May 10 2017, 20:04:28)
[GCC 6.3.1 20161221 (Red Hat 6.3.1-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import crypt
>>> crypt.crypt('Vicky', '$6$pdtyTfc9q2IFIOPs')
'$6$pdtyTfc9q2IFIOPs$x8nEfeR36RwY1EnGZQ1zxbFXlOtlRmo5HApbMdfFphu5g3v6Kx5QjQTAmIVti/seGAXsLgfp5JL7DwtCSWgC21'


man shadow
man crypt
op linux als je meer wil weten

[Stoelpoot]

Hoe log ik nu op een andere computer in als de salt lokaal wordt opgeslagen?

[freaky]

De user database staat hier lokaal, dus niet anders dan anders. Normaal staat de hash ($6$pdtyTfc9q2IFIOPs$x8nEfeR36RwY1EnGZQ1zxbFXlOtlRmo5HApbMdfFphu5g3v6Kx5QjQTAmIVti/seGAXsLgfp5JL7DwtCSWgC21 in het voorbeeld) in de user database. Voor een website in z'n database over het algemeen, voor AD/LDAP in de AD/LDAP (of een radius server/database er achter). Je stuurt je username en wachtwoord op, ze pakken de hash, voegen ze samen, hashen het, vergelijken de hashes, kloppen ze mag je aanmelden (er van uitgaande dat je account niet locked out, expired, etc. is).

[Stoelpoot]

Dus hoe hash je het wachtwoord nu op een andere computer, als de salt lokaal ergens wordt opgeslagen? Tenzij je de hash op de server opslaat. Wat natuurlijk wel kan.

[freaky]

De salt staat in de user database zoals ik al zei.

Als je lokale users hebt, dus lokaal, als ze op een webserver staan waar die z'n accounts ook bewaard en als het domein gebruikers zijn in een Windows omgeving bijv. in de AD (en dus op alle DC's die die AD repliceren).

[Anoniem: 84766]

De hele verwarring komt omdat je in je eerste post over javascript hebt. Waarom? Hashes, salts en KDF zijn totaal irrelevant als de client het doet en het resultaat naar de server stuurt.

[-weenie-]

Dat zou kunnen, verder niet naar gekeken. Maar doet hoeft niet te betekenen dat het ook leesbaar is in de database. Bij een login poging kunnen ze het serverside controleren.

[Martijntj]

Huh? Waarom zou dat niet het geval zijn? Hoe denk je dat dat op andere websites gaat?

[Jace / TBL]

Met hashes.
Liefst met unieke salt per user, en trage hash functie (eigenlijk meer een KDF).

[Martijntj]

Maar meestal serverside, niet clientside?

[Heidistein]

Altijd serverside, nooit clientside. Immers, anders kan de 'man in the middle' slechts de hash uitluisteren, en de volgende keer opsturen.

[Hugo_ijslijk]

Maar je zou toch ook beide kunnen doen? Simpele hash clientside, en serverside nogmaals hashen voor je database lookup. Dan zorg je ervoor dat je wachtwoord nooit plaintext over de lijn wordt gestuurd, en je ww veilig wordt opgeslagen.

[Heidistein]

Ja, klopt. Dat noemen ze ook wel eens SSL

[Sleurhutje]

Als niet aan de minimale voorwaarden wordt voldaan, is het wachtwoord niet te gebruiken. Dus een ieder die een geldige login heeft, heeft voldaan aan de minimale eisen qua lengte en karakters.

[stresstak]

een ieder die een geldige login heeft, heeft voldaan aan de minimale eisen qua lengte en karakters.

Dus mensen gebruiken het minimaal juiste en dat wordt hen verweten ?!
Overheden...

[bauke1994]

Ik hoop dat ze de boolean dan niet gelinkt aan het wachtwoord opslaan. Lekt de database en kan je zo filteren op gebruikers met zwakke wachtwoorden.

Ik verwacht dat ze bij het inloggen inderdaad het wachtwoord hebben geanalyseerd en dit ergens opslaan.

[629110]

Allemaal de zelfde hashes ?

[MadEgg]

Ik mag toch hopen dat de passwords wel salted opgeslagen worden...

[629110]

Dan kunnen ze dus niet meer zien of het zwakke wachtwoorden zijn. Dus die optie vervalt lijkt me.

Het kan natuurlijk dat ik er ook naast zit.

[MadEgg]

Ze zouden een dictionary attack gedaan kunnen hebben op de accounts in het systeem en alle wachtwoorden die daarmee te kraken zijn, vormen 90% van het totaal?

[EraYaN]

Dat is het meest logisch. Er light een prachtige lijst van wachtwoorden op straat gesorteerd op frequentie, daar kun je zelfs met de tragere hashes vrij snel er een heleboel checken. Vooral als je de hardware of het budget hebt.

[piderman]

Ja en je weet de salt per user. Dus het is even number crunchen om de 'bekende zwakke wachtwoorden' te hashen per user en dan te kijken of de user zo'n hash heeft.

[MadEgg]

Dat zeg ik hier toch ook al?

Ik reageerde er even op dat allen dezelfde hashes zouden hebben, maar bij een goed opgezet systeem kun je geen wachtwoorden vergelijken op basis van de hash.

[kleautviool]

Precies dit!

Tenzij ze per login een testresultaat van het wachtwoord opslaan natuurlijk

[Reactie gewijzigd door kleautviool op 24 juli 2024 21:19]

[Ge Someone]

Dat hoeft niet "per login" er zijn veel sites die bij het instellen van een wachtwoord (tijdens het typen) de sterkte aangeven. Dat zou je kunnen opslaan of in statistieken verwerken,
Het lijkt er echter meer op dat ze bedoelen "slechts een wachtwoord" (zonder SMS).

[SpiceWorm]

Je kan de hashes brute forcen en dan kijken hoe snel je hoeveel wachtwoorden hebt. Ik mag hopen dat dat de manier is waarop ze het gedaan hebben.

Een alternatief is dat ze de complexiteit berekenen wanneer het wachtwoord wordt aangemaakt en dat deze complexiteit in een geanonimiseerde database wordt gebruikt om statistieken van de complexiteit uit te rekenen.

[Zeehond]

Ik mag toch ook hopen dat er salt is gebruik bij het hashen van de wachtwoorden, in dat geval zou het toch veel werk moeten zijn om alle hashes te brute forcen wanneer ook een actueel algoritmen gebruikt is.

[Webgnome]

Dat is inderdaad een erg goede vraag. Hier ligt een taak aan Tweakers om het artikel / persbericht niet simpelweg te plakken op de site maar om echt onderzoek te doen.. lijkt mij?

[Stoelpoot]

Dan kunnen we pas over tientallen werkdagen antwoord verwachten, ben ik bang.

[Webgnome]

Is dat een probleem? Zet er dan bij in het artikel dat er nog een vervolg artikel komt

[Anoniem: 57411]

Dat is toch redelijk eenvoudig te achterhalen? Zelfs als de wachtwoorden naar de meest recente standaarden hashed&salted worden opgeslagen:
Neem een lijst van zwakke wachtwoorden, gooi je encryptiemethode eroverheen en vergelijk het resultaat met de opgeslagen lijst van gehashete wachtwoorden.

[Qarion]

wachtwoord sterkte opslaan als het password geupdate wordt?
mag toch hopen dat ze de passwords niet kunnen inzien..

[job89]

Ik weet niet of ze het doen, maar ze kunnen tijden het aanmaken van een nieuw wachtwoord dan wel tijdens het invullen van je wachtwoord wel de sterkte berekenen en dat opslaan in hun database. Zo kunnen ze zonder dat het wachtwoord in plain tekst in hun datatbase staat nog altijd de sterkte weten.

[Bazi]

In het artikel staat letterlijk dat het gaat om 90% van de keren dat er is ingelogd. Dus niet 90% van het aantal gebruikers.

Dat betekent dus dat ze gewoon bij het inloggen statistieken bijhouden (bijv. simpelweg aantal keer tellen van zwak/sterk wachtwoord) en niet uit hun database halen. Anders kun je het nooit uitdrukken als percentage van het aantal logins.

[Reactie gewijzigd door Bazi op 24 juli 2024 21:19]

[PilatuS]

Het aantal karakers zegt genoeg. Ieder wachtwoord met bijvoorbeeld 4 karakters is zwak. Zodra je naar 12 karakters gaat is het op enkele uitzonderingen na meestal een sterk wachtwoord.

[Jace / TBL]

Wat mij hieraan nog het meest verontrust: hoe weten ze dat?

Want als ze zich zelf aan enig "betrouwbaarheidsniveau conform de regels" zouden houden, zouden die passwords helemaal nergens zijn opgeslagen. Alleen een hash waar je niets aan kunt zien over het password zelf.

[Anoniem: 378762]

Pecies! Hoe weten ze dat dan? Lekker veilig systeem als ze er zelf ook in kunnen kijken.

[hackerhater]

Lijkt me checken wanneer je in logt.
Tijdens inloggen/wachtwoord veranderen is namelijk het enigste moment dat digid je wachtwoord kent.

Je browser =HTTPS=> server => hashen wachtwoord => controleren tegen database

[Reactie gewijzigd door hackerhater op 24 juli 2024 21:19]

[freaky]

Daar kun je werkelijk niks over zeggen gezien ze zelf gewoon een dictionary/brute force aanval op hun database kunnen doen.

En natuurlijk kunnen ze in hun eigen systeem kijken. Je roept toch ook niet lekker veilige auto als de eigenaar er gewoon in rond kan rijden? Dat zou rond uit belachelijk zijn...

[sebvieira]

Steekproefgewijs onderzocht middels enquete, vermoed ik. Met vragen als "Gebruikt u verschillende karakters / hoofdletters / andere tekens / lang wachtwoord" etc. etc. En dan nog is het de vraag wat dat onderzoek dan verwacht onder 'zwak wachtwoord'. Ik zou bijvoorbeeld een wachtwoord kunnen pakken als "1234hoedjevanpapier!" wat best wel een zwak wachtwoord is (want: dictionary) maar i.c.m. mijn username (die je ook zelf mag bepalen!) 'dx98374yrjs98r43' is er alsnog moeilijk achter te komen.

En de praktijk (ik was systeembeheerder) leert dat hoe meer eisen je stelt aan het wachtwoord, des te groter is de kans dat mensen zoiets hebben van "dat ga ik nooit onthouden, dus ik schrijf het wel ergens (digitaal) op" , waarmee alle beveiliging teniet gedaan wordt.

[Anoniem: 57411]

Je kan natuurlijk een lijst van bekende (en/of zwakke) wachtwoorden nemen, de boel hashen en vergelijken met de hashes van de wachtwoorden van de gebruikers. Zelfs als de boel hashed&salted naar de nieuwste standaarden is opgeslagen werkt dit prima.

Dat is ook de reden waarom het belangerijk blijft om je wachtwoord te veranderen nadat een lijst van gehashete wachtwoorden is gestolen: wachtwoord gokken is bij zo een lijst een stuk makkelijker dan op een website die waarschijnlijk een limiet in het aantal pogingen heeft ingebouwd.

[Webgnome]

Dit komt toch niet als een totale verrassing? Vraag de gemiddelde burger om een wachtwoord te verzinnen en ze komen aan met variaties op geboortedatum, trouwdatum, huisdier informatie you name it. Maar echt een goed wachtwoord is er nooit bij. Dat is natuurlijk ook niet heel erg raar als je bedenkt dat voor veel gebruikers een computer nog steeds een gebruikersvoorwerp is vergelijkbaar met een auto.

Bij een auto wordt de gebruiker er ook niet op aangesproken als zijn / haar banden spanning te laag is etc. Dat is namelijk een taak die de gebruiker heeft uitbesteed aan de garage (en ja daar is ook iets van te zeggen). Geeft dat de gebruiker dan maar een vrijbrief om zo door te modderen? Nee lijkt mij niet. Hier is een taak van de overheid / bedrijfsleven weg gelegd door gebruikers actief op te voeden over de problemen die je kunt krijgen bij het gebruik van een PC. Dit wordt nu niet gedaan en er wordt gewoon vanuit gegaan dat de gebruiker zelf wel gaat snappen hoe het e.e.a. werkt. Dat is gewoon pertinente onzin. Om maar weer een vergelijking te maken met een auto. Ik ga echt niet leren hoe de motor van mijn auto werkt zolang dat er garages zijn die mijn auto willen onderhouden.

Maar buiten het feit dat 90% van de gebruikers een verkeerd wachtwoord heeft even een quote uit het artikel

De encryptie is nog steeds alleen gedeeltelijk en voldoet niet aan de geldende regels, maar het misbruik van de gegevens zou door andere veiligheidsmaatregelen 'tot een gering risico' beperkt zijn. De minister nam daarom in oktober 2016 de beslissing om het restrisico te aanvaarden.

Dit snap ik niet. Twee jaar geleden is de minister er op gewezen dat de encryptie van het geheel niet goed werkt en toch gaan we dat niet aanpassen omdat het geringe risico? We hebben het hier over een overheidssysteem? Een systeem waar heel veel data van burgers toegankelijk is?

p.s. voor de overheid bashers. Lees het artikel nog eens goed en zie dat het hier gaat om een pebkac probleem gaat in eerste instantie.

[sebvieira]

Het is zo dat alle gebruikersgegevens versleuteld worden opgeslagen, maar overige data van het systeem niet. Is ook niet te doen, wil je het geheel een beetje kunnen beheren, en ook totale overkill. Je gaat bijvoorbeeld ook niet alles van je harde schijf encrypted opslaan, maar alleen datgene waarvan je niet wilt dat derden het zonder jouw toestemming kunnen lezen.

De meeste van dit soort eisen worden opgesteld door mensen die weinig tot geen verstand van techniek hebben, helaas.

[PolarBear]

Bij een auto wordt de gebruiker er ook niet op aangesproken als zijn / haar banden spanning te laag is etc. Dat is namelijk een taak die de gebruiker heeft uitbesteed aan de garage (en ja daar is ook iets van te zeggen).

Bandenspanning is dan weer een slecht voorbeeld. Nieuwe auto's hebben niet voor niets verplicht (apk afkeurpunt!) een bandenspanning sensor. Net als oliepeil en ruitenwisservloeistof zijn dat echt zaken die de bestuurder zelf kan en moet regelen dat ligt niet bij garageonderhoud.

[incaz]

Een design dat verwacht dat gebruikers meer weten en kunnen dan ze kunnen, is geen goed design.

[SinergyX]

Maar wat is hun definitie van zwak? Naam+123? Of ook ditiseenwachtwoorddielangismaargeenhoofdlettersheeft? Volgens mij was het toch meerdere malen onderzocht dat lange wachtwoorden al beter zijn dan korte complexe versies.

Maar andere kant, hoe zien zij eigenlijk dat iets zwak is? Betekend dat zij dus wachtwoorden kunnen inzien? Of is dat eenmalig vooraf bepaald bij ingeven van wachtwoord en dat slaan ze bij je wachtwoord op? Lekker veilig.

Maar in de basis, als je kijkt naar de 2 'veiligheidsissues' die spelen, zwak wachtwoord zou dus brute-force kunnen helpen maar mag aannemen dat daar ook wel een systeem voor is, maar wat heb je aan een wachtwoord als hun hele systeem gewoon gekraakt wordt? Mag best tot een 'gering risico' zijn gemaakt, maar dat is nog steeds een risico. Kan je je gebruikers wel streeds extremere wachtwoordeisen gaan opleggen en SMS verificatie verplichten.. wat heb je er aan als je eigen systeem zo lek als een mandje is?

[Milt]

Los van de zwakke wachtwoorden, is het versturen van een extra authenticatecode via SMS eigenlijk ook al niet meer "recommended" (en nog een andere bron). Het advies is om in ieder geval een Time-based One-Time Password algorithm (TOTP) optie aan te bieden voor de gebruikers die weten hoe dat werkt.

[computerjunky]

Of nog beter helemaal geen digid.

Hoeveel gezeur ik daar al wel mee gehad heb. ik geen bedrijven en instanties dan ook geen toestemming om mij zooi vie digid te sturen. die bagger werkt vaker niet dan wel. ik heb al 3x een nieuw paswoord moeten aanvragen afgelopen 18 maanden en het heefd me bijna mijn huis gekost omdat ik niet kon inloggen voor weken.

[0xygen500]

Als er ook even vermeld wordt wat een zwak wachtwoord is, is dat een wachtwoord met alleen letters of alleen letters en cijfers?

Edit: lees dat de rekenkamer dit niet gedefinieerd heeft, dan kan je ook weinig met een percentage van 90%.

[Reactie gewijzigd door 0xygen500 op 24 juli 2024 21:19]

[Waah]

Een kort wachtwoord is altijd zwakker dan een lang wachtwoord. Los van speciale tekens. Snap ook niet dat bijna elke site nog hamert op speciale tekens, cijfers, hoofdletters etc.

[434365]

Hoewel je helemaal gelijk hebt dat een langer wachtwoord vaak veiliger is dan een korter wachtwoord, is er wel degelijk een goeie reden voor speciale tekens, cijfers, hoofdletters etc.

Hoe wachtwoorden vaak gekraakt worden is via 'brute-forcing', oftwel een computer probeert alle wachtwoorden van aaaaa tot xxxxx, de reden dat veel sites vragen of je speciale tekens etc in je wachtwoord wilt stoppen is omdat dit de actie van 'brute-forcing' moeilijker maakt, als je wachtwoord alleen uit kleine letters bestaat, hoeft een computer maar 36 tekens per character te proberen, heeft je wachtwoord kleine letters hoofdletters tekens en cijfers, dan kan een enkel character al 95 verschillende tekens zijn, oftewel een stuk meer werk om te 'brute-forcen'

Als we voorbeeldje aaaaa even pakken, dat is dus
36x36x36x36x36 = 60,466,176 mogelijke wachtwoorden
Maar doe je Ab$!5 als wachtwoord dan is het
95x95x95x95x95 = 7,737,809,375 mogelijke wachtwoorden

Hopelijk zie je nu wel de toegevoegde waarde van hoofdletters speciale tekens cijfers etc, er is dus een zeer goeie reden voor.

[Bacchus]

Het probleem van gekke tekens wordt overzichtelijker als je entropie-bits (2log(set^lengte)) ipv aantal mogelijkheden gebruikt:
5 kleine letters = 24 bits
5 typebare tekens = 33 bits
7 kleine letters = 33 bits

Dus door mijn wachtwoord twee tekens langer te maken win ik net zo veel entropie als door een ruim drie keer zo grote tekenset te gebruiken. En dat eerste is veel makkelijker te onthouden.

[434365]

Dat eerste is echter ook weer veel makkelijker te kraken, omdat je zeer waarschijnlijk bestaande woorden gebruikt, die dus ook vrij makkelijk te testen zijn.

Nou is het voor ons natuurlijk ietsje sterker, en zijn er (naar mijn weten iig) niet zoveel niet-engelse woordlijsten, maar toch, uiteindelijk zijn er genoeg manieren om een wachtwoord wat langer is maar gewoon engels/nederlands sneller te kraken dan eentje die korter is maar totaal onsamenhangend.

[Bacchus]

Op basis van een woordenboek van 2.000*, haal je 11 bits entropie per woord. Dus als je willekeurig kiest, heb je er drie nodig voor 33 bits.

* Equivalent aan de XKCD-methode, Diceware gebruikt een lijst van 7.776 (13 bits) woorden, een gemiddelde Nederlander kent rond de 40.000 (15 bits) woorden.

[434365]

Er zijn lijsten van meest gebruikte woorden die een stuk korter zijn, ja een gemiddelde Nederlander weet (blijkbaar) 40.000 woorden, maar hoeveel daarvan worden vaak gebruikt/zullen een makkelijk te onthouden wachtwoord vormen?

Waarschijnlijk dat je met een woordenlijst van zeg 5000 stuks je al het merendeel van de 'moeilijke' Nederlandse wachtwoorden hebt gekraakt

Hier alvast een beginnetje voor geïnteresseerden

[GrooV]

Zie mijn reactie hieronder: GrooV in 'nieuws: 90 procent DigiD-gebruikers heeft zwak wachtwoord zonder sm...

Wat je zegt is namelijk niet waar en een erg grote fout in de IT. Lengte is het belangrijkste van een wachtwoord. Die paar extra tekens staan in het niets bij de complexiteit die extra lengte toevoegd

[434365]

Ik:

Hoewel je helemaal gelijk hebt dat een langer wachtwoord vaak veiliger is dan een korter wachtwoord, is er wel degelijk een goeie reden voor speciale tekens, cijfers, hoofdletters etc.

Jij:

Wat je zegt is namelijk niet waar en een erg grote fout in de IT. Lengte is het belangrijkste van een wachtwoord.

Ik:
Uuuuuh? Ik zeg ook niet dat speciale tekens veiliger is, ik zeg ook dat lange wachtwoorden (vaak) veiliger zijn (correct horse battery staple is GEEN veilig wachtwoord!!!! ik hou van XKCD maar dat stripje is slecht/vergeet rainbow tables) ik geef waah alleen een korte uitleg WAAROM bijna iedere site dit doet.

[GrooV]

correct horse battery staple is ook maar een voorbeeld, je kan ook michelin autobanden branden beter gebruiken

[434365]

Was natuurlijk ook maar een voorbeeld van mijn kant (omdat bij dit soort onderwerpen altijd die comic gepost word) uiteindelijk is 'michelin autobanden branden beter' natuurlijk weinig veiliger, het zijn nog steeds 4 vrij standaard woorden, michelin wat minder, maar toch.

[Anoniem: 310408]

als je wachtwoord alleen uit kleine letters bestaat, hoeft een computer maar 36 tekens per character te proberen,

Ik denk dat je na even nadenken de fout in je redenatie ziet. Alleen als je als kraker weet dat er alleen kleine letters bestaan kunnen is de keuze kleiner. En dat soort sites bestaan naar mijn idee niet meer.

ghtrewsdwm is precies zo veilig als hg5%$gTggfr

De tweakers die dit plussen... urghhhhh

[RedLizard]

Eh, een beetje aanvaller weet donders goed (1) wat voor wachtwoorden gebruikers zoal kiezen als je ze de kans geeft, en (2) welke eisen er precies van toepassing zijn op een specifieke website (dat krijg je immers voor je neus als je een account probeert te maken). Op basis daarvan kan je zonder moeite uitwerken wat de structuur is van 80% van de wachtwoorden van een dienst.

Als ik weet dat een site wachtwoorden als "ghtrewsdwm" toestaat, dan stel ik mijn brute force tooltje in op kleine letters, en dan kan ik op die manier grote hoeveelheden wachtwoorden binnen harken. Misschien niet per se JOUW wachtwoord, maar ik ben geinteresseerd in de numbers game. Dat betekent dat tegen deze aanvaller, "hg5%$gTggfr" wel degelijk veiliger is dan "ghtrewsdwm". Het gros van de aanvallers is opportunistisch gericht op het laaghangend fruit.

Verder:

Alleen als je als kraker weet dat er alleen kleine letters bestaan kunnen is de keuze kleiner.
ghtrewsdwm is precies zo veilig als hg5%$gTggfr

Met andere woorden: jij vertrouwt erop dat jij beter bent in onvoorspelbaar zijn in je wachtwoordkeuze, dan de aanvaller goed is in jouw gedrag voorspellen. Er is een wapenwedloop tussen gebruikers die proberen onvoorspelbare wachtwoordkeuzes te maken, en aanvallers die proberen patronen te herkennen. Denk jij echt dat je dat gevecht consistent gaat winnen? Zo niet, dan is hg5%$gTggfr" opnieuw veiliger dan "ghtrewsdwm".

Je onderschat de aanvaller grondig als je denkt dat hij niet kan raden wat voor patronen er achter mensen's wachtwoorden zitten (naar smaak xkcd link invullen hier). Ja, zelfs jouw wachtwoorden. Het onderschatten van je vijand is een uitstekende manier om een gevecht te verliezen.

[434365]

Alleen als je als kraker weet dat er alleen kleine letters bestaan kunnen is de keuze kleiner. En dat soort sites bestaan naar mijn idee niet meer.

- Als een kraker zn werk heeft gedaan dan weet hij toch van welke site de lijst komt? even kijken naar het registratie formulier en hij weet de regels voor het wachtwoord?
- Een beetje kraker is slim genoeg om klein te beginnen (aaaaa) en uitgebreid te eindigen (C0rr3ct horse b@ttery stap1e)
- Er zijn helaas nog genoeg sites die speciale tekens etc niet ondersteunen in wachtwoorden.

De tweakers die jou +3 geven.... urghhhhhh

[IGKR5]

Relevant xkcd

[434365]

Pas hier alsjeblieft mee op, ik hou echt van XKCD stripjes, maar deze is vrij gevaarlijk om maar klakkeloos te accepteren als 'goeie tactiek'.

Wat deze strip totaal vergeet mee te nemen is het gegeven 'rainbow tables', dit zijn (wacht-)woordlijsten die gebruikt worden in combinatie met brute forcing, en geloof maar dat die 4 woorden (correct horse battery staple) ondertussen in iedere woordenlijst staan die je kan vinden.

Oftewel, zonder dat je het echt doorhebt heb je dus (als je dat wachtwoord zou hebben) simpel gezegd een wachtwoord van 4 'tekens'/woorden, nou niet bepaald veilig, dan is Tr0ub4dor&3 misschien nog wel veiliger...

[Tacow]

Een rainbow table zal de volledige combinatie van "correct horse battery staple" moeten bevatten om te matchen. De losse woorden "correct", "horse" enzo zullen niet gematched kunnen worden.
De spaties zijn immers gewoon een onderdeel van het wachtwoord (speciale tekens) en het geheel is dus een prima wachtwoord.

Behalve dan dat het precieze wachtwoord natuurlijk in zoveel voorbeelden gebruikt wordt dat dat wel in die rainbow tables staat.

[434365]

Een beetje bruteforce programma wat met rainbow tables werkt (lees; vrijwel allemaal) heeft vandaag de dag wel de optie woorden te combineren, al dan niet met spaties, jij bent natuurlijk niet de eerste die met dit tegenargument komt

[Anoniem: 890159]

Een site die na zoveel mislukte inlogpogingen niet snapt dat er iets niet klopt is anders ook niet best opgezet.

[skatebiker]

Onzin. Gewoon langer ww nemen met alleen letters.
Dus xxxxx of aaaaaaaa.
Zie mijn vorige post.

[434365]

Nee dus, want de doorsnee gebruiker zal a-la die XKCD strip een paar woorden gebruiken, en dan ben je echt niet veiliger uit. Er bestaat zoiets als 'rainbow tables' dit zijn woordlijsten van woorden die vaak gebruikt worden, en vaak in wachtwoorden voorkomen, en deze lijsten kunnen weer aan zo'n brute-force process gevoerd worden.

Nou weet ik (gelukkig) natuurlijk je wachtwoord niet, maar als je een beetje lang wachtwoord hebt met alleen letters durf ik te wedden dat het een paar woorden zijn, dan is je wachtwoord vrij zwak, ipv dat je (om maar wat te noemen) 30 tekens hebt, heb je (wederom, om maar wat te noemen) 6 woorden, dat is dus absoluut niet veilig als er iemand met maar een klein beetje kennis je wachtwoord probeert te kraken.

[Jace / TBL]

Dat is onzin.

Alexanderstraat152 is een veel slechter password dan 7G{jL;>x%B1u ondanks dat het langer is.

De sterkte van een wachtwoord zit hem niet in de lengte maar entropie. En de entropie van woorden, huisnummers, geboortejaren, en andere dingen met betekenis of context is veel minder dan het aantal karakters waar ze uit bestaan.

[Anoniem: 890159]

De sterkte van een wachtwoord hangt af van de aanvalsvectoren. Als brute forcen een optie is heb je gelijk, als meekijken over de schouder de voornaamste aanvalsvector is niet.

[Jace / TBL]

Ook als meekijken over de schouder een aanvalsvector is, zijn 12 random karakters veiliger dan je straatnaam + geboortejaar wat misschien wel twee keer zo lang is.

[Anoniem: 890159]

Mijn wachtwoord is een hele rij sterretjes, is dat veilig?

[Jace / TBL]

Ligt eraan hoeveel. Meer dan 40 sterretjes is wel veilig, dat raadt niemand

[Reactie gewijzigd door Jace / TBL op 24 juli 2024 21:19]

[koelpasta]

De sterkte van een wachtwoord zit hem niet in de lengte maar entropie. En de entropie van woorden, huisnummers, geboortejaren, en andere dingen met betekenis of context is veel minder dan het aantal karakters waar ze uit bestaan.

Dat is alleen als je de aanname maakt dat er inderdaad ook echte woorden worden gebruikt in een wachtwoord.
Als het wachtwoordsysteem ook cijfers en leestekens accepteert dan zit er nog best veel entropie in 'Alexanderstraat152'. Het had namelijk ook 0N879B&b86vC%c7 kunnen zijn.

[CAPSLOCK2000]

NIST is de voorschriften aan het aanpassen. De nieuwe best practices zijn inderdaad om al die regels over hoofdletters en vreemde tekens af te schaffen, net als verplichte wachtwoord rotatie. Hoewel deze maatregelen in theorie goed zijn, werken ze alleen als mensen ook oprecht proberen om ze te volgen. In praktijk ervaren de meeste mensen die regels als een belemmering waar om heen gewerkt moet worden, of snappen ze niet wat er van ze verlangd wordt. Daardoor maken de oude regels het in praktijk vaak minder veilig in plaats van meer veilig.

[MadEgg]

Dat is niet per definitie waar.

correct horse battery staple

is makkelijker te kraken dan

`;+pZ>2M

Er zit zeker een sterk verband tussen de complexiteit van het kraken van een wachtwoord en de lengte ervan, maar er zit ook een sterk verband tussen de zoekruimte (aantal verschillende tekens waaruit gekozen wordt en de complexiteit van het kraken.

Of om het nog even wat concreter te maken:

8 kleine letters levert 208,827,064,576 mogelijk combinaties op.
9 kleine letters levert 5,429,503,678,976 mogelijke combinaties op.
8 kleine of grote letters levert 53,459,728,531,456 mogelijke combinaties op.

Het toevoegen van grote letters aan de set naast kleine letters levert dus een factor 10 meer complexiteit op dan het toevoegen van één extra karakter. In dit geval is het kortere wachtwoord dus complexer dan het langere wachtwoord. Korter is altijd zwakker kan je dus ook hier niet zeggen.

Veelgebruikte woorden gebruiken als wachtwoord is een aardig alternatief voor een korter maar willekeurig wachtwoord, maar je kunt de kraakcomplexiteit niet één-op-één vergelijken. Je kunt prima een dictionary attack doen op combinaties van veelgebruikte woorden, daarmee wordt de zoekruimte een flink stuk kleiner dan als je de volledige lengte met willekeurige woorden zou vullen (waar het befaamde XKCB-stripje vanuit lijkt te gaan).

[Reactie gewijzigd door MadEgg op 24 juli 2024 21:19]

[koelpasta]

Er zit zeker een sterk verband tussen de complexiteit van het kraken van een wachtwoord en de lengte ervan, maar er zit ook een sterk verband tussen de zoekruimte (aantal verschillende tekens waaruit gekozen wordt en de complexiteit van het kraken.

Eeh, maar heb je dan al uitgerekend wat de zoekruimte is van nederlandse woorden?
Waar je met losse characters max 26+26+10+leestekens aan woorden hebt is de set aan woorden in de nederlandse taal enorm veel groter.

Als ik even ervan uitga dat je alle ~240.000 woorden uit de Van Dale kan gebruiken (wat in de praktijk niet zo zal zijn, maar goed, even grof kijken hoe groot die ruimte is) dan krijg je voor een serie van 4 woorden ongeveer:
240000^4
en dat komt uit op zo'n 3.317.760.000.000.000.000.000 mogelijke combinaties!!!!!

Daar ga je dan met je characters

En natuurlijk heb je gelijk dat mensen veelgebruikte woorden gaan gebruiken maar stel de woorden komen uit een set van veelgebruikte woorden van 4000.
Dan krijg je alsnog:
4000^4 = 256.000.000.000.000 mogelijke combinaties bij vier woorden.

[MadEgg]

Dat volgt toch ook uit mijn berekening?

4 woorden uit een set van 4000 woorden, dan maak je het me wel heel makkelijk

4000^4 combinaties dus voor 4 woorden.
72 (uitgaande van 10 leestekens), 8 karakters: 72^8.

Ik ga de getallen niet uischrijven, maar de ratio:

4000^4 / 72^8 = 0.35. De 4 woorden zijn dus slechts 35% van de zoekruimte van 8 willekeurige karakters. Het is beide groot, maar absoluut niet onkraakbaar.

[Reactie gewijzigd door MadEgg op 24 juli 2024 21:19]

[koelpasta]

Ja, ik las je andere posts te laat.
Punt is wel dat het met woorden makkelijk is om er een obscuur woord tussen te gooien. Zal alsnog makkelijker te onthouden zijn dan een random combinatie.
En dan tap je dus uit de complete Van Dale, met dus zo'n 240.000 symbolen.

En er moet overigens ook nog ergens iets zijn dat de woorden die je kiest niet te kort moeten zijn omdat anders brute forcen weer makkelijker wordt.
Een combinatie als 'de in op te' is slechts 12 characters lang.
Dus het zit allemaal wat complexer in elkaar en is afhankelijk van hoeveel de breker weet over de aard van het wachtwoord.
Magoed, dat terzijnde.

[MadEgg]

Dat is zeker waar! Passphrases hebben zeker hun waarde, maar onderschat de capaciteit om slechte wachtwoorden te bedenken van mensen niet!

Er wordt vaak geroepen dat 4 woorden kiezen aanzienlijk veiliger is dan een wachtwoord, en dat klopt gewoon niet per definitie. Het hangt altijd af van op welke manier het wachtwoord tot stand gekomen ie en de eventuele kennis die over een persoon op internet te vinden is.

Mijn mening is dat zelf onthouden gewoon geen goede oplossing is. Het gebruik van een password manager (en dan niet alleen om te onthouden, maar ook vooral om te genereren) zou zo'n beetje verplicht moeten worden.

[koelpasta]

Ja, de subset van veel voorkomende woorden die mensen kiezen zal waarschijnlijk een heel stuk lager liggen dan de gehele ruimte.

Over PW managers ben ik nog niet uit.
Het is een single point of failure.
Ja, je kunt dan 1 heel lang en moeilijk te raden wachtwoord gebruiken als master maar dat is mogelijk nog moeilijker te onthouden en dus meer potentie op opschijven en als dat in verkeerde handen komt dan ben je gelijk alles kwijt.

Maar voor veel doeleinden zal het prima werken.

[MadEgg]

Ik heb meerdere password kluizen, elk met een eigen moeilijk master password. Dan is het geen SPOF meer

Opschrijven is weer "pebkac" natuurlijk. Dat risico hou je altijd. Net als 2FA overigens, mensen die passwords opschrijven laten hun telefoon vast ook vask slingeren. Maar het risico op hacks is wel veel lager aangezien je overal een ander willekeurig wachtwoord gebruikt als het goed is.

[dormamu]

Je maakt wel een kleine denkfout. De Nederlandse taal kent geen absoluut aantal woorden omdat onze taal gebruik maakt van samengestelde woorden. Dit zijn woorden die eigenlijk opgebouwd zijn uit twee of meerdere woorden. Dit betekent dat het aantal absolute unieke woorden vanuit het perspectief van een dictionary attack vele malen lager ligt dan 240.000. Het Engels is wel een taal met een absoluut aantal woorden. Dit zijn er volgens de Oxford dictionary iets meer dan 47.000. Als we die lijn door trekken dan heeft het Nederlands ook niet meer dan 50.000 absolute unieke woorden.

[koelpasta]

Je maakt wel een kleine denkfout.

Het maakt het wel wat ingewikkerder idd.

Maar dan nog, als een woord uit twee woorden is opgebouwt dan worden dat in jou dictionary dus opeens ook twee symbolen.
Zeg we houden voor de lol die hoeveelheid engelse woorden aan dan wordt dat gecombineerd woord uit een set van 240.000 dus opeens twee woorden die elk uit een set van 47000 komen.
Dat komt neer op 47000^2 = 2.209.000.000 combinaties !!!
Veel meer dus dan die set van 240.000

Laat staan woorden die uit meer dan twee woorden bestaan. Fietsvergunningsgarantieverlener is vier woorden. Das dus 47000^4 = 4.879.681.000.000.000.000 combinaties die op deze manier gemaakt kunnen worden. Daarbij zit er ook nog een stiekume 's' in die je niet goed kan plaatsen tenzij je alle woorden nog een keer in je dict opneemt maar dan met een extra 's'. Of je ziet die s als een extra woord maar dan wordt de combinatieruimte ook een beetje groter door.

Maar goed, natuurlijk zijn niet alle woorden uit die 47000 met elkaar te combineren en zal die set in werkelijkheid kleiner zijn.
Maar alsnog, als je die woorden op de door jou gesuggereerde wijze gaat opdelen dan neemt de ruimte in dit geval dus toe!

[dormamu]

Je hebt helemaal gelijk. Het is een afweging. gebruik je unieke woorden of een echt woordenboek. In jouw voorbeeld had je het woord überhaupt niet gevonden met de dikke Van Dale 😉

[GrooV]

Sorry dit is gewoon niet waar. Zie mijn andere reactie: GrooV in 'nieuws: 90 procent DigiD-gebruikers heeft zwak wachtwoord zonder sm...

Volgens https://howsecureismypassword.net/

correct horse battery staple -> 15 OCTILLION YEARS

`;+pZ>2M -> 2 DAYS

[Reactie gewijzigd door GrooV op 24 juli 2024 21:19]

[Jace / TBL]

Volgens https://howsecureismypassword.net/

Dat is een zeer slechte en totaal niet representatieve graadmeter voor hoe sterk je wachtwoord is.

Deze is bijvoorbeeld al beter: zxcvbn en dan ongeveer de onderste van de 4 guess times (uitgaande van het offline kraken van een password database).

[MadEgg]

Ik noem bewust 'correct horse battery staple' omdat die uit het stripje komt. Die zal dus, de luiheid van mensen in acht nemend, op élke dictionary-attack-lijst staan en daarmee vrijwel instantly te kraken zijn. Dat wachtwoord heeft al zijn waarde verloren.

En die 15 octillion years is berekend op basis van de aannamen dat lengte de enige factor is. Als we even vergeten dat 'correct horse battery staple' inmiddels bekend is, is het effect sowieso dat je gaat zoeken naar wachtwoorden van 4 woorden.

Neem een tienduizend veelgebruikte woorden in je taal, 4 woorden, dus dan kom je op 10000^4. Dat vergelijk je met 72 mogelijke karakters, 8 teken, 72^8 combinaties.

Dat scheelt een factor 14. Als '`;+pZ>2M' dus in 2 dagen te raden is, dan is 'correct horse battery staple' in 28 dagen te raden, niet in 15 octillian years.

Voeg je er een karakter aan toe, 72^9, dan is het random wachtwoord weer lastiger te kraken.

[Xiphalon]

Die 28 dagen geldt dus alleen als je weet dat het wachtwoord uit 4 woorden bestaat.

[MadEgg]

Die 28 dagen geldt dus alleen als je weet dat het wachtwoord uit 4 woorden bestaat.

Zeker. Maar wat ga je eerst proberen? 15 octillian jaar brute-forcen of 28 dagen een dictionary attack?

Ik stel absoluut niet dat een dergelijk wachtwoord onveilig is, maar de onkraakbaarheid wordt met grote regelmatig ernstig overschat.

[MadEgg]

Lekker onderbouwd. Wat is er 'gewoon niet waar' dan?

[GrooV]

Dat laat ik toch zien, het "moeilijke" wachtwoord wat je laat zien is in 2 dagen te kraken, terwijl correct horse battery staple er ontelbaar aantal jaren over doet

[Reactie gewijzigd door GrooV op 24 juli 2024 21:19]

[MadEgg]

Dat had je er later in-geedit. Toen ik reageerde stond er alleen

Sorry dit is gewoon niet waar. Ik hoop dat niemand dit leest.

[SinergyX]

Maar ga je dan niet uit van het principe dat zij vooraf weten met welke pool je te maken hebt? Immers kan dat eerste wachtwoord ook bestaan uit dezelfde leestekens, jouw 'pool' per teken zal je dus net zo breed moeten inzetten als je 2de wachtwoord.

[tweaknico]

Zelfs als je woordenboeken van verschillende talen aan elkaar knoopt is de zoekruimte veel kleiner dan willkeurige teken volgordes.
En ja in die woorden boeken kun je ook gelijk de regeltjes I=1, E=3, Z=2, L=7 etc. meenemen.

[Aikon]

Het verplicht stellen van speciale tekens zorgt er voor dat je als kraker nu eenmaal op een grotere dataset moet testen, daarmee wordt een wachtwoord sterker, net zoals dat bij de lengte gebeurd.

Een kort wachtwoord is daarmee niet per definitie zwakker dan een langer wachtwoord.

[GrooV]

Dat is echt de grootste onzin, een passphrase is veel veiliger dan een W@chtw00rd!

Bijvoorbeeld: i own 2 dogs and 1 cat is nagenoeg nooit te kraken, met welke tabel of bruteforce dan ook (wie weet met kwantum computers). Maar bijvoorbeeld J5bZ>9p! heb je in minder dan een dag gekraakt.

Als je een passphrase gebruikt, let wel op dat je geen makkelijk te raden woorden of combinaties gebruikt

Meer info & bron: http://crambler.com/passw...d-length-over-complexity/

Dus: lengte is belangrijker dan moeilijkheid!

[Reactie gewijzigd door GrooV op 23 juli 2024 14:23]

[MadEgg]

Het is maar net wat je met wat vergelijkt. Je neemt nu een wachtwoord van 8 tekens, dat is zo'n beetje de ondergrens van wat je als redelijk veilig wachtwoord kunt bestempelen (als je er vanuit gaat dat het willekeurige tekens zijn). Voeg daar één karakter aan toe en je bent alweer een aantal maanden onderweg om het te kraken, twee karakters en je bent tien jaar verder.

Als 'i own 2 dogs and 1 cat' niet waar is, dan zou het een goed wachtwoord zijn natuurlijk, maar in de praktijk komt het erop neer dat de persoon in kwestie dan ook daadwerkelijk 2 honden en 1 kat heeft, waarbij bij een gerichte aanval dat echt wel op de lijst met mogelijkheden gezet zal worden.

[JAVE]

Dan ga je ervan uit dat de kraker een bekende is van de persoon met die zin.
Over het algemeen wordt er een brute-force losgelaten om een verzameling wachtwoorden, zonder de achterliggende personen te kennen.

Het grootste probleem met wachtwoorden is dat ze meestal voor computers makkelijk, en voor mensen moeilijk zijn.
Dat is met lange zinnen nu juist andersom.

Het probleem is alleen dat mensen de wachtwoorden vanuit een menselijk standpunt bekijken. 'Waar de blanke top der duinen...' is voor een mens veel makkelijker (te onthouden, begrijpen) dan 'kF3#bp@!'. Dat laatste moet dus wel een moeilijker wachtwoord zijn!

Nu is een brute force tegenwoordig meestal een combinatie van een dictionary en brute force attack. Ze gaan dus eerst de 'makkelijke' dingen af. (12345, wachtwoord, etc) voordat ze een echte brute force beginnen.

Pas wel op, de xkcd passphrase is in feite niets anders dan een wachtwoord met 4 tekens. OK, er zijn wat meer woorden dan karakters, maar in feite hoef je alleen maar een woordenboek af te lopen met <woord1><woord2><woord3><woord4>. (En gezien de populariteit van xkcd is een check op 4 woorden dus een goed begin ;-))

[MadEgg]

Pas wel op, de xkcd passphrase is in feite niets anders dan een wachtwoord met 4 tekens. OK, er zijn wat meer woorden dan karakters, maar in feite hoef je alleen maar een woordenboek af te lopen met <woord1><woord2><woord3><woord4>. (En gezien de populariteit van xkcd is een check op 4 woorden dus een goed begin ;-))

En dat is een goede samenvatting van mijn argument

[GrooV]

Ja dat zeg ik toch ook, dat je passphrase wel lastig te raden moet zijn

[aadje93]

tja, en als het met random tekens gaat, dan maakt het niet meer uit of het er 8 zijn of 28....

[walteij]

Dus wel, want een wachtwoord brute force raden is veel eenvoudiger bij 8 ipv 28 karakters, om nog maar te zwijgen van rainbow tables die zo ongeveer alle wachtwoord combinaties t/m 10 karakters wel hebben geindexeerd. Google/Shodan maar eens de hash van je wachtwoord van 8 karakters.
Mijn wachtwoorden zijn geen van allen korter dan 12 karakters en inderdaad bij voorkeur een passphrase. Voor onbelangrijke dingen (forums enzo) gebruik ik een passphrase die enigszins standaard is voor mezelf met afwijkingen per website.

Belangrijkere gegevens (internet bankieren, DigID, verzekering etc) weet ik zelf de wachtwoorden niet eens van. Daarvoor heb ik keePass, welke is afgeschermd met een certificaat en een passphrase van pakweg 25 karakters.
De wachtwoorden die keePass genereerd zijn ook minstens 128 bit, met werkelijk waar bijna alle soorten karakters (uitzonderingen zijn quote-jes (' en ") en spaties.
2-factor authenticatie bij deze websites is bij mij dus ook gewoon standaard (en dus niet via een app op mijn telefoon, maar gewoon via een SMSje).

[Reactie gewijzigd door walteij op 24 juli 2024 21:19]

[aadje93]

ik bedoelde in de trend dat het dan niet meer uitmaakt om er één van 28 (of meer indien mogelijk) te nemen, immers gebruikt men dan toch vaak een password manager.

[walteij]

Wat betreft de password manager heb je (deels) gelijk. Als je een password manager gebruikt, kun je er het beste voor kiezen om een wachtwoord te nemen met zoveel mogelijk karakters (omdat je het toch niet zelf hoeft te onthouden).
Maar, even als voorbeeld gaan we vergelijken. Hoe makkelijk (of moeilijk) is een wachtwoord te bruteforcen met 8 random karakters volgens: https://howsecureismypassword.net/

H1Va['Zu
It would take a computer about 13 hours to crack your password
Nu 28 random karakters:
kvMg*CUn%nG2LMmQdX^Y$wX84+LL
It would take a computer about 53 decillion years to crack your password.

Het maakt dus wel zeker uit of je nu 8 of 28 karakters neemt als het om de veiligheid gaat. Als het om gebruikersvriendelijkheid gaat, de password manager is net zo vriendelijk voor de gebruiker met een 8 of 28 karakter wachtwoord inderdaad .

[skatebiker]

Maar andersom ook niet.

1. Letters, cijfers, tekens: dat zijn er 96.
2. Alleen letters (niet hoofdlettergevoelig), dat zijn er 26.
3. Alleen cijfers: dat zijn er maar 10.

Een rekensom leert dat hoe lang een wachtwoord moet zijn.
Een ww van categorie 3 (boven) moet log(96)/log(10) is ongeveer 2x zo lang zijn om het even veilig te maken.
En van categorie 2 log(96)/log(26) is 1.4.
Maar een langer ww van alleen letters is makkelijker te onthouden dan een met hoofd-, kleine letters, cijfers en tekens.
En daarom schrijven steeds meer mensen hun ww op omdat ze het niet kunnen onthouden met die stompzinnige regels 'er moet een hoofdletter, cijfer en een speciaal teken in zitten'.
Voor Digid zou ik trouwens gewoon een hardware token maken net als de banken dat doen. Dan hoef je alleen maar een eenvoudige pincode te onthouden.

[Tielenaar]

Dit inderdaad. Ik kan serieus boos worden op mensen/websites die password policies verzinnen waarin bepaalde tekens worden vereist. Een wachtwoord van 16 random kleine letters is VEEL veiliger dan eentje van het minimum van 8, die standaard eindigt met 1!, en begint met een hoofdletter. Password1! wordt door veel websites als veilig gezien, terwijl mskfjglekwjfbnbmbieh niet door de check heen komt. Onbegrijpelijk. Waar komt die speciale tekens fetish toch vandaan? Het voegt complexiteit toe, maar het langer maken met 1 karakter voegt net zo veel toe. Maak het minimum dan 10 ipv 8.

Het enige dat ik kan bedenken is dat dit mensen ervan weerhoudt om simpele leesbare woorden te gebruiken van 8 letters, maar dit zorgt alleen maar voor het toevoegen van een ! of @ aan het eind.

[Yaminike]

Helaas alleen jammer dat die extra dataset nog steeds onderdoet aan het langer maken van een wachtwoord.
Misschien wel eens leuk om te lezen als je dat niet al had gedaan.

https://xkcd.com/936/
https://blogs.dropbox.com...word-strength-estimation/

[Ramon]

Het verplicht stellen van speciale tekens zorgt er voor dat het recept voor het wachtwoord bekend is en dus makkelijker te kraken.

Als je een site hebt die eist dat er, 6 letters, 2 nummers en een speciaal teken in zit, dan kan je er vergif op nemen dat 98% van de wachtwoorden 6 letters, 2 nummers én een speciaal teken hebben. De 2% die overblijft gebruikt misschien een wachtwoordmanager

[Aikon]

Ja klopt inderdaad. Ik bedoel eigenlijk dat je ze niet moet uitsluiten, hoe meer opties je biedt als karakter in een wachtwoord hoe moeilijker deze te kraken wordt omdat je als kraker er altijd rekening mee moet houden.

[10 feet high]

Dat wordt wel vaker gezegd, maar blijkbaar slaagt er zelden iemand in om dat op een betrouwbare en volledige manier te onderbouwen. Vaak gaat het er dan om dat dat enkel het geval is wanneer je naar één specifieke manier van het onthullen van een paswoord zou gaan kijken (waarbij de rekenkracht van een computer een van de factoren is).

Toch slagen bijvoorbeeld banken er (nationaal en internationaal) in om een systeem te ontwikkelen waarbij de wachtwoorden niet specifiek langer worden en uit meerdere soorten tekens bestaan, maar men gebruikt een wachtwoord van vier karakters, enkel cijfers.

Daarnaast krijg je de laatste jaren helemaal niet de indruk dat er bij een groot deel van de zaken waarbij wachtwoorden worden onthuld, helemaal geen sprake is van het gebruik van die rekenkracht/datasets/whatever. Het gaat dan onder meer om phishing, het onderscheppen van opgeschreven wachtwoorden (papier of via sms/e-mail), het raden van paswoorden of het uitproberen van wachtwoorden die elders gebruikt worden. Al die zaken staan compleet los van de lengte van een wachtwoord of het gebruik van speciale tekens.

[Waah]

In een lang wachtwoord dat simpel te onthouden is (en dat is de kracht van een langer wachtwoord bestaande uit woorden) kan je ook makkelijker aanpassen op de dienst. Je kan dus makkelijker unieke wachtwoorden maken door bijvoorbeeld de naam, een afkorting etc te verwerken in het wachtwoord.

Hiermee voorkom je het hergebruik van wachtwoorden (een simpele manier van wachtwoorden kraken) en het opschrijven van wachtwoorden.

Zelfs speciale tekens zijn makkelijker te integreren. Maar zolang er sites zijn waar je verplicht minimaal 8, maximaal 16 tekens, bij de een mag teken X wel, en bij de ander mag dat teken weer niet..... dan ga ik niet overal verschillende wachtwoorden hanteren. Nee dan rouleer ik er wel 3, waarbij de ernst als iemand het wachtwoord weet verschilt.

[MadEgg]

Mijns inziens is de enige écht goede oplossing een password manager. En dan bij voorkeur eentje zónder integratie met je browser, we zien regelmatig nieuwsberichten voorbij komen waarbij dat opnieuw tot lekken van wachtwoorden geleid heeft.

Ik gebruik voor al mijn wachtwoorden KeePassX, en genereer bij default wachtwoorden van 32 karakters met letters, cijfers en tekens. Helaas zijn er inderdaad teveel sites die daar arbitraire beperkingen aan leggen (zoals dat je geen ' of " mag gebruiken in het wachtwoord, of dat het niet langer dan 16 karakters mag zijn, of of of). Op basis van die eisen schroef ik de generatie iets naar beneden tot het hoogst toelaatbare.

Onlangs heb ik een Mooltipass Mini ontvangen, na hun Kickstarter gebackt te hebben in november. Een hardwarematig apparaat met een chip op een kaart die de encryptie verzorgd icm een passcode. Ik ben er nog mee aan het experimenteren. Het werkt heel leuk in ieder geval - het apparaat doet zichzelf voor als een toetsenbord en kan zo de wachtwoorden voor je intypen op je laptop of PC. Op je telefoon wordt dat weer wat lastiger, daar kan ik geen USB-apparaat op aansluiten. Het geeft, net als een softwarematige password manager wel de veiligheid van lange én complexe wachtwoorden.

[tweaknico]

Belangrijker is: Hoe weten ze uberhaupt de gebruikers ww.....

Blijkbaar zijn de ww. inzichtelijk voor de beheerders, dat is dan de eerste fout als er geen goede one-way hash op zit.
In het andere geval zijn er blijkbaar metrieken over het wachtwoord vastgelegd..., zoals het ww. van deze gebruiker is 10 lang, heeft 2 hoofdletters, 3 cijfers en 1 leesteken. (Dat scheelt dan weer als je een ww. zou willen raden...)
En voor het geval er Private/Public key encryption toegepast wordt dan is dat geen toegevoegde waarde, want ik heb zelf geen private key waarvan ik een public key heb uitgeleverd.
Het is dus meer Digid die als Digid namens mij kan optreden....(Daar hebben ze feitelijk geen informatie (wachtwoord) van mij voor nodig).

[0xygen500]

Als je kan zien hoe lang een wachtwoord is en je baseert de definitie van "zwak" op de lengte, dan hoef je niet het echte wachtwoord te weten.

[tweaknico]

Een goed gehased wachtwoord is ALTIJD 32 bytes lang als bv. een MD5 hash wordt gebruikt, en nog veel langer als andere hashes worden gebruikt.

Ongeacht hoe lang het wachtwoord is. Als het goed is zijn alle accounts van verschillende salts voorzien zodat zelfs gelijke ww. tot een verschillende hash leiden.

[Dorank]

In vrijwel alle inlog formulieren gaat het unencrypted wachtwoord naar de webserver (over een hopelijk encrypted verbinding) om vervolgens daar gehashed te worden.

En voor het geval er Private/Public key encryption toegepast wordt dan is dat geen toegevoegde waarde, want ik heb zelf geen private key waarvan ik een public key heb uitgeleverd.

Dat komt wellicht nog ooit met nieuwe ID bewijzen met een PKI.

[tweaknico]

Wederom zie ik niet in hoe iedere burger z'n EIGEN PRIVATE key erop gaat zetten.
(ie. Ik genereer mijn private key, en kan die ZELF op de kaart zetten)

vs. wat de waarschijnlijke implementatie is: De Overheid zet de Private key op de kaart
(en weet dus zowel de Private als Public key)....
Daarmee kan de overheid dus ook duplikaten maken en met die ID aan de wandel,

[Dorank]

Ik mag hopen dat er smartcards gebruikt worden die geen externe sleutel kunnen importeren. Dan is het systeem inderdaad waardeloos. Als het goed is wordt het keypair gegenereert, exporteert de kaart de pubieke sleutel en wordt deze gesigned door de overheid en gepubliceerd. Zonder de signature van de overheid is het PKI verhaal waardeloos aangezien niemand de echtheid kan controleren aan een WoT.

Als de overheid het goed wil doen zou je als gebruiker zelf de kaart een willekeurige sleutel moeten kunnen laten genereren en dan zelf de public key kunnen overleggen.

[tweaknico]

Er is altijd maar een bepaald paar public/private key... vergelijk het met een willekeurig doorgescheurd papier geld. dan passen er slechts 2 helften exact bij elkaar.
De ene helft is publiek, de ander private. (Die hou je bij je), de andere is voor iedereen raadpleegbaar in een register. Je identieit bewijs je door die twee naast elkaar te houden.
Net als X.509 certificaten moet de overheid hier als CA ondertekenaar optreden. Je E-ID moet dan hopelijk als unieke sleutel (waar geen kopieen van gemaakt kunnen worden) een sessie sleutel kunnen maken als de passphrase gevoed is.
(het verschil dat bij de private key een paar kenmerken horen waarmee een public key afgeleid kan worden, bij de public key ontbreekt deze info., als het goed is).

Als je Private key ELDERS is opgeslagen kan de eigenaar van ELDERS altijd zonder dat jij het weet die key benaderen, gebruiken (voor bv. ) nieuw E-ID maken etc.

[Dorank]

Als je Private key ELDERS is opgeslagen kan de eigenaar van ELDERS altijd zonder dat jij het weet die key benaderen, gebruiken (voor bv. ) nieuw E-ID maken etc.

Vandaar de opmerking: Ik mag hopen dat er smartcards gebruikt worden die geen externe sleutel kunnen importeren.

[tweaknico]

Dat betekent dat de uitgever dus de private key bepaald, niet JIJ.
Dat betekent dat jouw Private Key ELDERS is.

[Pantostie]

Tweakers heeft dit zelf ook wel eens onderzocht. zie artikel
Ik kan me ook herinneren dat Tweakers toen een melding had bij de header die aangaf of je wachtwoord goed was of dat je het beter kon veranderen.

[tweaknico]

Dat betekent dat Digid de password database (Eigenlijk alles wat ze zijn een database van ww.) dus aan derden beschikbaar gesteld...???

Ik weet niet wat hier erger is. Het onderzoek van tweakers is kwalitatief beter omdat eerst wordt uitgelegd wat de methodiek is en dan het resultaat..., hier is er alleen een resultaat.
Wat daardoor nietszeggend geworden is.

[Superkanjo]

Ja, maar als je aangeeft dat 90% een wachtwoord wat alleen letters heeft of korter is dan 5 karakters dan creëer je ook een risico. Kwaadwillenden weten dan ook meer. Dus ik kan begrijpen dat dit niet openbaar wordt gemaakt.

[tweaknico]

42,

is ook een antwoord...., maar wat was de vraag?

90% is een antwoord maar zonder nadere aanduiding niet zinnig, waardevol.. of actie waardig.

[Reactie gewijzigd door tweaknico op 24 juli 2024 21:19]

[Superkanjo]

42

Uhm ik begrijp je niet denk ik

[tweaknico]

(Daar heeft Douglas Adams een trilogie in 6 delen over geschreven.
)
En de cursor hing op de verkeerde plaats waardoor ik te vroeg een antwoord plaatste.

[Ramon]

Je kan natuurlijk een lijst met hashes van bekende wachtwoorden vergelijken met de hashes uit je eigen database...

[tweaknico]

Als het goed is worden salts gebruikt om dit te voorkomen.

[Gopher]

Er staat nergens dat ze dit weten. Als je de comments en het originele artikel even naslaat wordt aangegeven dat het gebruik betreft. Dit is te analyseren tijdens de http(s) requests, kan volledig zonder wachtwoorden op te slaan of in te lezen. Op het moment dat je inlogt verstuur je altijd je ww stringetje.

[tweaknico]

Dus die kan gelogd worden...., dat is net zo fout als onvolledige opslag.
Een derde partij hoort geen toegang tot dat soort data te krijgen.
(Man In The Middle)

[Reactie gewijzigd door tweaknico op 24 juli 2024 21:19]

[Gopher]

The man in the middle kan hier enkel de partij zijn die digid consumeert, aangezien dit meestal al een overheidspartij is, en zij al informatie over jou als persoon kunnen raadplegen zou ik me daar niet druk over maken.

Daarnaast zal bij een normale implementatie van oAuth of iets dergelijks 't wachtwoord verstuurd worden naar digid, welke een token terugstuurt naar de consumerende dienst. Ofwel dan kan DigId je wachtwoord uitlezen.

Anders kom je er natuurlijk nooit.

[tweaknico]

Dat zou een behoorlijk foute implementatie zijn...
Het heen en weer spelletje bij OAuth is dat de target website je redirect met een stukje info (cookie) dat tussen OAuth organisatie en target website is afgesproken.

Je krijgt een redirect naar de Oauth website levert de target-OAuth cookie in, je authenticeerd, en je krijgt weer een cookie mee voor de target website.

Er is dus nergens een noodzaak voor unhashed cookies, en alleen de Oauth weet als het goed je cookie.

[Gopher]

Als het goed is bedoelde ik dit. Mogelijk krom verwoord

[Maistah]

Inmiddels heb ik 7 jaar ervaring als security tester en hacker. Ik kan je verzekeren dat een langer wachtwoord met nul variatie lastiger te achterhalen is dan een korte met speciale tekens.

Ik zou eerder kiezen voor:
ditwachtwoordisontzettendlangendaaromveiliger

Dan:
Tw34k3r$

[Anoniem: 714420]

Helaas zijn er veel websites die een maximumlengte stellen voor de wachtwoorden. Of, nog erger, die simpelweg alles na de eerste x tekens negeren.

[Bacchus]

Beiden hoeft geen probleem te zijn, ik kan er zelfs hele goede argumenten voor bedenken, mits die x maar voldoende groot is. En dan heb ik het over 100 à 200 vanwege performance: Je wil minstens 10 ms per wachtwoord besteden tegen brute-force maar ook niet veel meer dan een seconde tegen DoS.

[Anoniem: 714420]

Een limiet als 100 a 200 tekens zal in de praktijk weinig problemen opleveren. Dat was dan ook niet waarop ik doelde. Zo heeft bijvoorbeeld de ING een limiet van 20 tekens.

Overigens zijn de wachtwoordeisen van ING sowieso verschrikkelijk. Zo kun je van veel leestekens geen gebruik maken, en zijn ook spaties niet toegestaan. Tot zover het gebruik van wachtwoordzinnen!

[hackerhater]

Die hashingsalgoritmes boeit dat niet echt hoor. Hoe groot de invoer ik.
Ik verplicht zelf minimaal 8 tekens, voor de rest care.

[Bacchus]

Al eens geprobeerd een 100 KB aan tekst in je wachtwoordveld te plakken en daar een paar rondjes bcrypt over te draaien?

[hackerhater]

Hmmm good point.
Ik zal wel de limiet op 200 tekens zetten.

[stresstak]

Helaas zijn er veel websites die een maximumlengte stellen

Maar het gaat nu over digid. Hoe lang moet het daar zijn ?

Ik weet de eis even niet / slechts 1x per jaar nodig.

[0xygen500]

Mooi dat je dat bent, maar daar gaat mijn vraag niet over. Ik wil weten hoe zij op die 90% zijn gekomen. Indien :
ditw8woord=ontzettendlangendaaromveiliger ook gerekend wordt als zwak wachtwoord dan is je percentage natuurlijk hoger dan wanneer je alleen wachtwoorden met 5 letters als zwak aanmerkt.

[Jace / TBL]

Beide zijn redelijk zwak, want kwetsbaar voor dictionary attack.

Die tweede is wel zwakker inderdaad, want dat is maar één woord (met een paar bekende variaties op karakters die weinig veiligheid toevoegen).

Het beste is om wachtwoorden helemaal niet te verzinnen of onthouden, maar dat aan een password manager over te laten zodat je dingen als MCu0&gV/N4J+rz0K5wg^R krijgt.

[Vaan Banaan]

[offtopic]
Dat heb ik inmiddels opgegeven.
Bij de ene site werkt het wel, bij de andere niet. Wachtwoord te lang, verkeerde tekens, ik wordt er helemaal simpel van.
Zoals de ING
[i]• Lengte: minimaal 8 en maximaal 20 karakters.
Voor Mijn ING kunt u een wachtwoord maken met de volgende karakters:
• Cijfers: 0 t/m 9
• Letters: kleine letters (a t/m z) en hoofdletters (A t/m Z)
• Leestekens: punt (.), koppelteken (-), liggend streepje (_) en uitroepteken (!)
• Overige tekens: @, #, $ en %
Het wachtwoord in jouw voorbeeld is voor de ING dus te lang en bevat "ongeldige tekens"
Dan wordt het dus gewoon weer ouderwets een woord met hoofdletter + 1!

[Reactie gewijzigd door Vaan Banaan op 23 juli 2024 17:10]

[Bas de Bakker]

Zo'n reactie kan natuurlijk niet zonder een verwijzing naar https://xkcd.com/936/

[Anoniem: 919889]

Ik heb vaak deze gebruikt, is wel met een baard; "mijnwachtwoordisgeheim" of wat ik een collega vaak zag doen allemaal dezelfde tekens, je ziet het gebeuren maar dan, hoeveel..?

[Ramon]

Waarom niet gewoon voor bx^bzyESv<tHN2R9*<3ixtZ7 ?

[dormamu]

Tw34k3r$ is dan ook in enkele seconden te kraken. Dit is slechts 1 entry in een l33t speak dictionary.

[Anoniem: 919889]

Vraag mij af hoe ze weten dat er zwakke wachtwoorden worden gebruikt

[Gopher]

Ik verwacht op een simpele wijze. Zoals je bijvoorbeeld vaak een zwakte meter hebt bij het aanmaken van een nieuw wachtwoord; zo zal zeer waarschijnlijk de string die opgestuurd is door dezelfde check gehaald worden op de server. Zo kun je zien of deze sterk of zwak is en anoniem bijgehouden kunnen worden.

(Ja deze wordt inderdaad onversleuteld verstuurd over https, dat gaat niet anders tenzij je een versleuteling gebruikt die te achterhalen is, https is veilig genoeg hiervoor mits je SSL versie oke is).

Ik verwacht dat dit op een manier zoals ik hierboven aangeef gecheckt word en daar is op zich verder niets mis mee als dit het geval is. Dat de regels niet nageleefd worden heeft dan ook meer te maken met implementatie en de regels. Wat ik verwacht is dat de data die opgeslagen wordt niet op de beste manier beveiligd wordt. Is soms te begrijpen want dat kan lastig zijn, een migratie van een dergelijke implementatie heeft zeker veel risico.

[Zenka]

Wachtwoorden worden (voor de server) leesbaar opgestuurd als iemand inlogt. Daar word deze gehashed en vergeleken met de opgeslagen hash uit de database.
Je kunt voor het hashen natuurlijk even kijken naar hoe 'goed' het wachtwoord is en turven.

Dat of ze slaan wachtwoorden niet versleuteld op. Als dat het geval is... kom ik woorden te kort.
Wat ze bedoelen met 'gedeeltelijke encryptie' is mij niet duidelijk.

[Reactie gewijzigd door Zenka op 24 juli 2024 21:19]

[Willem_D]

Als het goed is worden de wachtwoorden al op de client gehashed. Die hash wordt dan naar de server gestuurd, en daar vergeleken. De server heeft (als het goed is) alleen een hashwaarde opgeslagen. En aan die hashwaarde kun je niet zien of het een sterk of zwak wachtwoord is.

Enige manier is dan om op de client de wachtwoord sterkte te meten.

[Bacchus]

Nee, de client hasht normaal gesproken niet. Het wachtwoord gaat ongehasht (maar hopelijk wel TLS-encrypted) over de lijn. De applicatieserver voert de hash uit, haalt de opgeslagen hash uit de DB op en vergelijtk die twee.

[pythagorasABC]

Dit zou ook het hele doel van hashen omzeilen. Dan zou je gewoon de hash op kunnen sturen, wat in feite neerkomt op een plaintext database...

[CH4OS]

Je zou an sich een hash over de hash kunnen maken. Echter zal je dan client side ook moeten hashen en juist die hash is dan makkelijk te achterhalen. Een aanvaller is dan dus al halverwege bij het achterhalen van een wachtwoord.

[pythagorasABC]

Wut? Dat is toch niet anders dan hem helemaal niet hashen client side?

[CH4OS]

Clientside hashen zal met JavaScript oid moeten en dan kun je toch achterhalen wat het algoritme van de eerste hash is?

[Reactie gewijzigd door CH4OS op 24 juli 2024 21:19]

[tweaknico]

Ze doen iets wel (bijna) goed:

https://www.ssllabs.com/s...tml?d=www.digid.nl&latest

Alleen geen DH Exchange en 3DES is nog geaccepteerd.

[Willem_D]

De hash en/of paswoord kan natuurlijk met een challenge-response worden opgestuurd naar de server.

Wat is er dan mis met op de client de hash al maken? Mits je die hash natuurlijk niet direct over de lijn stuurt, maar bijvoorbeeld een challenge-response gebruikt.

[Gopher]

Kun je me vertellen wat je precies bedoelt met challenge-response in dit geval?

Hashen doe je niet aan de client omdat:

1. De client mogelijk jou hash algoritme niet ondersteund
2. Je nog een SALT of andere rare toevoeging aan de password-string wilt toevoegen zodat Rainbow tables en andere fratsen het wachtwoord niet gemakkelijk kunnen achterhalen.
3. Het hashing algoritme zichtbaar zal zijn aan de client kant.
4. Een "Gebruik nooit x keer hetzelfde wachtwoord" onmogelijk wordt in een soortgelijke setting

FYI er is zo goed als geen enkele implementatie waarbij hashing client-side gebeurt bij wachtwoorden.

[pythagorasABC]

Is reden nummer 1 niet dat als de database wordt gehackt, dat de aanvallers dan in één klap alle "wachtwoorden" hebben?

Ze hebben natuurlijk niet alle wachtwoorden, maar effectief is er geen enkel verschil, omdat ze gewoon de hashes (al dan niet gesalt) op kunnen sturen naar de server.

Dit is dan ook (zo goed als) exact hetzelfde als een plaintext database opslaan imo.

[Gopher]

In jou voorstel is het juist gemakkelijker voor de Hackett, als deze dan de database achterhaalt hoeft hij jou wachtwoord niet te weten, enkel je hash. En kan hij inloggen met jou gehashde password ( dit zal makkelijker te emuleren zijn dan het de-hashen van een password).

Als je dit echt wilt weten stel ik voor om stackexchange even te raadplegen, daar zijn experts die het wat beter uitleggen. Client side hashing is gewoon minder secure als niet nutteloos. Je zou dan alsnog op de server hashen.

[MiesvanderLippe]

Als jij je network monitor opent in Chrome dan zie je heel leuk je wachtwoord meegestuurd worden hoor. De beveiliging ligt hem in de verbinding, voor de rest komt het wachtwoord gewoon plaintext bij de server aan.

Zie liever niet dit soort misinformatie online eigenlijk.

[stresstak]

De beveiliging ligt hem in de verbinding, voor de rest komt het wachtwoord gewoon plaintext bij de server aan.

Dan stuur ik ze toch de hash, dan blijft het wachtwoord bij mij..

[CH4OS]

De browser moet dan middels JavaScript de hash alvorens versturen... Dan is dus ook gelijk zichtbaar wat het algoritme is, denk niet dat dat heel handig is...

[Reactie gewijzigd door CH4OS op 24 juli 2024 21:19]

[AWitteveen]

Inderdaad, dat vroeg ik mij ook meteen af. Ik mag toch hopen dat de wachtwoorden beveiligd zijn opgeslagen en dat deze niet zomaar uit te lezen zijn.

[Jace / TBL]

Passwords moeten helemaal niet worden opgeslagen, en dus sowieso nooit uitleesbaar zijn.

[thefox154]

Misschien monitoren ze de indicator die aangeeft hoe sterkt het ingetypte wachtwoord is.
Het eind resultaat van deze meter kunnen ze natuurlijk monitoren.

[Anoniem: 669957]

nou als je een check doet van het wachtwoord en vergelijkt met de geboorte datum/namen/woonplaats van degene dan kan je al snel zien dat een wachtwoord zwak is.

9 van de 10 keer mag een wachtwoord niet gelijk zijn aan je naam(gebruikersnaam) en 9 van de 10 keer is dat de eerste wachtwoord die mensen intikken. Jantje(insertdateofbirth) of ronaldrotterdam1999 is een zwak wachtwoord omdat elke ander persoon dat ook kan bedenken.

[True]

Informatiebeveiliging bij afnemers steeds beter
Om de veiligheid van de gehele DigiD-keten te toetsen vereist de minister van BZK van alle
afnemers dat zij jaarlijks een DigiD-assessment laten uitvoeren door een IT-auditor. Uit de
resultaten hiervan blijkt dat in vergelijking met vorig jaar meer assessments direct bij de
eerste oplevering volledig aan alle normen voldoen, er in het totaal minder bevindingen
zijn en er minder uitstel van oplevering van het assessment is verleend.

Volgens: http://www.rekenkamer.nl/...e?objectid=25551&type=org

Niet bepaald duidelijk dus, een IT-auditor, wellicht middels enquetes of anders door inzicht in de gegevens, ook staat er in vermeldt dat niet alle DigiD gegevens volledig encrypted zijn en dit pas in 2018 bij de opvolger van DigiD zal gebeuren.

[Reactie gewijzigd door True op 24 juli 2024 21:19]

[Mel33]

Op het moment dat je ze aanmaakt is er een melding zwak of sterk, ik denk dat ze die gegevens uitlezen.

[m8ZBm1Si]

De organisatie constateert verder dat de encryptie onvolledig is

Ik denk hierdoor...

[Aikon]

Dat de encryptie blijkbaar niet goed is staat los van de gebruikte wachtwoorden. Met het eerste wordt het systeem achter het wachtwoord als het ware bedoeld.

[Dasprive]

Ze bedoelen wellicht dat de wachtwoorden met een zwak algoritme worden opgeslagen en dus te achterhalen zijn middels brute force of rainbow tables.

[Anoniem: 521666]

Misschien iets van een goed wachtwoord heeft een lange encryptie dan een slechte. Zo iets misschien.

[SmokingCrop]

Dan is de opslag hiervan ook al niet goed, hash + random waardes erbij levert zelfde lengte op voor alle wachtwoorden

[Thijsmans]

Als de encryptie "niet goed" is, zou het dan niet mogelijk zijn de opgeslagen encrypties terug te draaien tot het bijbehorende wachtwoord?

[Aikon]

Ja, dat zou wel als 'niet goede encryptie' worden geclassificeerd

[Anoniem: 200498]

Voor het opslaan het aantal character classes, lengte e.d. tellen en bewaren.

[Eface]

Ook dit was meteen mijn eerste gedachte. Als het klopt kunnen ze dit niet in zien.

Worden die wachtwoorden uberhaubt met een fatsoenlijke salt+encryptie opgeslagen?

Wordt de data opgeslagen hoe sterk je wachtwoord is/was? Ik dacht dat de richtlijnen op die site ervoor waren dat je minimaal een "sterk" wachtwoord zou hebben.

[kritischelezer]

Hoe kan het dat digiD dit soort onveilige wachtwoorden toelaat? Het is vrij eenvoudig een password strength test toe te passen, bij het aanmaken van een wachtwoord, die feedback geeft tijdens het aanmaken en slechte paswoorden weigert. Ook kan DigiD standaard de SMS verificatie aanzetten en dat de gebruiker moeite moet doen om dit uit te zetten bij het registreren...

[MadEgg]

Je kunt hoogstens een basale indicatie geven van de veiligheid van een wachtwoord.

Een goede extra check zou zijn om te kijken of het wachtwoord aanwezig is op enkele dictionary-attack-lists van veelgebruikte wachtwoorden en zo ja, het wachtwoord te weigeren. Maar voor de rest moet je het wachtwoord wel echt op een taalkundig niveau gaan analyseren om te kijken of het wel of niet eenvoudig te kraken zal zijn en dat is lastig te doen in een stukje javascript.

[kritischelezer]

Als ik in Cpanel een ww aanmaak, krijg ik direct een balk van groen tot rood te zien of het een sterk wachtwoord is. Ik begrijp dat als een wachtwoord jE&#dUO478E&#^#^ wat sterk zal betiteld worden, maar heel vaak voorkomt in dictionary-attack-lists minder sterk is, maar je haalt het simpele wel weg. Overigens is het natuurlijk niet zo moeilijk om de top 10.000 van die lijst als niet mogelijk te gaan betitelen voor een wachtwoord, door ze simpel weg the black listen.

[MadEgg]

Ja, die balk zie je overal. Ik bedoel dus dat die niet een echt goed oordeel kan vellen. De meestel van die indicatoren zeggen dat MadEgg1112970 een goed wachtwoord zal zijn, maar als ik geboren zou zijn op 11 december 1970 (wat niet waar is), is het een vrij waardeloos wachtwoord.

De wachtwoord-meters gaan er altijd vanuit dat de tekens die je invoert willekeurig zijn en geen betekenis hebben, en als dat inderdaad zo is, dan klopt het wel aardig. Maar anders zijn ze aardig misleidend.

[yeroon17]

Die zwakke wachtwoorden is heel eenvoudig op te lossen door wachtwoordbeleid toe te passen.
Minimaal X karakters, waarvan Y (hoofd)letters, cijfers en vreemde tekens.

Die SMS-authenticatie is vrij lastig bij DigiD.
Ik regel bij ons thuis de financiën (belasting, zorgverzekering e.d.). Maar ik moet dan soms ook als mijn vrouw inloggen (zorgverzekering staat op haar naam). Ze werkt onregelmatig en juist op de avonden dat ze niet thuis is, doe ik vaak de administratie. Dan is het niet makkelijk als zij een SMS krijgt.
(uiteraard gaat dit in tegen alles waar het voor bedoeld is, maar zo zal het bij veel meer mensen werken: één van de twee partners doet de financiën)

[Xiphalon]

Ze kan jou toch gewoon machtigen?

[yeroon17]

Dat kan inderdaad.
Dat wist ik niet
Dank voor de tip!